"SAP: A Sea Change in Software"
BusinessWeek has a flattering article on SAP this week. But as I read it I kept getting flashbacks to SAP promises in previous years and asking whether it really is a "sea change".
a) "The move thrusts SAP squarely into the most important -- and hotly contested -- trend to hit software in a decade. Known as Web services, the new approach uses messages sent over the Net to link up pieces of software running on different computers."
In the past, SAP has rolled out a variety of proprietary and industry standard integration technology. Go in to the SAP partner ecosystem and you see terms like ALE, EDI, IDoc, RFC, BAPI, DCOM, .NET, Java Connector in use to connect disparate systems. Web services are part of that evolution. What is unclear is how SAP will manage the thousands of Web services entry points it is promising.
b) "It's breaking up its software into smaller chunks that customers can snap together or break apart like Legos."
See this article from 1996 about another SAP "breakup". The reality is the tight integration in the "core" FI/CO, MM, SD - financial, procurement, inventory management, order processing functionality was one of the main reasons companies chose SAP over its competition. Breaking up was not easy then, continues to be challenging.
c) "Both Microsoft and IBM do far more business in partnership with SAP than in competition. But each has its own approach to Web services that differs from SAP's."
see my blog - SOUP -Services Oriented User Procrastination
d) "The danger is that customers could buy less software from SAP or use more products from other vendors. Kagermann doesn't seem worried."
Wait till the new generation of i2 or Ariba or Siebel takes off as and creates new planning, procurement, CRM or other categories, then SAP will scamper to build its own as it has done repeatedly in the last decade. Plenty of markets for which SAP does not have robust transaction processing solutions.
e) "For one, SAP hasn't yet disclosed pricing for the modular version of its software."
It would be a sea change to see SAP "core" components priced at utility rates - see my blog The Giant Crunching Sound. Hopefully, SAP will allow its loyal customers to free up more for innovation. Also point d - what is SAP itself doing for business process and vertical innovation, not just architectural renewal?
f) "That should help SAP burrow into potentially thousands of niche markets that are too small to pursue on its own"
That statement painted for me images from Spielberg's new movie "War of the Worlds". In the movie, alien tripod fighting machines burst out of steady ground and use their snakey probes to search for humans in niches in basements. Does it sound like components emerging from core SAP with web services probes? Maybe that disturbing movie had more of an impact on me than on my son...
Author's Note - see response to my blog from the BusinessWeek journalist Andy Reinhardt who wrote the SAP story by clicking on Comments below
Thanks for your thoughtful comments. My story has generated quite a bit of response already--more than most things I write--so I guess people feel pretty passionately about SAP.
Your points are well taken, and I can promise that you are more of an expert on SAP than I am. But here a few thoughts:
1. I acknowledge that SAP and lots of other vendors have rolled out interoperability and integration technologies in the past, so some skepticism is in order. But I still think Web services--as nebulous as they are--represent a quantum leap in simplicity and standardization vs. more cumbersome earlier concept such as RPCs, EDI, and the various object models such as COM, DCOM, CORBA, etc. All of the latter were even more proprietary, and in some cases, very "heavy-weight" and complex. Web services has the advantage, as far as I understand it, of being lighter weight and more flexible.
2. What was striking to me is not that SAP is proposing to break up software into chunks; as you point out, such schemes have been around forever. It's the nature of those chunks that interests me. SAP is taking the argument up a level, away from objects and technologies, and focusing instead on business processes. It has 30+ years of experience in developing solid, reliable data-and-event sequences that represent core business processes. By exposing those sequences (while keeping the internals still closed, so that they're reliable and predictable), and allowing ISVs and system integrators to recombine them into different applications, I think SAP manages to focus the market on where it adds real value. Does this make sense?
3. I don't really know how much SAP needs to worry about losing business to providers of third-party NetWeaver compatible modules. The sense I got from the company and outside analysts is that SAP has more to gain from getting deeper into vertical markets and smaller businesses than it stands to lose from large enterprises defecting to non-SAP business process modules. You might call it a "rising tide lifts all boats" strategy: SAP could end up with a somewhat smaller share of a much larger pie.
4. Maybe the language about "burrowing into niche markets" was too graphic. But my point remains that SAP has gotten too big to address every potential market opportunity with branded, company-developed vertical market solutions. To justify the engineering expense, each one has to address a very large market opportunity--yet, at the same time, the larger the target market, the more general-purpose the package has to be, which then ironically limits its applicability to niche users. This idea was explained to me with an 80/20 rule: If 80% of a customer's needs can be met with off-the-shelf functionality (which, naturally, embeds lots of best practices), the other 20% can be developed in India using software components for a fraction of what it would have cost to write a custom app using older technology. That lets SAP simultaneously take advantage of volume economics in its horizontal underpinnings, while leveraging cheaper engineering for its customization, and that, in turn, opens up more specialized niches. (And don't forget--a company that develops a micro-niche application for one customer also might be able to sell it to others, as well.) Maybe this is still an ideal, but it sounds pretty compelling to me.
Anyway, thanks for reading my article and commenting on it. I'll be interested to see what kind of further response you get to this and other postings.
Andy Reinhardt
BusinessWeek, Paris
Posted by: Andy Reinhardt | July 07, 2005 at 03:05 PM
Andy, thanks. You write for the business reader and I consult with them so from that common perspective here are some comments:
a) The average business executive (and BusinessWeek reader) does not care much about elegance of Web services, just the business benefits. Web services are a concept which the tech industry itself cannot agree on – see my blog called SOUP – Services Oriented User Procrastination. But assuming they are easier to implement than previous integration attempts like ALE (I agree on surface they appear to but when I hear SAP may end up with 5 or 10,000 of them I become less convinced) should we credit SAP for exposing its engine or the third parties which built the functionality you are trying to link to SAP. Or worse, are you expected to pay both?
b)SAP is not done building out its core in so many vertical markets - insurance claims processing, bank trading systems, mortgage processing, telecommunication billing, utility billing, patient and health care accounting, media rights management – I could do on and on. Will this get built by SAP or will some “community” be expected to build out this core too?
c) From my role as negotiator, I think current core SAP (its financial, MM, SD functionality) and the annual 17% maintenance is way over priced at this point. BTW – lots of Oracle, Accenture, IBM products are similarly overpriced. not just picking on SAP – but the core of SAP is at this point utility, not innovation IT using terms from my blog titled “The giant crunching sound”. I think most csutomers want to hear about pricing adjustments before they tie themselves even tighter to SAP's changing architecture.
Final point - not so much from a buyer perspective - but by putting so much emphasis on SOA I think SAP is playing in to Oracle’s hands. They can “out architecture” and “pure Java” them. SAP won against him by emphasizing boring business functionality for the last decade.
But appreciate the dialogue . Hope we can argue about IBM or Oracle next.
Posted by: Vinnie Mirchandani | July 08, 2005 at 05:15 PM