License vs. Service and Support Revenue: Some Historical Clarity

A blogger I honestly have never heard of in my 25+ year in high tech has used his 30+ year in high tech to claim that “tech journalist” Bob Evans is recirculating a “meme” that Bob is writing because he is both lazy and ill-informed about the historical revenue split between new license revenues and service and support revenues in enterprise software.

I’ll try to skip discussing Bob’s alleged laziness as unworthy of comment, except to say that the blogger, Dennis Byron, ironically claims that Bob is lazily recycling old material, and to support his claim Byron gleefully recycles so much of a previous post that it takes up fully half of his new post. ‘Nuff said.

The laziness comment is also pointless because Byron’s main point, that the fact that software companies’ practice of gleaning a majority of their revenues from service and support — one of the points of Bob’s recent post —  is “decades old”, is  patently false. Actually, as someone who has covered this issue very closely for decades myself, the trend in enterprise software through the end of the last decade was that license revenues often outstripped service and support revenues by a factor of two or more.

The dotcom bust and the subsequent recession, less than a decade ago, began a significant restructuring  of this revenue split, but up until then enterprise software companies prided themselves on having a much larger proportion of license revenues to service and support revenues. It was only as growth slowed down that the annuity value of service and support began to be seen as a key element in company longevity and stability.

What Byron forgets or never knew in the first place is that, until the last decade, the number one metric for a successful enterprise software company, especially publicly-traded ones, was customer growth. He does acknowledge that only  fast growing companies have more license than service and support revenues. But what he seems not to realize is that what we consider the enterprise software market today largely didn’t exist when Bob and I started our careers in the 1980s, and that the companies in that sector today were on a fast growth path until, as I stated, the last recession. That meant customer acquisition was job number one, and the revenue split reflected that. The change Bob is referring to happened not decades ago, to reiterate, but barely one decade ago at best.

Lazy is as lazy does.

The Return of Business ByDesign and the Future of the On-Demand ERP Market

It’s tough being SAP’s forthcoming Business ByDesign in an unforgiving market. Having been launched and then pulled back, re-designed and then offered back to a market that is a little more jaded, a lot more cautious, and desperately trying to sort out what’s happening in this global recession, the ByD team is facing an almost unprecedented quantity of challenge, skepticism, and even ridicule.

The rumor mill has been most unkind of late: Rumors have been flying that ByD is going to miss its latest release date, that its marketing plans are DOA, and that SAP is on the verge of laying an egg of colossal size and impact.

The rancor surrounding the July 31 release date of the new ByD reflects a complex history inside SAP and the on-demand market that has clouded a lot of otherwise objective analysis about its prospects, and how important ByD’s success is not just for SAP and its customers, but for the on-demand market as a whole.

Let’s start with some rumor control. I spoke recently to Doug Merritt, the SAP EVP tasked with bringing ByD and the other on-demand products to market. Doug confirmed that ByD has slipped a whole two weeks in its release date, from mid-July to the end of July. And, while QA could still conceivably find something that would delay its release further, at this point that’s a pretty long shot. NBD.

As for the GTM strategy being DOA, it’s actually alive and well, and in a deliberate go-slow mode. Deliberate is the operative word: SAP is trying to do the ByD rollout slowly and carefully. And differently, as evidenced by this YouTube ad.

The ad is worth watching for two reasons. First, it’s really different than most of what you see SAP doing in the marketing of its products. Refreshingly different. And that includes taking a swipe at “heavy duty” ERP in the process, despite SAP’s deserved reputation as one of the major purveyors of  heavy duty ERP.

The second is that it’s amazingly effective: a posting on this video in the Enterprise Irregulars bloggers group created a thread that has been bouncing back and forth across ByD and related topics for two days. You might think the ad is silly, trivial, pitiful, refreshing, courageous, or clever, but it does get people thinking, even a group of professional skeptics and curmudgeons like EI.

