Open doors for databases

From a marketing perspective, the history of database use from SAP's point of view is a masterstroke: for decades, they degraded the best databases to primitive data stores.

Intelligent data processing took place exclusively in the SAP application servers. People loudly grumbled about the incompetence of DB vendors and what poor performance they were delivering.

Hana was invented, and to improve ERP performance, SAP now enabled a step that IBM, Oracle, and Microsoft were denied for years - data processing functions may and must be moved from the ERP application server closer to the data in the database server.

Which customer had the highest sales in the first quarter? A simple and elementary function for any SQL database: find the maximum in a table.

Any provider can do this within a few milliseconds, regardless of the DB size. Not so in an R/3 system! First the whole table has to be loaded from the database server to the application server, then an Abap program starts to find now the maximum in the local table.

This highly simplified example illustrates the basic data path in an R/3 System. The database server is only a memory, the complete application logic took and takes place in the application server.

This also explains why, before the great virtualization wave, there was also a separate server for each R/3 module in the R/3 data centers. A lot of sheet metal - to the delight of the hardware vendors.

SQL databases can do more! The concept of a very reduced and standardized handling of the databases under R/3 made a lot of sense for SAP. This made it possible to appear "neutral" on the market and give IBM, Oracle and Microsoft the chance to become part of the community.

Where there is light, there is also shadow: This generic database approach all too often sent the response time behavior into the basement. The SAP scene tried to keep the respective response time just under one second with enormous hardware expenditure - in the long run, this was naturally not a successful path.

When Hana came on the market and SAP was forced to prove its performance, they relaxed the concept. Viewed precisely, it was a revolution, even if it sounded very "simple":

In the future, the ERP functions are to be more closely coupled to the data and basic functions such as min/max search, currency conversion, etc. are to be completely outsourced from the Abap code and executed as original database functions.

This is theoretically the hour of the database providers IBM, Oracle and Microsoft. If every data processing step no longer has to take place in the Abap server, then the SQL database can prove its performance.

So with Hana, SAP was forced to use the ERP database for the first time not as a data archive, but as an intelligent system for data management. A key function for the interface between the ERP application server and the SQL database are the Core Data Services, and there is a document on this:

SAP Hana Core Data Services (CDS) Reference, SAP Hana Platform SPS 09, Document Version 1.1 (2015-02-16, PDF 120 pages). Among other things, IBM is putting some hope in this interface to make DB2 more attractive again for Business Suite 7 users (ECC 6.0).

But not only with S/7, but also with S/4, CDS and subsequently BFL (SAP Business Function Library) could become an opportunity for IBM, Oracle and Microsoft. There is also a PDF with 158 pages on BFL.

The moderate speed of an R/3 system was thus also due to the software architecture: The interaction of database server and application server, i.e. the first two stages of SAP's three-tier client/server model, was anything but optimal.

By developing its own SQL database, SAP seems to have painfully recognized this problem. The "innovation" that data and functions are now moving closer together on the Hana database platform was thus also presented with a lot of fuss and enthusiasm.

Too much of a good thing? Once the interface between the application server and the database server was broken down, SAP immediately programmed numerous ERP functions as database functions, so that the ERP Abap application code mutates into a call to Hana functions over long stretches.

The best way to see what the Hana platform can do is to read SAP Hana Predictive Analysis Library (PAL), SAP Hana Platform SPS 09, Document Version 1.1 (2015-10-16, PDF 384 pages). That, in turn, could become a stopper for IBM, Oracle and Microsoft.

Hana is also an SQL database. Through CDS, there is a transparent layer between the application server and the database server. S/7 and S/4 can also use the "intelligent" SQL functions of a database, which has a positive effect on processing speed.

But Hana is also much more than a SQL database, see PAL, and thus SoH (S/7 on Hana) and S/4 will offload much more to the underlying platform than the SQL databases from IBM, Oracle and Microsoft can provide.

SAP has thus made good use of the "opening", on the one hand to dramatically improve the response time behavior, and on the other hand to immediately exclude the competitors.

So how IBM, Oracle and Microsoft will and want to use the favor of the hour on the basis of CDS in the future is still uncertain at the moment. The fact is, however, that CDS/BFL opens up a large window of options for all SQL databases.