Expand +



Why Innovation Fueled by In-Memory Computing Gives SAP an Advantage

by Joshua Greenbaum | insiderPROFILES

April 1, 2013

In his latest column, Joshua Greenbaum explores the history that led to SAP’s decision to power SAP Business Suite with SAP HANA. He explores why the archrivalry between SAP and Oracle was so important in this development, and why SAP HANA will fuel innovation to give SAP a distinct advantage in the market.

SAP’s recent announcement that its flagship SAP Business Suite will run on the SAP HANA in-memory database was years in the making, and the achievement highlights not only SAP’s dogged pursuit of innovation, but the rapidity with which technology and business strategies are changing.

When I wrote about the potential for an in-memory business suite for insiderPROFILES back in 2007,1 the context for thinking about running a business suite on what would eventually be called SAP HANA was very different than the context SAP customers face today. And inside this shift is the story of the evolving future of the intersection between technology and business.

The goal back in 2007 for imagining an in-memory business suite was to run it faster, and maybe a little more cheaply. The idea that disk access and its associated latencies could be bypassed and that operations could run at the speed of memory, instead of disk, was a pretty impressive improvement. SAP had piloted some of this thinking in its SAP liveCache and SAP NetWeaver Business Warehouse Accelerator (SAP NetWeaver BW Accelerator) products, both of which used in-memory technology to make planning and business analytics run faster. The idea of split-second analysis supporting split-second decision making was appealing — and so the concept of running SAP NetWeaver BW Accelerator and liveCache faster using in-memory technology became the progenitor of running other SAP applications on SAP HANA.

Underlying this issue of speed was the growing rivalry between Oracle and SAP. Oracle’s PeopleSoft acquisition closed in 2005, and by the end of 2006, Oracle had beaten out SAP on the purchase of Retek and acquired former customer relationship management market leader Siebel. Against this backdrop of archrivalry was the not-so-hidden secret that SAP was Oracle’s largest ISV reseller of the Oracle Database Management System (DBMS), with 80% of SAP R/3 systems running Oracle, which translated to about 16,000 customers.

At the time, there had been a number of unsuccessful attempts by SAP to draw customers away from Oracle DBMS. Even though SAP DB, formerly known as Adabas D and originally marketed by Software AG, was the DBMS behind liveCache, the option of a much lower-cost and SAP-branded DBMS never caught on in the market. While Microsoft SQL Server and IBM DB2 made serious inroads in the SAP market, SAP’s biggest competitor was still sopping up tons of revenue and influence in the SAP customer base, to SAP’s competitive disadvantage.

In retrospect, the reason SAP DB never quite made it was simple: you can’t force revolutionary thinking — as in ditching an acknowledged market leader around which careers and IT fiefdoms were built — with something that’s largely marketed as “good enough” and much cheaper. IT buyers just aren’t that fickle, nor are they that opportunistic. And Oracle’s sales force was clearly not going to let something as meaningless as price get in the way of maintaining its market leadership. What SAP needed to do was something much more disruptive, and that kind of disruption wasn’t on the table — yet.

Memory Chips, Big Data, and User Experience

Right around the time that SAP’s biggest database partner was becoming its biggest enterprise software rival — making Oracle a twin threat — something remarkable happened in the hardware market to change the economics of in-memory database technology: the price of memory chips, which had begun to fall in 2006, plunged even more in the beginning of 2007, and the prospect of further decline was excellent. By the end of the decade, a production glut further drove down prices, and low-cost memory was now something SAP could count on.

All of this meant that in-memory database technology could be built using commodity hardware and be marketed as both faster and definitely cheaper than disk-based systems, and that companies like SAP could do long-term planning based on this new reality. The speed issue got a further boost with the advent of column-based database technology that offered a very high rate of compression and essentially no indexing. This development further skewed the faster/cheaper argument in favor of in-memory database technology.

But the real issue that I believe will drive the success of SAP Business Suite powered by SAP HANA and the rest of the opportunities for running SAP applications on SAP HANA was still a couple of years off, though the market momentum was underway as the first decade of the new century wound to a close.

This issue is “big data.” Terms like “exaflood” started surfacing in 2008, and prognosticators began talking about zettabytes of data enveloping the enterprise and overwhelming our ability to analyze the business environment in which we work. The hype machines started humming, and a trend tailor-made for in-memory computing had arrived.

However, big data had always been there, just not in the context of big enterprise software systems, such as SAP Business Suite. While SAP data warehouses had been growing phenomenally, the established hardware/relational database combination was more than adequate to handle most companies’ analytical and transactional needs.

But two big-data components — social web data and sensor data — began to converge on the enterprise quickly and in great abundance. And this was not your usual relational data: suddenly, vast quantities of non-relational data were heading to the enterprise, and the question of how to process this data became a major topic. In-memory, columnar technology started to look like a great solution.

Another element to this saga that’s worth mentioning is the user experience revolution that was stalking the enterprise. Driven by the forced simplification required for mobile devices and many online services, improving the user experience became one of the major design goals for enterprise computing. SAP took this thinking to heart, and began to add simplification to SAP HANA’s design.

A Time Ripe for Disruption

With that as background, will SAP’s efforts really yield the “Oracle Killer” I wrote about in 2007? I honestly think the question today is largely moot. SAP Business Suite powered by SAP HANA is just the beginning — everything powered by SAP HANA is clearly the goal, and the technical advantages that in-memory computing can provide will largely fade into the background as the advantages of faster, cheaper, and more simple begin to change how businesses innovate.

Business innovation, not in-memory, is what will drive SAP’s success in the next 10 years. Business innovation fueled by in-memory computing will give SAP an advantage that will definitely help its customers succeed, and that is and should be the real focus of SAP’s efforts. And if it hurts an archrival or two along the way, it just proves that all is fair in love and war…and technology too.

1Putting the Database on a Diet: The ‘Oracle Killer’ Positions SAP as a Database Pioneer” by Joshua Greenbaum (2007). [back]

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!