The other point worth addressing about ByD is that its initial entrance to the market in 2007 came in the midst of a not-so-private battle between ByD’s main advocate, Peter Zencke, and fellow board member Shai Agassi, who wanted the concepts of ByD – model-driven, on-demand ERP – to be embodied in the main SAP suite instead of in a completely new, mid-market product. That battle at the top eventually led to Shai’s departure – Zencke left shortly thereafter – but it left a bad taste in many SAPers’ mouths for the product. The fact that it failed to be economically viable as an on-demand product in its initial release further fueled the ire of its detractors.

This internal “polemic”, to be polite about it, reminds me of what Microsoft has been going through in the years since Ray Ozzie first discussed Software + Services as the new direction for Microsoft. Even an outsider can imagine the screaming inside Microsoft about such a radical shift and what it would mean to the king of the desktops. The fact that Steve Ballmer felt compelled three years later to give his now-famous “We’re All In” speech is testimony to how hard it’s been internally for Microsoft to grapple with this paradigm shift.

And the fact that “We’re All In” has become a catch-phrase repeated, mantra-like, at every Microsoft event I’ve been to – it’s even a tag line on Microsoft email messages – speaks not just to the level of commitment at the top of Microsoft but to the acknowledgement that getting everyone singing from the same hymnal requires lots and lots of practice.

SAP is facing a similar dilemma with ByD. Everything about it – on-demand but not true multi-tenant, requires a major channel that doesn’t exist yet, the potential for cannibalization of other products, the sordid release history, the bad blood inside SAP – means that SAP has a similar requirement to make sure that everyone is walking the walk and talking the talk.

With so much at stake, it’s clear that ByD will be one of the great inflection points in the history of enterprise software, and in many ways its success or failure will define the future of on-demand enterprise software for some time. ByD isn’t just a gamble that SAP can create a product like ByD, it’s also a gamble that there is actually a market out there for what ByD represents. This fact is hardly a given: NetSuite’s struggles to meet its market potential has given many proponents of on-demand ERP pause, as has Workday’s slow slow progress towards a critical mass of customers.

Of course there is, among others, but I would argue SFDC really hasn’t succeeded in defining a major market opportunity outside of SFA, while everyone else is busy creating markets that aren’t necessarily of the size and scope that means on-demand ERP has really arrived.

If SAP can pull off ByD, that success will create a huge opportunity for others, including NetSuite, by legitimizing a market that to date doesn’t really exist as a billion-plus dollar opportunity. If SAP fails, I fear that this much-needed capability will languish on the sidelines another four or five years, and customers will be all the poorer, literally and figuratively, for that failure.

So, baring some unforeseen glitch, ByD re-enters the market in one short week. Its success or failure will hinge on a number of factors, most important of which will be the SDK that comes out at the end of the year. This is going to be one of the most closely watched software rollouts in a long time, with its repercussions felt across the industry for years to come.

Alea jacta est.

Collaboration Tools : SharePoint = Enterprise Apps : Excel

As I sat through an overview of one of the latest collaboration tools on the market, a product called Spaces from nGenera, I began to have a deja-vu all over again moment. The discussion centered around the unique value proposition that nGenera was putting forth in the product, and, while the arguments behind them were convincing, I couldn’t help think of the half-dozen projects I had recently seen or been involved in that tried to accomplish much of the same functionality using Microsoft’s increasingly ubiquitous SharePoint.

And then it dawned on me: SharePoint has become the Excel of the collaboration space, the apex predator in a growing jungle of tools and offerings that are scrambling to capture scarce resources and developer mindshare as enterprises build out their nascent collaboration functions.

This Excel-like status is not to be trifled with: I always caution my vendor clients to be aware that, however cool and compelling their innovative products are, their number one competitor is likely to be an Excel spreadsheet, as well-worn and as shaggy as your dad’s favorite briefcase, that the users are likely to give up only when pried from their cold, dead fingers. This is one of the classic dilemmas facing all innovators: how to get people to actually use truly innovative products when there’s some good enough, tried and true solution already in place.

