Wither Oracle, SAP, et al? (Pt 2)

Enterprise software vendors face some tough decisions. In Pt 1, I focused on license revenue vs maintenance/services. Pt 2 is about depth of infrastructure:

Stack or platform? Oracle is "missing an operating system," CEO Larry Ellison told the Financial Times last week. He went on to dismiss the notion of buying Red Hat, but made it clear that Oracle is determined to acquire the necessary skills to offer Linux so that customers will be able to buy a complete soup-to-nuts infrastructure-and-applications stack from the company.

SAP blogger Jeff Nolan reports that SAP executive board member Shai Agassi completely dismisses this approach:If they really want a single throat to choke, they'd much rather go to IBM "Shai said emphatically that 'we are not a platform company, we’re an application company'." Although as Nolan goes on to point out, that's not exactly what Agassi means, if you consider that SAP's NetWeaver strategy is all about building an application platform. The point is that it stops at the layer of application infrastructure: there's no operating system, there's no database, and in the fullness of time there won't be an application server either. But there will be a lot of middleware, designed to support a network of software services that interact to provide composite applications. It's a platform, but not a complete top-to-bottom stack like the one that Oracle aims to offer.

Of course, it was inevitable that each company would adopt its chosen direction. Oracle already offers a database and an application server. That's its core business. It would be folly not to add the option of an operating system — especially when more and more of its customers are adopting open-source platforms anyway. It neatly completes Oracle's story as an infrastructure provider. But I suspect it will undermine its proposition as an application provider, so although it's the right choice from an infrastructure point of view, it could be an almightly strategic error from an applications point of view.

I know that Oracle's argument is about customers preferring 'one throat to choke'. Generally speaking, they do. It's a lot of hassle if you have a myriad of different suppliers to deal with, especially if there's plenty of scope for each of them to blame the other each time something goes wrong. But customers also prefer competition. So the saying would be more accurate if it went something like this (if you'll excuse the marginally gruesome mixed metaphor at the end):

'Customers prefer no more than four, and never less than two, throats to choke — even if there is only one, they'll always keep a second one waiting in the wings just to keep the other on its toes.'

There are some customers for whom Oracle's proposition will appeal, but most will have misgivings about entrusting absolutely everything to a single proprietary vendor. If they really want a single throat to choke, they'd much rather go to IBM, say, and still have some choice as to which applications they adopt (unless the rumors are true and IBM is going to buy SAP, which would really shake things up).

The key question still hanging over this discussion, though, is where will customers draw the line? SAP's strategy is betting that customers will consider application infrastructure as part of their applications. Fair enough, they always have. But what if that changes as we move to a services-based architecture? If the applications are formed out of services, there's no longer any point in considering the platform on which those services are based as being anything other than a single stack (especially if, as seems likely, more and more of it is open-source). System services like integration, identity, security and so on will no longer form part of the applications, they will be part of the underlying infrastructure. Many customers will prefer to buy all of that underlying infrastructure from a single source, while going elsewhere for the applications. If that's where the line is drawn, it cuts straight across the middle of SAP's application-platform offering.

This rather neatly brings me to the third choice facing vendors, which really takes us to the heart of what an application actually is. That's coming up in my next posting.