SAP's services roadmap

Since I'm frequently less than kind to SAP, for once let me hand out some plaudits to the company on the heels of its acquisition of Frictionless Commerce last week. Its pragmatic approach to software services may not be one that I agree with, but if I were running SAP, it's pretty much exactly the strategy I'd be following, too.

I use the term 'software services' deliberately. SAP's moves into the SaaS space have to be viewed within a much broader context,SAP is taking a more difficult (and courageous) route the most important of which is the Enterprise Services Architecture (ESA) strategy with the NetWeaver platform at its core. SAP is moving its entire application stack to a services architecture. Whether individual services or applications within that overall architecture are hosted externally or on-premises is ultimately irrelevant (if you wanted to be clever, you might say, 'neither here nor there'). The most important milestone to pass is service-enablement (which is why SAP is so eager to persuade its customers — or some of them at least — to upgrade to the NetWeaver platform). Worry about where to host the services later.

The acquisition of Frictionless doubles the number of applications that SAP now offers on-demand from one (CRM) to two (adding supplier relationship management — SRM). But that wasn't SAP's motive, which Procurement Central blogger Dave Stephens nailed in a short posting last week: SAP SRM finally has Sourcing & Contracts. The point of the deal is to add vital missing functionality to SAP's SRM offering. Further analysis posted by spend management blogger Jason Busch and AMR analyst Mickey North Rizza reveals that:

• Frictionless was in trouble and so it seems SAP was able to buy cheaply;
• It wasn't the most sophisticated offering in the market but is the most open to customization;
• Most vendors offering this type of functionality do it on-demand.

That final point is significant: SAP has bought an on-demand vendor because it needed to offer the functionality, not because of an explicit strategy to embrace on-demand. I made the point when writing about the choices facing enterprise software vendors last month: on-demand is particularly well suited to applications that require "the ability to bring together functionality and information from many different external services and link it into the enterprise application infrastructure." As SAP deepens its functionality in these kinds of application areas, the more entangled it will become with on-demand offerings.

Indeed, this was already visible last week in several partner announcements. A second posting by Jason Busch highlighted Ariba's NetWeaver certification for its supplier network (ASN):

"... pre-integrated supplier network connectivity via the ASN will go a long way to helping existing SAP SRM customers get the most out of their eProcurement investments. Why does network-based supplier connectivity matter? According to Aberdeen, a typical eProcurement implementation has 253 suppliers enabled, but the average ASN user has over 600 connections (but greater than 50% of ASN customers have more than 1,000 suppliers connected)."

Another new partnership was with Emptoris, the Frictionless rival that SAP presumably found too expensive to buy, but whose offering is apparently more highly rated by most observers.

The story behind these partnerships brings us back to the NetWeaver and ESA context that I mentioned earlier. On-demand vendors are natural partners for the NetWeaver environment because they are natively service-oriented. SAP's shift towards a services-based architecture is destined to bring large numbers of on-demand vendors into its ecosystem, whatever SAP thinks of the model.

(By the way, now that SAP has bought one of its partners, that ecosystem will now become even more attractive to VC-funded players. And just in case it doesn't, SAP has simultaneously announced a new fund of its own to invest in companies in the NetWeaver ecosystem).

So SAP's strategy in relation to on-demand is to embrace the model where market conditions dictate. Either in response to a competitive environment where customers are asking for on-demand (as in CRM) or where it offers more cost-effective and manageable functionality than on-premises alternatives (as in these SRM examples). Obviously the two factors will frequently overlap.

My point of disagreement with SAP is its view that on-demand is no more or less than a deployment option. Hence SAP board member Leo Apotheker's comment, reported by Zoli Erdos "over time all SAP's offering will be made available in the 'hybrid' model," which allows customers to slip at will from on-premises software to a hosted service and then back again at some later date (a notion that Bill Gates calls 'server=service'). If only it were that easy.

In the long run, though, it doesn't matter, because SAP is committed to a services architecture anyway. It's just taking a more difficult (and courageous) route to get there. Once your application architecture is truly service-enabled, it no longer matters where any of those services are located. Many of SAP's customers are large enough to run their data center operations at service-provider scale. Those that aren't will typically prefer to rely on external services. In many cases, enterprises will run in-house services but sign up for external providers as a fallback.

The big question is whether SAP  can re-engineer its software fast enough (but not so fast that it leaves its customers behind), and yet remain competitive against native on-demand vendors whose product development isn't being held back by legacy migration factors. My gut feel is that SAP will come second in this race, but what other choice does it have? It has to protect its existing customers' interests and give them a realistic migration path. In its shoes, I would do exactly what it is doing.