The good news for nGenera and other companies in this space, including SAP’s StreamWorks, is that the SharePoint advantage today is mostly a developer advantage, not an end-user advantage. Pretty much every SharePoint end-user I know has no idea they are looking at SharePoint, whereas as Excel’s end-user identification powers are so strong that in Germany a spreadsheet is called an Excel (pronounced axle, in case you hear someone using the word and wonder how the conversation just switched to cars.)

This removes the need to worry about prying and cold, dead fingers, but that’s only on the end-user side. The developer community has similar prejudices, and most developers who have built collaboration tools using SharePoint are inclined to do it again. This is in part due to the excellence of SharePoint as a developer environment, and in part due to the excellence of SharePoint as a developer resource billable hour generator: end-user tool it is not.

Which means that, like the classic enterprise apps market, products like Spaces have to be sold to the end-users, preferably warm and alive, in hopes that they will obviate the need for developers enamored with SharePoint to get involved and start recommending their favorite tool.

That end-user evangelism requirement is tricky in the classic enterprise apps market, it’s even trickier in a nascent collaboration tools market. As I have opined before, we are not born with a lot of collaboration skills, and while everyone hears the collaboration drum beat load and clear, few people actually know what a collaborative project or process really should look like. This begs the need for templates and how-to-do-it tools, inside Spaces or StreamWorks or any other collaboration tool, that provides examples how collaboration really works.

Anyone  who doubts this requirement needs to sit in on a volunteer or non-profit organization and watch how things don’t get done: despite the very best of intentions, homo sapiens’ social development didn’t get as far up the evolutionary tree as it could have.

nGenera definitely gets this requirement, and is promising to build out the best practices for collaboration in addition to providing advisory services to its customers. In many ways I believe it will be these secondary services that will make or break any individual tool. The collaboration market is new enough that the successful pioneers will also be the successful teachers.

To do otherwise is to cede the market to SharePoint and an army of willing SharePoint programmers. The trick is to get out there with the how-to tools before the developers get the upper hand. Otherwise Collaboration Tools: SharePoint = Enterprise Apps: Excel will be a formula to rule for many years to come.

How to Make Money in the Cloud: Microsoft, SAP, the Partner Dilemma and The Tools Solution

It’s cloud’s illusions I recall, I really don’t know clouds at all…..

One of the primary devils in the details with cloud computing will always be found in the chase for margins, and this is becoming abundantly clear for Microsoft’s market-leading partner ecosystem, gathered this week in Washington, DC. for their Worldwide Partner Conference. Chief cheerleader Steve Ballmer repeated the standard mantra about how great life will be in the cloud, something I tend to agree with. But missing from Ballmer’s talk was the money quote for Microsoft’s partners:  “…..and here’s how, once we’ve stripped the implementation and maintenance revenue from your business, you’ll be able to make a decent margin on your cloud business.”

More than the coolness of the technology, it’s the coolness of the possibility for profit margins that will make or break Microsoft Azure and any other vendor’s cloud or cloud offering. This is hardly just Microsoft’s problem, SAP has grappled with this margin problem as it has moved in fits and starts towards this year’s re-launch of Business ByDesign. And it’s top of mind across the growing legions of ISVs and developers looking at what they can do to capitalize on this tectonic shift in the marketplace.

The trick with chasing cloud margins is that the chase dovetails nicely with a concept I have been touting for a while, the value-added SaaS opportunity. What is obvious from watching Ballmer and his colleagues discuss the future according to Azure is that much of the profits to be gained from moving existing applications and services into the cloud will largely go to Microsoft. That’s the first generation SaaS opportunity – save money by flipping existing applications to the cloud and reap the economies of the scale inherent in consolidating maintenance, hardware, and support costs. To the owner of the cloud goes the spoils.

This is the same issue, by the way, bedeviling SAP’s By Design: SAP will run its own ByD cloud services, and in doing so, assuming that the problems with the cost-effectiveness of ByD have been full resolved, sop up the first order profits inherent in the economies of scale of the cloud. How SAP’s partners will make the healthy margins they need to be in the game with SAP has been, in retrospect, a bigger problem than the technology issues that stymied ByD’s initial release. And, by the way, thinking that value-added partners – the smart, savvy ones SAP wants to have on board selling ByD – will be happy with a volume business won’t cut it. Smart and savvy won’t be interested in volume, IMO.

