SAP’s ambitious launch of SAP Business Suite 4 SAP HANA (SAP S/4HANA), the successor to SAP R/3 and SAP ERP 6.0, has many important attributes that could propel it to a leadership position in enterprise software. And one of the most significant attributes at first seems paradoxical: by basing its next-generation suite on a single database, SAP HANA, instead of the open database model used for SAP R/3, SAP effectively is making the database disappear. What’s confusing is the “HANA” in SAP S/4HANA signifies the database is more important than ever — and the fact that SAP S/4HANA runs on a columnar, in-memory database seems to be the main reason SAP believes it will become the platform for innovative enterprises in the 21st century.
While all of that is true, there’s a much more substantial issue at play — the linkage of business processes directly to the database layer — that effectively means the database need no longer be a key factor in the customer’s decision about whether SAP S/4HANA is the worthy successor of SAP R/3. SAP has been so successful on the database side with the features and functions of SAP HANA that the market’s attention can and will shift to a more important domain, one that’s always been a sweet spot for SAP: business process excellence. And, along the way, the database side of SAP S/4HANA will become as significant as the number of valves in a car’s engine — essential for a few, but really not relevant to the average car buyer.
History of the Database
The story of SAP HANA and the end of the database starts back in 1979 with a company called Britton-Lee. This pioneering database company figured out how to build an ultra-fast relational database by effectively creating the specialized hardware needed to make it screamingly fast. The company had its day in the sun, but eventually the complexity and cost of using specialized hardware made Britton-Lee largely unable to compete with the low-cost, general-purpose UNIX machines that began to emerge in the mid-1980s.
One of the engineers at Britton-Lee figured out that while writing directly to the hardware layer wasn’t going to work from a cost-effectiveness standpoint, a relational database written to function in close concert with the UNIX operating system would allow him to create what, at the time, was an extremely high-performing relational database and allow customers to leverage the cost-competitiveness that the UNIX market created in the hardware markets. Sybase — a company you may have heard of — was born.
Meanwhile, SAP was creating what it thought would be a mid-market version of its big mainframe ERP system, SAP R/2. One of the primary characteristics of SAP R/3 was that it ran on relatively low-cost UNIX hardware, and, in a further nod to cost effectiveness and choice (database portability and choice being a hallmark of the UNIX market of the time), SAP chose to support a multitude of relational databases, including the three that would eventually become the mainstays of the SAP R/3 market: Oracle, IBM DB2, and Microsoft SQL Server.
In order to support multiple databases, SAP created a software layer above the database that effectively meant that databases functioned in a least-common-denominator fashion in the SAP world — the database layer in SAP R/3 was like the governor on a go-kart, limiting speed and performance as a
sacrifice for providing a degree of safety.
Ironically, this least-common-denominator approach didn’t sit well with Sybase, which was one of the market leaders in the hotly competitive relational database market. Sybase balked at simplifying its database to meet SAP’s spec, and as a result, Sybase was aced out of the ERP market of the 1990s. When SAP eventually bought Sybase in 2012, it was in the middle of a revival based on support for the emerging mobility market, its glory days of database leadership long gone.
What ensued was a market marriage of inconvenience between SAP and three companies that would become erstwhile competitors: Oracle (which sold e-Business Suite), Microsoft (which sold Dynamics), and IBM, which claimed it didn’t sell enterprise applications but had a strategy of trying to convince customers to bury SAP in a commodity layer and buy all its innovation as a consulting project from IBM Global Services.
The marriage of inconvenience was further inconvenienced by the fact that the relational database advocates in the SAP customer base became a separate, and very powerful, force in enterprise decision making. And as the technology and business requirements of the enterprise evolved, particularly toward a real-time enterprise that needed to leverage big data and unstructured data, and support highly dynamic business processes, the relational database advocates became the Luddites of the enterprise, blocking innovation and keeping the cost of running the enterprise and its relational databases
The old least-common-denominator database layer is gone, and with it the drag in functionality.
The End Is Nigh
This brings us to why SAP S/4HANA signals the end of the database. The founders of Britton-Lee, it turns out, were right, albeit about 35 years too early. The fundamental fact remains that the closer the database is to the hardware, the better performance it will provide — that never went away. SAP S/4HANA adds an important nuance to this by doing two things. The first is well known: SAP HANA allows the database to run in-memory, which means that the database can be accessed by processing hardware at speeds orders of magnitude faster than what disk-based systems can provide.
The second is much less well-known: native SAP S/4HANA applications, like SAP Simple Finance, which is available today, and the pending follow-ons like SAP Simple Logistics and SuccessFactors and Ariba solutions, effectively write directly to the SAP HANA database. The old least-common-denominator database layer is gone, and with it the drag in functionality that being all things to all databases meant.
This has numerous other effects, one of which is that there is no separate buying decision about which database to use, or about whether an existing enterprise license for Oracle or IBM DB2 or Microsoft SQL Server can be extended to cover SAP solutions. The removal of choice also potentially undercuts the hegemony of the relational databases and their advocates: making the case for staying with the incumbent relational database will also mean making the case for missing out on the innovation, speed, and flexibility promised by SAP S/4HANA.
Finally, as SAP’s partners begin to move their development efforts toward SAP S/4HANA, it will become clear that, from a development standpoint, there is no separation between the database layer and the applications layer — the database effectively goes away, replaced by a monolithic SAP S/4HANA development environment, SAP HANA Cloud Platform, that is as close to Britton-Lee’s vision of an ultra-fast database as anything in the market.
In the end, the brilliance of SAP HANA is that it will become transparent, ceding the limelight to the applications and business processes that are what really make the difference in the enterprise. This doesn’t mean that SAP HANA won’t be an important differentiator for SAP and SAP S/4HANA — it most definitely will. But ensuring that next-generation business decisions are made for the right business reasons — and not just because the underlying database is superfast or cool — is perhaps the greatest innovation of all.