On-premise vendors never have to run their own software*. This is by far the largest (and least often anticipated) handicap suffered by on-premise vendors when embarking on the on-demand model. [*OK, maybe some of them 'eat their own dogfood' by using it in-house. But they never really experience it as their customers experience it.] They are in blissful, utter ignorance of just how difficult it is to install and run their own products. They have always imagined that the problems their customers experienced in doing so were due to special factors in each customer's own infrastructure. Such problems never come up when testing in the development labs. But as soon as any vendor becomes a software operator, forced to grapple with the realities of running its own software to achieve a business result, suddenly all those lab certainties disappear, overwhelmed by the fuzzy compromises of the real world.
I was forcefully reminded of this when I read about why SAP said it had delayed the release of its SaaS offering, Business ByDesign. Fellow Enterprise Irregulars reported on the account given by SAP executives at the company's recent SAPPHIRE Orlando conference. It so happens that I'm writing this having arrived today for the European sister show, SAPPHIRE Berlin, where several of us will do some further probing [disclosure: SAP has paid my travel costs to be mere]. Co-CEO Léo Apotheker, who some of us met with this morning, says that any new project starts out with assumptions that turn out to be incorrect. "Fine, you change them." But I'd argue that shifting to SaaS throws up more issues of much more significance than you'd get in the average new product development project. You're not simply creating another software product, you're grappling with all the operational headaches of running business software reliably and at scale, while working out how to deliver it within a completely new business model. Any SaaS stalwart will tell you how steep that learning curve is.
Indeed, many of us in the SaaS world had an 'I-told-you-so' moment when we read of the reasons for the slippage in Business ByDesign's release schedule. "The initial deployments showed unique customer configuration and other issues they had not anticipated in the labs," wrote fellow-EI Vinnie Mirchandani from Orlando. Brian Sommer expanded in robust style:
"SAP executives admitted that their new on-demand solution encountered challenges the company had previously never encountered. First, SaaS was an entirely new space. Second, the company couldn't fully 'leverage their 35 year experience' in application software as these customers were not the typical SAP customer and the solution would be used differently than its prior on-premise solutions. One SAP executive said they 'thought they knew this market' but that wasn't exactly true. Lastly, their development staff was caught by surprise as they did not have the same level of control with this product as they have had with other product lines."
Another EI, Charlie Wood added further detail:
"In private sessions with the Enterprise Irregulars yesterday, SAP co-CEO's Henning Kagermann and Léo Apotheker blamed the delay on unexpected scalability and operational issues and, interestingly, labor costs. Apparently the on-boarding and upgrade processes are largely manual, making them not only labor-intensive but also error-prone. Also intriguing was Dr. Kagermann's assertion that the next version of NetWeaver will help alleviate some of the problems."
That reference to NetWeaver highlights another area of conflict for conventional software vendors. Business ByDesign is built on SAP's NetWeaver platform and it needs to migrate to the new 7.1 release to resolve some of those automation issues. No wonder the development staff were complaining of lack of control. Instead of being able to move ahead on their own initiative to resolve those problems as soon as they were encountered, they've had to wait in line for a separate team serving SAP's on-premise customer base to deliver those much-needed platform improvements (and then adapt them to their own needs).
At this rate, Business ByDesign is turning into a masterclass in how SaaS innovation can never thrive inside a conventional software company. Its developers started out grossly underestimating the scale of the task ahead of them. Now that they've started to understand what they're up against, they're being starved of development resources and marketing spend. Apotheker told us this morning that knocking back Business ByDesign's schedule by 18 months didn't matter "because the rest of the business is really delivering well." Meanwhile, SAP's top management seems more interested in feeding back innovations from the Business ByDesign team back into its on-premise products than in accelerating the SaaS offering as fast as it can go.
From their perspective, the mission is far wider than SaaS. "Traditional software wasn't good enough," Apotheker freely admitted this morning. "There were too many issues around getting it to scale to the next level." SAP believes that solving those issues for SaaS is merely a part of solving them for all software, whether delivered as a service or implemented on-premise. "It is not about SaaS as the next level," he said. "It is about how do you get software to a point where it is perfect, you can consume it any way you want."