But there is an answer to the answer that will appeal to everyone:  build net new apps that, in the words of Bob Muglia, president of Microsoft’s server and tools business, weren’t possible before. This act of creation is where the margins will come from. And the trick for partners of  any cloud company is how easy the consummation of this act of creation will be.

The easiest way to do for partners to create this class of apps is for the vendor to offer the highest level of abstraction possible: from a partner/developer standpoint, this means providing, out of the box and in the most consumable manner possible, a broad palate of business-ready services that form the building blocks for net new apps.

Microsoft is starting to do this, and Muglia showed off Dallas, a data set access service that can find publicly and privately available data sets and serve up the data in an Azure application, as an example of what this means. As Azure matures, bits and pieces of Microsoft Dynamics will be available for use in value-added applications, along with value-added services for procurement, credit card banking, and other business services.

This need for value-added apps then begs two important questions for Microsoft and the rest of the market: question one is what is the basic toolset to be used to get value-added SaaS app development started? And question two: who, as in what kind of developer/partner, is best qualified to build these value-added apps?

I’ll start with the second question first. I have maintained for a while that, when it comes to the Microsoft partner ecosystem, it’s going to be up to the Dynamics partners to build the rich, enterprise-class applications that will help define this value-added cloud opportunity. The main reason for this is that the largest cloud opportunity will lie in vertical, industry-specific applications that require deep enterprise domain knowledge. This is the same class of partner SAP will need for ByD as well.

Certainly there will be opportunities for the almost all of the 9 million Microsoft developers out there, especially when it comes to integrating the increasingly complex Microsoft product set – Sharepoint. SQL Server, Communications Server, etc. – into the new cloud-based opportunities.

But with more of the plumbing and integration built into Azure, those skills, like the products they are focused on, will become commoditized and begin to wane in importance and value, and therefore limit the ability of these skills to contribute to strong margins.

The skills that will rise like crème to the top will be line of business and industry skills that can serve as the starting point for creating new applications that fill in the still gaping white spaces in enterprise functionality. Those skills are the natural bailiwick of many, but not all, Dynamics partners: Microsoft, like every other channel company, has its share of great partners and not so great partners, depending on the criteria one uses to measure channel partner greatness. Increasingly, in the case of Azure, that greatness will be defined by an ability to create and deliver line of business apps, running in Azure, that meet specific line of business requirements.

The second skillset, really more ancillary than completely orthogonal to the first, involves imagining, and then creating, the apps “that have never been built before.” This may task even the best and brightest of the Dynamics partners, in part because many of these unseen apps will take a network approach to business requirements that isn’t necessarily well-understood in the market. There’s a lot of innovative business thinking that goes into building an app like that, the kind found more often in start-ups than in existing businesses, but either way it will be this class of app that makes Azure really shine.

Back to toolset question: Microsoft knows no shortage of development tools under Muglia’s bailiwick, but there’s one that comes from his colleague  Stephen Elop’s Business Solutions group that is among the best-suited for the job. Muglia somewhat obliquely acknowledged when I asked him directly that this tool would one day be part of the Azure toolset, but it’s clear we disagree about how important that toolset is.

The toolset in question is xRM, the extended CRM development environment that Elop’s Dynamics team has been seeding the market with for a number of years. xRM is nothing short of one of the more exciting ways to develop applications, based on a CRM-like model, that can be run on premise, on-line today, and on Azure next year. While there are many things one can’t do with xRM, and which therefore require some of Muglia’s Visual Studio tools, Microsoft customers today are building amazingly functional apps in a multitude of industries using xRM.

The beauty of xRM is that development can start at a much higher level of abstraction than is possible with a Visual Studio-like environment. This is due to the fact that it offers up the existing services of Dynamics CRM, from security to workflow to data structures, as development building blocks for the xRM developer. One partner at the conference told me that his team can deliver finished apps more than five times faster with xRM than with Visual Studio, which either means he can put in more features or use up less time or money. Either one looks pretty good to me.

