SAPs 429 page lecture: who's learning what?
Dan Farber's discussion of a meet up with SAPs Denis Browne could not come at a better time. Independently, I was pinged with a message from Martin Guenther at the SAP Developer Network that advised me of a 429 page Hasso Plattner lecture entitled Trends and Concepts in the Software Industry.
Apart from qualifying as a geek's coffee table adornment, the tome provides fascinating insights into the way SAP thinks. While Mr Plattner is no longer a titular head of the company, a cursory reading makes clear that he is driving design. I should say that I have enormous respect for Mr Plattner as both a founder and thinker. I admire the way he tries to take SAP out of its engineering comfort zone. But I can't help but wonder whether he is able to influence the company to make the kinds of radical change necessary to remain competitive in the early 21st century.
The message that comes through in Dan's piece is clear: caution. That's understandable. SAP is managing some of the largest ERP projects ever attempted and its sponsoring management knows there comes a point where the 'brittle' nature of the applications might overtake the engineering the company has invested over the last 30+ years.
But is it a symptom of thinking that's wedded to the past? In the Foundations chapter p.7, Mr Plattner notes:
Business processes were the purpose of lines of business in the Enterprise 1.0 era. Business process will continue to be at the heart of Enterprise 2.0. Standalone Web 2.0 capabilities are not sufficient to provide the added value to business users and companies.
Really? When I listen to Workday, they paint a very different picture. Salesforce.com continues to rack wins. But in fairness, these companies are talking about a certain style of company. One that is less cautious, that recognizes the need for agility and flexibility, something Mr Plattner acknowledges is very difficult with SAPs style of application.
My sense is that SAP is bifurcated. In conversation, Mr Plattner demonstrates a very clear understanding of the challenges that lightweight 'Web 2.0' style applications represent to incumbent, inflexible systems. In the lecture, he says:
Enterprise 2.0 closes the gap between unstructured world of information work and the structured world of business processes by complementing rather than replacing existing Enterprise 1.0 applications, processes, and infrastructure or office productivity and Web 2.0 concepts.
When you dig through the rest of the paper (and I have not read it all but enough to form an opinion), there is a sense that SAP has to be the architect and builder of whatever the next phase of development brings. This is its Achilles Heel. Why for example do we need an entire chapter on SAP developed search except to justify what many already know - Google fulfills a general need but if that's no good, then there are other 'buy' alternatives. The cost of testing 'new' is a flea bite on most enterprise IT budgets.
On the other hand, there are people at SAP like Craig Cmehil who developed a raw integration between SAP and Zoho in a matter of days. What does that mean for the years of development thrown at Duet? Then there are teams trying to work out how to express KPIs in the same manner so that all customers speak from the same hymn sheet. I've contributed to that effort because its potential value to the business is enormous. [Disclosure: I have no commercial relationship with SAP]
How does a company like SAP tread the fine line between transaction based applications that cost millions to keep alive and those that show demonstrable value add but which are 'loose' and cost pennies? There are no clear answers but Denis Browne's caution is not the way to go. It may satisfy in the short term and absolutely plays to the laggard businesses to which SAP must be selling. The pace of change is such that companies like SAP are faced with two alternatives:
Either way, it is a tough choice.