SAP promises to deliver 'Big SOA' -- then what?

SAP will be able to move thousands of customers to SOA quickly. But what happens when they taste freedom?

ZDNet blogging colleague Dan Farber recently spoke with Shai Agassi, president of SAP's product and technology group, about SAP's emerging SOA strategy, who promised that SAP would be leading the enterprise SOA market by the end of 2007.

SAP will be able to move thousands of customers to SOA quickly. But what happens when they taste freedom?

SAP's intentions are ambitious -- Agassi plans to move 10,000 customers running on SAP's SOA-enabling NetWeaver middleware platform within the year. Agassi told Dan that by that time SAP expects to have reached a tipping point, in its favor, for its services-enabled ERP platform and ecosystem, through its base of mySAP ERP 2005 customers, Web services and xApps.

Can they do it, logistically? I think they can. But the $64 million (or make that billion) question is, should SAP competitors be running scared, or is SAP running scared? 

First, the logistics. Jeff Nolan, a former SAPper himself, noted in his own analysis that there are 400 customers on SAP's SOA platform today, and "considering that the existing customer base is not beating down the doors to get the upgrade, I just don’t see how you could possibly sell and install 1/3 of the entire customer base in a year." But Nolan adds that's he's reserving judgement, and will wait and see what happens a year from now.

But I don't doubt SAP can move this mountain if it wants to. For a large vendor with lots of resources, it's no biggie. I've seen IBM move far more than 10,000 customers on various platforms countless times to new technologies with barely a hiccup. For example, back in the late 1990s, I watched Big Blue move a good chunk of its iSeries base from 32-bit to 64-bit computing without a whimper and almost no fanfare -- while the rest of the world  struggles to catch up with 64-bit computing to this day. So if a vendor with a locked-in customer base can offer a compelling upgrade to a SOA-enabled stack without breaking any current implementations, then go forth and multiply.

SAP's customers rely heavily on the vendor for mission-critical applications. Any attempt switch away from the big vendor is a non-trivial task. But the long-term question for SAP and other large application vendors goes to the very nature of SOA: applications are gradually being broken down into what are essentially hot-swappable application components. What happens when customers get a taste of the "freedom" from the single-vendor locked-in, complex applications they had learned to live with for so long?

Companies are already finding it more cost-effective to move certain pieces of applications to a standardized middleware stack than go through major back-end upgrades. SAP knows this, and Oracle knows this. As I have observed in previous posts to this blog (here and here, for example), I am aware of companies that have taken the SOA middleware route as an end-run around complex back-end ERP systems. 

AMR's Bruce Richardson even went so far to say that SOA will kill off ERP -- at least as we know it in its large form factor -- within the next ten years.

Jeff Nolan observes that large vendors such as SAP is that they are built on a "culture of complexity" -- the antithesis of what SOA is supposed to be all about:

"...big enterprise software vendors have increasingly been unable to 'do anything simple.' It’s not that there are teams of seasoned developers sitting around suggesting ways to make things more complex, but there is a pervasive culture in these companies that values complexity over simplicity as proxy for 'value creation.' The belief is that a complex technology stack represents a competitive barrier and the ability to lock in customers, and quite honestly it has worked as a strategy.

Nolan adds that the foundation of SOA -- "a standardization of application protocols and the holy grail of software, interoperability without penalty" -- is a trend that has legs. "This stuff really does work and will get better with age, and it either promises or threatens, depending on your vantage point, to reshape the industry as we know it."

Jeff Nolan also sees the shift away from complex, locked-in back-end systems to a more flexible middleware service layers:

"The irony in our current market is that the big SOA platforms end up driving not a technology shift that fuels a new wave of growth, but a business model shift as a result of the decoupling of a tightly integrated suite of applications into a loosely coupled repository of services. Customers will be able to substitute services and drive their own solutions offerings 'at the edge' in a way that is reminiscent of best of breed." 

SAP, as does Oracle, knows that to remain a player, it needs to embrace SOA, and to any extent possible, have customers doing SOA their way. But this brings into conflict the idea of Big SOA versus Incremental SOA. As I've said in a previous post, Oracle is about Big SOA, and the same goes for SAP -- Big SOA. "Sure, go ahead, take your huge back-end system, and move some of that functionality out to a service layer -- preferably ours." An incremental SOA approach, of course, would see a lessening of the influence of large vendors.