The success of xRM is important not just for Microsoft’s channel partners: the ones who work with xRM fully understand its value in domains such as Azure. xRM is also defines a model for solving SAP’s channel dilemma as well for ByD. The good news for SAP is that ByD will have an xRM-like development environment by year’s end, one that can theoretically tap into a richer palate of processes via ByD than xRM can via Dynamics CRM.

Of course, xRM has had a double head start: it’s widely used in the market, and there’s a few thousand partners who know how to deploy it. And xRM developers will have the opportunity when Dynamics CRM 2011 is released (in 2011, duh) of literally throwing a switch and deploying their on premise or in the cloud. Thus far, ByD’s SDK only targets on-demand deployments. And there are precious few ByD partners today, and no one has any serious experience building ByD apps.

What’s interesting for the market is that xRM and its ByD equivalent both represent fast-track innovation options that can head straight to the cloud. This ability to innovate on top of the commodity layer that Azure and the like provide is essential to the success of Microsoft’s and SAP’s cloud strategies. Providing partners and developers with a way to actually make money removes an important barrier to entry, and in the process opens up an important new avenue for delivering innovation to customers. Value-added SaaS apps are the future of innovation, and tools like xRM are the way to deliver them.  Every cloud  has a silver lining: tools like xRM hold the promise of making  that lining solid gold.

The IBM/SAP/Oracle/HP Show: ALM and the Struggle for Lower TCO and Better Account Control

Big company battles, like real-world battles between countries, often center around obscure points of friction. The Austro-Prussian war had its Schleswig-Holstein, the Vietnam war had the Gulf of Tonkin incident, and enterprise software has application lifecycle management. ALM today is a relatively obscure point of friction between giants that holds the promise of igniting global conflict if… things either get out of hand or go exactly as planned, depending on one’s perspective.

The warring parties circling around the issue of ALM can definitely promise global conflict if that is what actually happens – no less than IBM, SAP, Hewlett-Packard, and Oracle, to name only the biggest, are angling for position in the ALM space as a means to not just make some serious money, but reap enormous benefits in terms of added account control. Oh yes, and do something positive for their customers as well.

What is likely to happen is a further refinement in the on-going coopetition derby now playing out in the enterprise software space. My guess is that some partnerships will be strengthened – SAP and HP definitely,  SAP and IBM maybe, while other competitive lines will drawn with an even thicker marker: SAP vs Oracle (of course), Oracle vs. IBM (in case Larry hasn’t made it clear enough), HP vs.  IBM (duh!) and, most likely as well, HP vs. Oracle.

Regardless of where the lines are finally drawn, it’s clear that, even as the industry fears that industry consolidation means less innovation, the continually shifting sands around ALM are an example of how when allegedly big, slow, and indifferent industry giants start dancing, customers actually stand to benefit.

Here’s the issue in a nutshell: It’s increasingly expensive and complex to run large enterprise software implementations, particularly for global companies managing heterogeneous environments. Total cost of ownership is elusive, and the push for more upgrades from the vendors threatens to further increase TCO – any potential functional benefits to end-users from upgrades notwithstanding.

ALM has emerged as a way to tackle the problem – better lifecycle management, aided and abetted by better tools, means that companies can fine tune their implementations and upgrades to avoid waste, trim unneeded resources, rationalize overly complex portfolios, and otherwise run a tighter ship. Easy, right?

Like many things in life, ALM is great as a theory, but customers run into all sorts of problems trying to actually do something about it, so many that it’s hard to find where to start. Heterogeneity is one of the big problems – managing the lifecycle of one app is tough, dozens or even hundreds of interoperating applications is an absolute nightmare to manage. Vendor lock-in is another: SAP’s Solution Manager is the premier tool for SAP, but doesn’t do anything to manage how PeopleSoft HR or Siebel CRM interoperate with SAP. And SAP guards its SolMan interfaces carefully, so that using third party tools to access SolMan and thereby access the keys to the SAP ALM kingdom is not something that just any partner or product can do.

