Offene Türen für Datenbanken
Aus Marketingsicht ist die Historie der Datenbankverwendung aus SAP-Sicht eine Meisterleistung: Jahrzehntelang degradierte man die besten Datenbanken zu primitiven Datenspeichern.
Intelligente Datenverarbeitung fand ausschließlich in den SAP-Applikationsservern statt. Man schimpfte lautstark über die Unfähigkeit der DB-Anbieter und welche schlechte Leistung diese erbringen.
Man erfand Hana und um die ERP-Leistung zu verbessern, ermöglichte SAP nun einen Schritt, den man IBM, Oracle und Microsoft jahrelang vorenthielt – Datenverarbeitungsfunktionen dürfen und müssen aus dem ERP-Applikationsserver näher zu den Daten in den Datenbankserver verlagert werden.
Welcher Kunde hatte im ersten Quartal den höchsten Umsatz? Für jede SQL-Datenbank eine einfache und elementare Funktion: in einer Tabelle das Maximum suchen.
Das schafft jeder Anbieter innerhalb weniger Millisekunden, unabhängig von der DB-Größe. Nicht so in einem R/3-System! Zuerst muss die gesamte Tabelle vom Datenbankserver auf den Applikationsserver geladen werden, dann startet ein Abap-Programm, um in der lokalen Tabelle nun das Maximum zu finden.
Dieses stark vereinfachte Beispiel veranschaulicht den prinzipiellen Datenpfad in einem R/3-System. Der Datenbankserver ist lediglich ein Speicher, die komplette Anwendungslogik fand und findet im Applikationsserver statt.
Daraus erklärt sich auch, warum es vor der großen Virtualisierungswelle in den R/3-Rechenzentren für jedes R/3-Modul auch einen eigenen Server gab. Viel Blech – zur Freude der Hardware-Anbieter.
SQL-Datenbanken können mehr! Das Konzept eines sehr reduzierten und normierten Umgangs mit den unter R/3 liegenden Datenbanken machte für SAP viel Sinn. So konnte man „neutral“ am Markt auftreten und IBM, Oracle und Microsoft die Chance geben, ein Teil der Community zu werden.
Wo Licht ist, ist auch Schatten: Dieser generische Datenbankansatz schickte nur allzu oft das Antwortzeitverhalten in den Keller. Man versuchte in der SAP-Szene mit gewaltigem Hardware-Aufwand die jeweilige Antwortzeit knapp unter einer Sekunde zu halten – auf Dauer war das naturgemäß kein erfolgreicher Weg.
Als Hana auf den Markt kam und SAP zum Leistungsbeweis gezwungen war, lockerte man das Konzept. Genau betrachtet war es eine Revolution, auch wenn es sehr „simple“ klang:
Die ERP-Funktionen sollen zukünftig näher an die Daten gekoppelt werden und Basisfunktionen wie Min/Max-Suche, Währungsumrechnung etc. sollen vollständig aus dem Abap-Code ausgegliedert und als originäre Datenbankfunktion ausgeführt werden.
Hier schlägt theoretisch die Stunde der Datenbankanbieter IBM, Oracle und Microsoft. Wenn nicht mehr jeder Datenverarbeitungsschritt im Abap-Server erfolgen muss, dann kann die SQL-Datenbank ihre Leistung unter Beweis stellen.
Mit Hana war also SAP gezwungen, die ERP-Datenbank erstmals nicht mehr als Datenarchiv, sondern als intelligentes System für das Datenmanagement zu verwenden. Eine Schlüsselfunktion für die Schnittstelle zwischen ERP-Applikationsserver und SQL-Datenbank sind die Core Data Services, dazu gibt es ein Dokument:
SAP Hana Core Data Services (CDS) Reference, SAP Hana Platform SPS 09, Document Version 1.1 (2015-02-16, PDF 120 Seiten). Unter anderem setzt IBM einige Hoffnung in diese Schnittstelle, um DB2 wieder attraktiver für Business-Suite-7-Anwender (ECC 6.0) zu machen.
Aber nicht nur bei S/7, sondern auch bei S/4 könnte CDS und in der Folge BFL (SAP Business Function Library) eine Chance für IBM, Oracle und Microsoft werden. Auch zu BFL gibt es ein PDF mit 158 Seiten.
Die mäßige Geschwindigkeit eines R/3-Systems war somit auch der Software-Architektur geschuldet: Das Zusammenspiel von Datenbank- und Applikationsserver, also die ersten zwei Stufen des SAP’schen dreistufigen Client/Server-Modells, war alles andere als optimal.
Durch die Eigenentwicklung einer SQL-Datenbank scheint SAP dieses Problem schmerzhaft erkannt zu haben. Mit viel Wirbel und Begeisterung wurde somit auch die „Innovation“ vorgestellt, dass nun Daten und Funktionen auf der Hana-Datenbankplattform näher zusammenrücken.
Des Guten zu viel? Einmal dabei, die Schnittstelle zwischen Applikations- und Datenbankserver aufzubrechen, hat SAP umgehend auch zahlreiche ERP-Funktionen als Datenbankfunktion ausprogrammiert, sodass der ERP-Abap-Applikationscode über weite Strecken zu einem Aufruf von Hana-Funktionen mutiert.
Was die Hana-Plattform leisten kann, ist am besten nachzulesen in SAP Hana Predictive Analysis Library (PAL), SAP Hana Platform SPS 09, Document Version 1.1 (2015-10-16, PDF 384 Seiten). Das könnte wiederum zum Stopper für IBM, Oracle und Microsoft werden.
Hana ist auch eine SQL-Datenbank. Durch CDS gibt es eine transparente Schicht zwischen dem Applikations- und Datenbankserver. S/7 und S/4 können auch die „intelligenten“ SQL-Funktionen einer Datenbank nutzen, was sich positiv auf die Verarbeitungsgeschwindigkeit auswirkt.
Hana ist aber auch wesentlich mehr als eine SQL-Datenbank, siehe PAL, und somit werden SoH (S/7 auf Hana) und S/4 wesentlich mehr an die darunter liegende Plattform auslagern, als die SQL-Datenbanken von IBM, Oracle und Microsoft bereitstellen können.
SAP hat somit die „Öffnung“ sinnvoll genutzt, um einerseits das Antwortzeitverhalten dramatisch zu verbessern, andererseits um gleich wieder die Mitbewerber auszuschließen.
Wie also IBM, Oracle und Microsoft zukünftig die Gunst der Stunde auf Basis von CDS nutzen werden und wollen, ist momentan noch ungewiss. Tatsache hingegen ist, dass sich mit CDS/BFL für alle SQL-Datenbanken ein großes Fenster an Optionen auftut.
