Borland's ALM strategy and Delphi Aug 07, 2005 12:45
A lot of things have been going on at the higher levels of Borland's business. Dale Fuller, the CEO for 6 years, has resigned. Borland has posted 2 consecutive quarters of losses. Robert Coates, former Board of Directors member and large shareholder is publically calling for a divestiture of the IDE businesses. Borland's interim CEO Scott Arnold and CFO Ken Hahn conducted a quarterly earnings conference call on August 2nd (I have transcribed a bit of it here). JBuilder revenue has declined more rapidly than previously expected and is going to be based on the Eclipse framework rather than the PrimeTime IDE core.
There has been a lot of discussion about these events in the blogsphere and in non-tech. So here's my take on it. It is very clear that Borland wants to be an ALM software company competing directly against IBM's Rational Software offerings. This is exactly the message they sent to the investors in the conference call and they made no bones about wanting to really push the ALM stuff. IMO, there is no reason not to believe Borland in this regard. Their website is very consistent with this message as well.
Borland is also more interested in larger deals with their customers. They want to sell 100k-1million+ dollar ALM suites rather than single 2k licenses of a development IDE. They discuss how their "customer engagement cycle" has changed. What this means is that their sales cycle is longer and more complex, requires more pre-sales proof-of-concept type work and is very often led by software process consulting. Channel sales are not the priority.
So let's put this into context for the Delphi developer. Instead of being the main focus of Borland, IDE's are the cashflow positive "mature businesses" that will fuel the ALM "growth engine". IDE's still represent the "Develop" portion of the ALM suite; so there are many that strongly believe that Borland will continue to invest in Delphi's R&D.
It's interesting to look at the JBuilder progression as a clue to what might happen with Delphi. JBuilder will probably be a bunch of plug-ins and extensions to Eclipse. The new R&D effort in these plug-ins will be focused around integrating Eclipse into their ALM suite. So let's actually look at the specific integration points within that ALM suite:
- CaliberRM: requirements viewing and something that can show as requirements change which portions of the code will be affected.
- Together: they already have an Eclipse Edition, I don't suspect this will change very much.
- Optimizeit ServerTrace: not sure, but probably just a client to this.
- StarTeam: source control integration, feature enhancement/bug tracking and team collaboration features.
This doesn't sound like very much to me. ALM Integration is nice, but hardly as useful to the developer as something like an integrated debugger.
Let's look at what happened to JBuilder and why they moved in that direction. JBuilder got its butt kicked by Eclipse. It's pretty much impossible to sell an IDE that competes against a good, free, open-sourced IDE backed by IBM. So JBuilder's revenue stream declined and Borland has decided to take what they can from JBuilder and roll it into Eclipse. In short, "if you can't beat'em, join'em". Makes sense to me.
So why isn't this going to happen with Delphi? In the context of an ALM strategy, I don't see why it wont. VS.NET is obviously capable of Together support. It's highly customizable and more importantly, if Borland wants to play the ALM game for dotNet shops, they have no choice but to support VS.NET.
But clearly, supporting VS.NET alone as part of their ALM strategy doesn't mean that BDS will be scrapped. So what were the factors in JBuilder's PrimeTime demise? Declining revenue and less strategic importance in the context of their ALM strategy. I think Delphi fits that profile exactly. If things proceed as they are, at best, Borland will produce a VS.NET plug-in for Delphi and BDS will be no more.
So what are the arguments justifying BDS' existence? One argument is that VS.NET costs money, unlike the free Eclipse IDE. I seriously doubt that 1-2k for an IDE is going to make a difference to the kinds of customers Borland is pursuing in their ALM strategy. Also, no one doubts that VS.NET has the largest marketshare in the Windows space.
The other issue here is grass-roots support of the developers within those organizations. Developers that have IDE's installed on their home computers, or used them in school, will probably recommend them to their managers at their place of employment. How many Windows developers have VS.NET? Ok, how many have Delphi? Who's doing a better job in the schools?
Ok, another argument is that VS.NET is closed-source. This is argued to say that VS.NET won't give Borland the distribution rights or the capabilities required for tight ALM integration. I don't know the details of the VSIP program, but that is exactly what that program is all about. I'm sure Borland knows a lot about it, since they already are a member in that program. Together, after all, has a VS.NET solution already. Hmm...so they've already built ALM integration into VS.NET, but it's just not possible? Right.
But the granddaddy of all the arguments is that Borland can do a better job at ALM integration using BDS than VS.NET. But what does that mean? What specifically can be done better with having full control over your IDE core? In reality, all this is a moot point because they have to support VS.NET anyway. I cannot imagine Borland will be able to sell a single ALM suite to a Windows shop without supporting VS.NET (well maybe a single one). But let's explore this in more detail.
I don't pretend to know what mysterious deep integration Borland will produce for their SDO vision. But I think this is part of the problem. Borland has yet to be able to articulate a compelling argument to the Developer for why the fusion of all these separate products will be better. In fact, I suspect that many developers ask the same question I do when I look at their SDP product: What is it? I have no idea.
It looks like all these separate products glued together more tightly. Where's the value for me, the developer? I don't have to hit alt-tab and copy-paste stuff between my bug tracker and my IDE? Wow...that's worth at least 100k.
Now, in all fairness, often times there is a value to this glue. Like I said before an integrated debugger that lets you step through code in the same editor that you write it in, is very useful. Once a developer sees it, there is no denying it. That's the way to go. Will this happen with their ALM integration? I doubt it.
ALM is one of those things that we developers do because it's part of the job. It's not something that at its core helps us build better software. It helps the software business manage building software. And there is a difference there. And before you go to write a comment below, let me explain.
Professional developers recognize the necessity of ALM functionality: clear requirements gathering, bug tracking, source control, testing and profiling. But when you're actually writing code, no software product in these areas will help you build something better. I'm not going to build a better product simply because bugs are stored in some integrated fashion vs. Bugzilla or Mantis or notepad?
Sure, I can make the argument that using source control makes me more aggressive in my refactorings because I know I can always rollback those changes. That's why I always use source control, but it doesn't have to be integrated. I can also make the argument that writing test cases and client code first yield to better overall quality. But DUnit doesn't have to be integrated. These aren't things that are going to be made better by ALM integration. These are things that require a certain amount of developer discipline and experience.
Ok, so after all this, what does it mean for Delphi? Borland's ALM strategy doesn't have a long-term place for Delphi as we know it. In the short-term, I suspect that the Delphi R&D team will work their butts off and try their best to justify BDS' existence in Borland's ALM strategy. We'll see a few more releases, Highlander will be the last.
From an ALM business perspective, I really don't see the value in BDS and Delphi. So we'll never see any significant investment into something like a native 64-bit compiler...ever. Kiss that goodbye. Get over it.
I love Delphi, so I think a change is needed. It's time to spin Delphi off and let it live or die on its own merits. If Borland keeps Delphi, it will milk it for all its worth to fund their ALM stuff. Sad, but true. I'm not in denial anymore.
Write a comment
- Required fields are marked with *.