Cost and complexity is another major problem: ALM approaches are traditionally people-centric and therefore expensive, and therefore form a hugely profitable business for the global systems integrators that do the lion’s share of the ALM work. The historic price tags have been eroded by the emergence of a panoply of tools – IntelliCorp and Panaya in the SAP space, for example – but getting customers, and more importantly, global SIs to adopt the most effective of these tools is like getting a government bureaucrat to sign off on eliminating his own budget. Never very easy, however much sense it might make in the long run.

So, enter the four horsemen of the ALM world. SAP  has the customer base and the toolkit, SolMan, that its customers and partners love to hate. SolMan is big, complex, expensive to implement, and amazingly effective if only more customers would actually use it to its fullest. Oracle has another big, inherently heterogeneous customer base and a weaker set of tools – and therefore a much more open approach to ALM that invites partners to dig inside the inner workings of its eBusiness Suite in ways that would make SAP blanche.

IBM is in ALM in the dual role of tools provider – the Rational toolset, born like WebSphere from myriad acquisitions and technology roll-ups, is one of the best in the business – and as systems integrator, the latter role being the much more profitable and strategic and therefore influential inside IBM. HP plays in the ALM sandbox in two roles as well: tools provider (its testing tools are considered the industry standard as well) and systems integrator in the form of its EDS subsidiary.

What all these companies are jockeying for simultaneously, and in contradiction to each other, is the right to be the go-to-partner of choice for tools and services, and at the same time use their ALM efforts to maintain or expand whatever level of account control they currently hold. Wherein lies the complexity of the conflict.

Let’s start with IBM. If you’re IBM’s Rational tools group, you want everyone – SI partners like Accenture as well as IBM Global Services – to use your tools to work with SAP and Oracle, and anything else. But, as a good partner, particularly to SAP, you want to make sure that SAP’s Solution Manager is also in the mix – otherwise SAP would try to shut Rational out of the SAP market.

But if you’re IBM Global Services you want to use Rational and SolMan and anything else you can get your hands on to “rationalize” the SAP customer base, commoditize SAP’s Business Suite, and drive all innovation through Global Services in the form of custom applications, thus obviating SAP as an innovator. The less the customer ends up seeing of SAP or Oracle, the better. This Global Services vision is similar to conservative Grover Norquist’s infamous (IMO) vision for shrinking government “down to the size where we can drown it in the bathtub.” And to the survivor goes the account control.

Needless to say, this plays really poorly in SAP land. One of the tricks to IBM GS’ vision is getting access to the interfaces used by SolMan to manage an SAP installation. SAP has continued to rebuff attempts by IBM to have this access, for fear that once those interfaces are open and available, IBM (or anyone else) can pretty much obviate the need for SolMan, and thereby undermine SAP’s account control and its entire ALM and global support strategy, both of which place SolMan front and center as the key to the kingdom.

But, and there will be many more buts in this story, SAP and IBM need each other more and more, and the reason is a determined competitor named Oracle. Until the Sun acquisition, I had always assumed that Larry Ellison had wanted to get closer to IBM – and indeed most of his major acquisitions have included a huge IBM customer base. Now the blush is off the rose, and Larry’s full-throated attacks on IBM are helping to drive Big Blue closer to SAP, even as the plot in the ALM conflagration thickens. So, SAP and IBM, even as they are dancing around the ALM question, are convening summits and getting CTOs together to talk about strategic interests, among them what to do about Oracle.

In this light, don’t expect Oracle’s position in the market be simple and easy to understand. Clearly, Larry hasn’t left a lot of doubt whom he sees as Oracle enemy number one (today). But, meanwhile, IBM Rational is courting Oracle’s eBusiness Suite (EBS) customers with a similar rationalization/TCO message that it has for SAP’s customers. With a twist: there is no gatekeeper SolMan equivalent at Oracle, and Oracle’s more open architecture means that Rational is able to do its work inside the EBS customer base without some of the problems it has inside SAP’s market. And, at least according to IBM Rational, Oracle is responsive and interested in further collaboration in ALM.

