What is behind SAP’s ‘go-slow’ on SaaS?

There have been many reports recently on the problems with SAP’s Software as a Service (SaaS) offering, Business ByDesign – see for example the article by Timothy Morgan here.

To summarize, SAP is backing off its initial, bullish claims on SAP Business ByDesign, saying that it is now going to proceed at a much slower pace than originally planned. Of course, the SAP trade show Sapphire, which is being held this week, might provide more info, but I somehow doubt it.

So, what is going on? Why the sudden backtrack? After great trumpeting 18 months ago from SAP about Business ByDesign being the magic bullet for SMEs, offering the ability to run remote copies of SAP applications on a per user basis without having to cough up for a full license, why the hesitation?

I suspect the truth of the matter may be partly political, partly execution oriented and partly financial. There are those who would argue that SAP does not really WANT a SaaS market for its packages to come rushing into existence. After all, from a supplier point of view wouldn’t you prefer to sell more expensive licenses that lock the user in rather than a cheap usage-based service that the user can walk away from at any time?  So the conspiracy theorists would say SAP deliberately tried to freeze the market for SAP SaaS offerings to discourage competition and slow down the emergence of this market.

On the execution side, perhaps it is possible that SAP did not realize that selling SaaS solutions is a world away from selling large application suites directly to big companies. SaaS solutions are low-cost high-volume as opposed to high-cost low-volume, and hence need much more efficient and layered distribution channels – and SMEs are used to picking up the phone to ask someone whenever they have to change something, not a great strength for SAP’s support structure.

Then finally, the financial side. Many SaaS suppliers have discovered an uncomfortable truth – while in a license model the user pays a substantial sum of money for purchase followed by maintenance, in a SaaS model the risk position is reversed, with the supplier having to put the resources in place up front to support the POTENTIAL usage of the infrastructure by all those signed up users and then receiving revenues in a slow trickle over time. Is it possible that SAP just didn’t like the financial implications of having to continually invest while looking at payback times of years? Did they therefore decide to deliberately throttle the number of new customers, giving them a chance to make some money before making more investments?

Maybe SAP will tell all at Sapphire … or maybe we will just have to keep guessing.

Steve

Sofware as a service (SaaS) and the new frontier of integration

A report quoted in Computer Weekly at the end of June found that 17% of SMBs are using more than 1 application delivered as a service.

This, as the article notes, brings the problem of integration back into the frame.  However, the problem is a tougher one in the sense that SMB are typically not equipped with IT departments capable of handling integration projects and are cost averse.

One approach is to rely on your SaaS application vendor to do the integration for you.  As Mike West of the firm that produced the report, Saugatuck, puts it:

“If you’re exclusively on a platform like Salesforce.com and using Salesforce.com plus other cooperating companies on AppExchange, they have their own platform that offers integration,” West said.

Or to put it another way, rely on a single integrated stack from a single vendor – which sounds rather similar to the old enterprise software vendor approach.  For the same reasons as larger enterprises don’t put all their applications in a single vendor’s basket (functionality mismatch, over-dependence on a single supplier), many firms going the SaaS route will probably want to mix and match SaaS offerings from multiple vendors or combine in-house applications with SaaS.  While SaaS vendors do claim to provide integration hooks, this simply brings them back up to the same mark as in-house hosted applications.  This isn’t any more daunting than the other integration issues facing large organisations –and fit well into SOA programmes.

However, for smaller organisations this may be new territory and they are faced with two alternatives:

  • Do the integration in house as part of a SOA strategy for instance suffers from the problems I covered last time around the lack of support for development life cycle.  For larger organisations with sufficient in house IT expertise, this may be acceptable.  For smaller ones, it is a far from simple decision.  And the decision becomes exponentially more important and potentially painful as the number of applications to be integrated increases the problem exponentially.
  • Alternatively, you can go to a third party integration SaaS which offers to host the integration logic for you – such as BT (among others) has offered since last year.

Deciding which to go for will require a significant investment of time and effort as the decision will have far reaching consequences.

Ronan