SAP in Transition on Mobile, Cloud, and In-Memory Computing
I attended two days at SAP’s SapphireNOW conference in Madrid earlier this month, at the end of a month-long trip to Spain and Italy. The trip to Madrid gave me a good opportunity to catch up with the latest developments with SAP since the Sapphire conference last May in Orlando.
Jim Hagemann Snabe gave the Wednesday keynote, which I found tighter and more balanced than similar messages delivered in Orlando. Back then, the keynotes seemed to overly emphasis HANA, SAP’s new in-memory database technology. Although HANA is still hugely important to SAP, the message is now more balanced between SAP’s three focus areas of innovation: mobile, cloud, and in-memory computing.
I also appreciated Snabe's tone, focusing positively on SAP’s roadmap and customer success stories. This was a welcome change from recent keynotes by the CEOs of some of SAP’s competitors, whose bar-room brawling style might be more entertaining but doesn’t provide much real insight. Personally, I find Snabe’s low-key approach much more palatable, and I have to believe customers feel this way also.
So, in a nutshell, here is my bottom line: I see SAP in a period of transition with cloud computing, mobility applications, and in-memory computing. There is progress, but success is not ensured.
Business ByDesign Has Momentum, but Line of Business Apps Lagging
SAP has two major cloud initiatives: its Business ByDesign (ByD) ERP suite for small businesses and its Line of Business (LoB) SaaS applications, which complement its Business Suite.
Concerning ByD, SAP is on target to reach 1,000 customers sold by year end, although SAP executives indicate that reaching that goal might come down to the wire. Although reaching or exceeding that number will matter to some SAP folks’ year-end bonuses, I would view anything close as being a significant accomplishment. My consulting team at Strativa recently evaluated ByD in a competitive deal and came away favorably impressed. Customer reference checks during the Madrid conference were also encouraging. I believe SAP has a winner with ByD: both for subsidiaries of its large customers and in net-new small business deals. Those who question the viability of ByD at this point should reconsider their assumptions.
On the Line-of-Business side, progress is not as impressive. SAP has one SaaS application—Sales On Demand—in general release. But don’t expect to see other applications any time soon. Travel On-Demand (mostly expense reporting) will go into beta in Q1, 2012, according to Sven Denecken and Kevin Nix, who head up LoB development. Career On-Demand is scheduled to go to the first beta customer in Q2, 2012. In addition, Kevin and Sven told me of another LoB application now in development: Social Service and Marketing On-Demand. I have no target date for this product.
SAP positions these LoB applications as people-centric applications, helping end-users accomplish their daily activities. Although this is an interesting approach, the LoB apps do not have very broad functional footprints. For example, Sales On-Demand is primarily focused on the collaboration of pre-sales teams and others as they coordinate their activities for specific prospects. It is by no means a complete CRM package—it is not even a complete sales force automation app. Likewise, Career On-Demand is not a complete talent management system. Rather it is focused on helping people manage their goals, objectives, and daily activities and to see what others across the organization are working on. Finally, Social Service and Marketing is narrowly focused on processing incidents originating from Twitter and other social media channels.
In my view, the LoB applications are a defensive play by SAP, aimed at keeping its installed base from leaving the SAP-fold for newer cloud-based providers. For example, in my view, Sales On-Demand is aimed at keeping SAP CRM customers from considering Salesforce.com. Likewise, Career On-Demand is meant to keep SAP HRMS customers from considering Workday. Finally, Travel On-Demand is SAP’s answer to Concur’s expense management system. SAP may be successful in getting its installed base to adopt some of these LoB applications, but because they are not complete solutions, I do not think they are an adequate response to the threat from Salesforce.com, Workday, Concur, and others. Furthermore, it is hard to imagine non-SAP customers purchasing these solutions.
The other problem with the LoB applications, frankly, is that they are a late response by SAP. Salesforce.com, Workday, and Concur have been developing and marketing their applications for years. In the case of Salesforce.com, over 10 years, and SAP is only now starting to respond? It’s like the student who turns in (hopefully) a well-written essay, but misses the deadline.
So, on my scorecard, SAP gets an “A” for ByDesign and a “C” for its line of business applications.
Turning the Ship on Mobile Applications
On the mobility front, SAP appears to be making good progress. Based on a briefing I received, there are now 50 mobility apps available in the new SAP Store. Of these 38 are authored by SAP and 12 are from partners. There are 200 more in the development pipeline (split between SAP and partners is not clear to me).
All of the current apps in development are based on the Sybase Unwired Platform (SUP), and this is where there are some issues. The SUP is a general platform for mobility device development and management. It allows a developer to write an application and have it deployed on multiple devices, such as RIM’s Blackberry, Apple’s iPhone/iPad, Android devices, and Windows phones. It also provides an enterprise-class management platform for back-end data access, application provisioning, user and device management, and security. So from the perspective of ensuring that its mobility apps are enterprise-class, I can understand why SAP would want mobile applications developed by partners to be certified for SUP.
The problem, however, comes from the developer perspective. Many of the best mobile apps development these days are coming from small shops, and current SAP licensing practices by SUP are, shall we say, burdensome for small developers. Based on briefings we received, it appears SAP understands the obstacles in the way of small developers and wants to show some flexibility on this issue. There is talk of allowing developers to work outside of SUP and then submitting their applications for certification. There was even talk at some point of allowing apps to be sold via the SAP Store that do not run on top of SUP, but that is by no means current policy.
So, it would appear that on the mobility front, SAP is in transition. They are making good progress, but they need to follow through on their good intentions to become more developer- and partner-friendly in mobile apps development.
In-Memory Computing Still Rings SAP's Bell
Although the Madrid messaging was balanced among the three areas of innovation, you can still sense the excitement among SAP executives when they come to the subject of in-memory computing. They honestly feel that its in-memory technology (HANA) will leap-frog SAP over its competition. In a small group briefing with Vishal Sikka, he spent significant time talking about the value proposition of in-memory computing to provide faster answers to business queries, without the constraints of data structures such as cubes. The value of HANA has already been demonstrated in a limited number of one-off proof of concept projects for select customers, many of whom were featured in the Orlando conference.
The next step is to scale up HANA adoption by using it as a customer platform for SAP’s business warehouse (BW) deployments. In a sidebar conversation with Sanjay Poonen, SAP’s President of Global Solutions, he indicated this is where most SAP customers will first realize the value of HANA.
Ultimately, though, SAP intends to bring in HANA underneath parts of the Business Suite—we had one briefing from a customer looking to run HANA underneath its trade promotion processing to more quickly analyze pricing trends. SAP has a far-reaching vision for HANA to ultimately become the data platform for many of its products.
So SAP is also in transition with in-memory computing: moving it from a small number of proof-of-concept case studies to a broader adoption by its customer base. This migration has only just begun.
Can SAP Make The Needed Transitions?
For the largest enterprise software vendor in the world, the roadmap is good. But is it possible for SAP to complete the needed transitions? There are strong economic rewards up front for HANA, which are big ticket license sales. But will SAP be willing to devote the resources necessary for its cloud solutions and mobility applications to be successful, where the deals are smaller? The signs are encouraging, but success is not ensured.
Progress is good with mobility apps, but the partner model needs to be improved. When small mobile developer partners, like Graham Robinson, tell me they are happy with SAP’s support then I will be convinced that SAP stands a good chance of being successful. The words coming from SAP executives are the right sounds, but I’m waiting to hear confirmation from small developers that SAP’s actions are following its words.
It is going to be interesting to see how SAP’s cloud computing programs proceed. For SAP, cloud is both a sustaining innovation and a disruptive innovation (to use the terminology of Clayton Christensen). From the standpoint of SAP’s large customers with many small subsidiaries, ByD is a sustaining innovation because it gives them something to offer for their subsidiaries. Many competitors, such as Microsoft Dynamics, Epicor, NetSuite, and Plex, are targeting these subsidiaries in a so-called "two-tier ERP" strategy. Thus, ByD preserves and extends the revenues that SAP receives from these large customers.
The larger question is whether ByD can consistently beat out cloud-based competitors such as NetSuite, Plex, or Rootstock for net new deals in small organizations. As I indicated, the signs so far are good. But will SAP be willing to invest what it takes for such small deals? Furthermore, will SAP be willing to let ByD naturally grow up-market and start to disrupt (cannibalize) its sales of SAP All-in-One or even its Business Suite? If so, then I would declare victory for ByD as a truly disruptive innovation.
I do not view SAP’s LoB applications as disruptive. These apps are targeted primarily at SAP’s installed base and are therefore a sustaining innovation for SAP. They do not need to be best-in-class. They only need to be good enough to keep customers from going with SFDC, Workday, Concur, or other pure best-of-breed cloud solutions. But, as noted earlier, these are not complete solutions and may not be enough to keep SAP customers from looking elsewhere. Also, they are unlikely to find much of an audience outside of SAP’s installed base.
Although I would agree generally with Vishal’s assessment about HANA, from an economic standpoint, in-memory computing does not require SAP to transition its thinking or business model. From an economic standpoint, in-memory computing is a sustaining innovation for SAP. SAP can use in-memory computing to continue to sell big-ticket licenses to big-ticket customers and receive large annuities in the form of maintenance fees. It is not like cloud and mobile which require that SAP make changes in its expectations on how it will make money in the future.
So in terms of transition, I think SAP has made the most progress with cloud computing, with Business ByDesign but not with its line of business applications. The direction with mobility applications is good, and SAP is making the right noises about working with small developers, but it is too early to see words translated into action. Finally, even though in-memory computing is still early in its roll out, it stands a good chance of success if SAP can gain adoption beyond its initial proof cases, because it does not require SAP to change its business model.
I made some of the same points in a very short interview with Dennis Howlett, during the Madrid conference. You can watch the interview below.
Postscript: I’ll repeat here what I said to my SAP host when I bid goodbye from the Madrid conference: I know some of us often give SAP a hard time. But we do it for one reason: we care about SAP’s customers, just as SAP does, and we want SAP to be successful for their sake.
Disclosure: SAP paid part of my travel expenses to attend the Madrid conference.
by Frank Scavo, 11/15/2011 02:17:00 PM | permalink | e-mail this!
Such debates are likely to continue, but now there is at least one official source for the definition of cloud computing. The National Institute of Standards and Technology (NIST), an arm of the US Department of Commerce, has now published The NIST Definition of Cloud Computing. Though other standards bodies may (or may already have) published their own definitions, NIST carries particular weight as it is often referenced in U.S. governmental procurement. The NIST definition is vendor-agnostic and buyer-centric.
The NIST Definition
The NIST document is short--the body of the document comprises just three pages, with the definition itself taking up less than two pages. In it, the authors describe the essential characteristics, service models, and deployment models for cloud computing.
The five essential characteristics are: on-demand service, broad network access, resource pooling, rapid elasticity, and measured service.
They go on to then list three service models, which should be already familiar to most observers: software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS).
Finally, they list four possible deployment models for cloud computing: private cloud, community cloud, public cloud, and hybrid cloud.
In my mind, the section that is most useful for distinguishing what is or is not cloud computing is the first one, the "essential characteristics." So, let me quote NIST directly (emphasis mine).
On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
Keep these key points in mind.
Cutting Through the Ellison/Benioff Fog
So, let's apply these characteristics to what Larry Ellison and Marc Benioff each describe as cloud computing. In my opinion, both are right and both are wrong.
Benioff's service, Salesforce.com, certainly meets the NIST definition of cloud computing, both in its CRM application, which meets NIST's definition of SaaS, and in its Force.com offering, which meets the definition of PaaS. He is also correct in criticizing the labeling of Oracle's Exalogic hardware as a "cloud in a box." By my reading of NIST's essential characteristics, one could construct a cloud service using Oracle's hardware, but the hardware itself should not be considered a cloud.
But if Benioff is referring to Oracle's newly announced Public Cloud Services as a "false cloud," he is wrong. Oracle's Public Cloud Services certainly meet the NIST definition of cloud computing. But it is primarily an IaaS offering, similar to Amazon's EC2. Assuming that Oracle will offer development capabilities on top of its Public Cloud Service, those would be PaaS, and if it chooses to run applications on top of its Public Cloud Service, such as Oracle CRM On-Demand, those would be SaaS.
On the other hand, Ellison is wrong to label Salesforce.com's PaaS offering as a "false cloud." Ellision's argument is that Force.com utilizes proprietary extensions to Java and other programming languages, which make it difficult to migrate applications to other cloud providers. But there is nothing in the NIST definition of cloud computing that requires interoperability between different cloud service providers, as desirable as that may be. Ellison is simply turning what he sees as a disadvantage of Benioff's cloud into an argument that it is by definition not a cloud.
Cutting Through the Application Hosting Fog
The NIST definition is also useful for cutting through vendor marketing efforts to label anything they do off-premise as cloud computing. In particular, application vendors that simply host their on-premise solutions in their own, or partner, data centers should not be labeling those as cloud computing. In particular, simple hosting of an application does not qualify as cloud computing because it lacks the essential characteristics (see bolded sections in the quoted definition above).
With a hosted application, the customer generally cannot "unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction." In addition, with a hosted application there is generally no "sense of location independence." Rather, the customer usually knows the data center and may even know the data center, cage, or rack in which his hosted application resides, even if the application is hosted on a virtual server. Finally, with a hosted application, computing resources generally cannot be "elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand." Rather, the customer must negotiate provision of additional computing resources.
Notice also that the NIST definition does not mention anything about how cloud services are contracted. Some vendors point to subscription pricing as evidence of their hosted applications being cloud offerings. According to NIST, how the customer pays for the service has no bearing as to whether the service is cloud computing. It could be subscription pricing, it could be a perpetual license, or it could be something else.
The marketing hype and confusion over cloud computing will no doubt continue. But at least now NIST offers a reasonable and objective definition.
Send tips, rumors, gossip, and feedback to Frank Scavo, at
I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.
Selecting a new enterprise system can be a difficult decision.
My consulting firm, Strativa, offers assistance that is independent and unbiased.
For information on how we can help your organization make and carry out these decisions, write to me.
For reprint or distribution rights for content published on the Spectator, please contact me.