Of course, IBM Global Service’s vision for SAP works just as well in the Oracle market – or even better, as Oracle’s portfolio is by nature heterogeneous and will remain so for the foreseeable future. While Fusion Apps will hit the market this year, their initial usage as a best-of-breed stable for existing customers means that the heterogeneity of the Oracle customer base will only grow, and with it IBM Global Service’s interest in helping rationalize (can’t help using that word at least five times in this post) the complexity of these customers’ environments.

Getting a headache yet? Then there’s HP: Sworn enemy of IBM, newly dissed partner of Oracle (it’s a hardware thing), and top tools and implementation partner of SAP. HP is breathing new life into its Mercury testing tools line, and positioning itself to be a stronger partner to SAP. All indications are that SAP is biting, and that the two companies are finding a lot more common ground than they have in the past.

Part of this is what I hope is a realization at HP that it better get on the ball and pay a lot more attention to the enterprise software market – it’s not a coincidence that two of the biggest acquisitions in the industry, Sun and Sybase, both had a lack of understanding of enterprise software at the core of their unfulfilled positions as long-standing market leaders. HP has historically fumbled that role too, but the company seems to be showing a renewed understanding of its role in the enterprise software market, and if this understanding can be translated into action, HP’s role in the ALM mix will only grow (especially with EDS under its wing.)

Where does this migraine-inducing pas de quatre leave the customer? I believe somewhere between hell and the catbird’s seat. Hell comes in the person of the sales rep trying to convince the customer that ALM is easy and that there’s a single, easy to rationalize, decision on what the right tool and approach is. This is clearly an option-overload situation, and if you didn’t get a headache reading this post you’re sure to get one trying to sort through the options faced by a typical global company that very likely has all four Horsemen of ALM vying for a piece of the IT budget.

Seeing the customer in the catbird’s seat comes, of course, from the scramble for advantage among these companies and the very option overload it has created. What I’m seeing from my version of the catbird’s seat is a ton of innovation inside these four companies, and many others, as the opportunity for ALM riches and account control beckon.

SAP is beefing up not only SolMan but other parts of its toolset like Business Process Change Analyzer, which is trying to get a leg up against IntelliCorp’s LiveCompare, a tool much in favor in the SAP customer base. IBM Engineering is building technology workbenches for its SI partners, and Global Services,  to help package ALM services to the SAP and Oracle customers. Oracle is pushing forward its support of IBM Jazz (though not officially on the Oracle website) and further opening up its apps to third party ALM tools. HP is upgrading its testing tools (they have an on-demand version of LoadRunner that runs in Amazon’s cloud, taking a page from Panaya’s cloud-based upgrade services). And on and on.

How this will all settle out is a guessing game today, but I believe we’re talking about a long-running but low-level global conflict that actually promises to make the world a better place one day. I think that in the end IBM and SAP will get closer on the ALM front and the anti-Oracle front, but never so close as to hand the keys to the customer base – those SolMan APIs – to Global Services. HP and SAP will get closer too, and HP will continue to play counter-weight to IBM in the SAP world. In fact, my sense is that HP/SAP may be a faster and closer alliance than IBM/SAP in the next few years, based on the problem that Global Services presents.

Meanwhile,. Oracle will continue to be the company to watch as its post-Sun acquisition posturing gives way to a more carefully articulated market position. Like its software rival, SAP, it has reasons to be allied with the HP and IBM, and SAP too, if only for expediency’s sake. But with planning for September’s Oracle Open World now in progress, how Oracle will define itself in the market is becoming more than of academic interest. With ALM an even bigger problem in the Oracle customer base than in the SAP base, how Oracle responds to the ALM issue will have a major impact on what the marketplace looks like once the dust begins to settle.

So, as with any truly monumental conflict, it’s impossible to tell by the early skirmishes who in the long run will prevail. What’s clear is that this battle will go on for a while, and the casualties will start to pile up. But, if customers play their cards right, there’s definitely room for their budgets and portfolios to come out on top. The market may be confusing now, but there’s a method to this madness. Stay tuned as we all try to sort it out.