SAP Marketing hat eine lange Tradition aktuelle Schlagworte konsequent für sich zu nutzen. SAP Cloud Computing ist in, also redet SAP von Cloud Computing. Um jedoch SAP als Cloud Offering zur Verfügung zu stellen, bedeutet das sämtliche SAP Funktionen via Web Browser anzubieten. Doch es gehört noch mehr dazu. Wenn einzelne Benutzer SAP Funktionalität in der Cloud konsumieren wollen, muss dafür auch vorgängig die Datenhaltung und die Parametrisierung der Systeme und der SAP Business Prozesse für den individuellen Kunden vorgenommen werden. Meiner Meinung nach ist dies für SAP viel schneller gesagt als getan. Aber warum? Andere Paketsoftwarehersteller bieten solche Cloudleistungen schon längstens an. Um die Frage zu beantworten, ist es nützlich, zu verstehen, wie SAP technisch aufgebaut ist. SAP ist nämlich eine Software, die über viele, teils dramatische Evolutionen zu dem geworden ist, was wir heute locker als „SAP“ bezeichnen. Eine kurze Einführung in die SAP R/3 Softwarearchitektur lässt schnell tiefer blicken.

Die SAP Evolution von SAP R/3

1. Paketsoftware: Vier IBM Softwarespezialisten gründen SAP mit einem der ersten transaktionalen Modelle auf Mainframebasis,  SAP R/2 ist geboren. Anfänglich ausschliesslich mit Modulen für das Rechnungswesen, sukzessive werden Module für neue Bereichen wie Logistik  in der von SAP selbst entwickelten Programmiersprache ABAP entwickelt.

2. Client Server: Die Client-Server Welle schwappt über zu SAP. SAP portiert R/2 zunächst auf IBM AS/400. Das System läuft allerdings nie zufriedenstellend. In einem 2. Schnellversuch wird erfolgreich auf HP Unix portiert. Daraus ergibt sich die ABAP-basierte Client Server Applikation SAP R/3. Diese verfügt gegenüber R/2 über eine grafische Benutzeroberfläche.
Wie schon für R/2 werden sukzessive neue Business-Funktionalitäten dazu entwickelt und es entstehen weitere Releases bis SAP R/3- Release 3.0. SAP R/3 besteht mittlerweile aus einer Vielzahl von Modulen, die in die drei Hauptmodule Rechnungswesen, Logistik und Human Resources zusammengefasst werden können.

3. Redundante Systeme: Mit SAP R/3 Rel. 3.0 hat es SAP geschafft, Markttrendsetter zu sein. Der Begriff ERP wird schon fast ausschliesslich ein Synonym für SAP R/3. Grossfirmen setzen immer mehr auf SAP R/3. Durch das Wachstum und den Grosseinsatz und die damit die hohen Anforderungen an die Skalierbarkeit wachsen die Herausforderungen an die grundlegende Technologie und Business-Funktionalität. Um den gestiegenen Erwartungen gerecht zu werden, lanciert SAP ALE (Application Link Enabling). Somit hat SAP als einer der ersten Paketsoftwarehersteller das Konzept der kontrollierten Redundanz in seiner Software-Suite institutionalisiert.

4. Internet: Es herrscht Internet-Euphorie und SAP hat auch eine technologische Antwort auf diesen Trend: SAP R/3 Rel. 3.1 mit SAP ITS (Internet Transaction Server). SAP ITS ist in der Lage, das SAP interne SAP GUI-Protokoll in http zu konvertieren und umgekehrt. So kann von einfachen HTML-Seiten direkt in die Business-Applikation SAP R/3 gesprungen werden.

5. SAP Komponentenarchitektur: Um neue, trendy Applikationen in die Plattform integrieren zu können, versucht SAP mit SAP R/3 – Release 4.0 den starken SAP Basis-Kernel vom SAP Applikations-Kernel zu trennen. Ebenso wird auf der Ebene der Applikationen eine Trennung vorgenommen. Das gesamte HR-Modul wird ABAP-technisch vom Rest der Hauptmodule Rechnungswesen und Logisik abgekoppelt. Die Kommunikation zwischen den Applikationen basiert ab diesem Zeitpunkt nur noch auf SAP ALE.
Die Trennung der SAP Basis ist dann auch die Grundlage für weitere nicht mehr rein als Enterprise Resource Planning einzustufende Business-Funktionalität: SAP BW (Business-Warehouse) und SAP CRM (Customer Relationship Management). SAP ist nun zwar immer noch auf ABAP basierend, aber bestehend aus verschiedenen ABAP-Applikations Komponenten – ABAP heterogen!

6. Single Sign On: SAP erkennt schnell, dass das Anmelden der Benutzer an nunmehr verschiedenen Systemen als Konsequenz der ABAP-Heterogenität beseitigt werden musste. So lancierte SAP mit SAP R/3 – Release 4.5 einen ABAP-basierenden Workplace. Dieser stellt auf Basis SAP GUI einen Single-Sign-On zur Verfügung, welcher die Absprünge in die unterschiedlichen ABAP-Produktivsysteme steuert.

7. SAP Portal: Der gesamte Markt spricht von Portalen und SAP kann mit seinem „ABAP-basierenden Portal Workplace“ den modernen Ansprüchen an Portalen absolut nicht genügen.
So kauft SAP Top-Tier, welche zum Zeitpunkt bereits eine auf dem SAP HTML-GUI basierende Schnittstelle entwickelt hat.
Mit dieser Akquisition übernimmt SAP zum ersten Mal eine nicht ABAP-basierende Technologie. SAP Java und ABAP gehen eine folgenschwere Verbindung ein.

8. SAP Application Server: Mit der nun auch technologischen Java/ABAP-Heterogenität der Komponenten lanciert SAP das Marketingkonstrukt SAP NetWeaver, mit dem Ziel, die beiden äusserst unterschiedlichen Technologien über eine gemeinsame Plattform zu nutzen. Unter SAP NetWeaver werden die folgenden sieben kaufbaren Produkt-Suiten zusammengefasst:
• SAP NetWeaver Application-Server ABAP – hierauf werden die ABAP-basierenden Business-Systeme zur Verfügung gestellt.
• SAP NetWeaver Application-Server Java – hierauf werden die Java-basierenden Systeme zur Verfügung gestellt.
• SAP NetWeaver BI (Business-Intelligence – vormals BW)
• SAP NetWeaver PI (Process-Execution, zunächst XI genannt)
• SAP NetWeaver Portal
• SAP NetWeaver MDM (Master-Data-Management)
• SAP NetWeaver Mobile

9. Service Oriented Architecture: SAP Marketing springt nun nach Client/Server auf die nächste grosse IT-Architekturwelle auf: Service-Orientierte-Architektur (SOA). So lanciert die Firma SAP ESOA, mittlerweile nur noch SAP SOA genannt. Unter anderem erfüllt SAP damit vermeintlich eine der Voraussetzungen für ein Cloud Computing-Angebot.

Datenhaltung der Business-Prozesse

Diese SAP Evolutionen geben einen Eindruck davon, wie komplex und umfangreich mittlerweile ein SAP-System aus Komponenten aufgebaut ist. Bei SAP Enterprise-Installationen, in welchen die gesamte Business-Suite von SAP eingesetzt wird, kommt aus historischen Gründen und aufgrund von Kundenanforderungen schnell ein SAP System mit einer Architektur zustande, die eine Anzahl produktiver Systeme mit Datenbanken im grossen zweistelligen Bereich umfassen. Dies noch ohne die der Produktion vorgelagerten Entwicklungs-, Test-, Staging, Prototyp- und Schulungssysteme. Diese SAP Komplexität für einen Kunden zu managen, kann sehr aufwändig werden. Und nun soll mit der nächsten Marketingwelle – SAP Cloud Computing – ein solches System für die Anforderungen von einzelnen Anwendern on Demand aufgebaut werden? On Demand in der Wolke für Nutzer von Hunderten von verschiedenen Kunden mit unterschiedlichen Anforderungen in Bezug auf Systemeinrichtung. Bekannterweise und mit Kenntnis der Vorgeschichte und der SAP Softwarearchitektur verständlich, basiert „SAP Business by Design“ für jeden Kunden auf einer logisch eigenen Installation von SAP! Wie will SAP die Individualität jeder einzelner dieser Installationen managen, geschweige denn bei Änderungen mit vernünftigem Aufwand verstehen, was diese für die einzelnen Systeme bedeuten? Das Lifecycle Management über die Cloud hinweg ist eine zu gewaltige Herausforderung.
Aus dem aufgezeigte„SAP Evolutionsmodell“ kann man schliessen, was es für SAP bedeutet, SAP Business-Funktionalität eines SAP-Backend-Moduls in einem Browser benutzergerecht rollenbasiert zur Verfügung zu stellen. Deshalb erweitert SAP seine R/3 Client-Server-Welt um weitere Architekturebenen als Unterstützung für die Internet-Technologie. SAP selbst muss nun im Infrastrukturbereich noch weitere zusätzliche, produktiver Server-Ebenen hinzufügen, was die Komplexität des Systems und Unterhalts noch mehr in die Höhe schraubt.

SAP Funktionalität mitsamt Daten in die „Wolke“

Dank der letzten Technologie-Evolution von SAP, nämlich SAP SOA, werden SAP Business-Funktionen im Web zur Verfügung gestellt, im SAP Standard allerdings bloss ein einstelliger Prozentsatz der SAP-Business-Funktionalität. Hierbei ist auch zu beachten, dass Webfunktionalität von SAP oft nicht 1:1 bei Kunden installierter SAP Funktionalität entspricht. In SAP’s Brust schlagen zwei Herzen, eines für die alteingesessenen „ABAPeure“ und eines für die „neuen Java-Freaks“. Diese schlagen noch nicht immer synchron.

Fazit SAP Cloud Computing

Kann nun eine auf einem 20 Jahre alten Konzept basierende Business-Funktionalität und das zugehörige Systemumfeld den im ersten Absatz aufgeführten Ansprüchen von modernem Cloud Computing Rechnung tragen? Aus meiner Sicht ist die von Cloud Computing geforderte Virtualisierung und Skalierbarkeit von Systemwelt und Datenhaltung für eine dermassen auf individuellen Einstellungen basierende, transaktionale Verarbeitung von Geschäftsdaten im grossen Umfang nicht mit vernünftigem Aufwand machbar. SAP versucht ein weiteres Mal von Anfang an auf einer Marketing-Welle mitzureiten – „auf der Wolke mitzufliegen“. Ob es sich bei dieser Wolke für SAP um eine gefährliche Gewitterwolke für SAP handelt?
Bisher kümmerte sich SAP in erster Linie darum, die Veränderungen am eigenen Code im Griff zu haben und die Kunden beim Software-Upgrade zu unterstützen. Mit SAP als Cloud Computing Angebot ist das vorbei. Hiermit muss SAP individuelle Kundenumgebungen aufsetzen und sie über den Lebenszyklus unterhalten – nicht nur den SAP Code, auch die gesamte Konfiguration und alle Systeme. Werkzeuge wie SAP Solution Manager sind für diese umfassende SAP Change Management Aufgabe nicht geschaffen und können nur punktuell helfen. Problemstellungen, mit denen sich bisher in erster Linie die Kunden herumgeschlagen haben, werden zur Herausforderung für SAP selbst.

Ob dies wohl der Grund ist, warum SAP’s „Cloud“-Angebot Business byDesign scheinbar nur schleppend vorankommt? Ein schnelles Anwachsen von Business byDesign Anwendern ohne eine entsprechend ausgeklügelte, individuelle SAP Kundenprovisionierungs- und SAP Lifecycle Management – Lösung wäre auf jeden Fall fatal für SAP.
Für den SAP Business byDesign-Kunden ist dies im Prinzip kein Problem, solange das Cloud-Angebot von SAP preislich und technisch stimmt. Aber ist SAP wirklich in der Lage, über Marketing-Messages hinaus ein solches Offering im grossen Stil kostengünstig zu liefern? Es ist an SAP, dies zu beweisen. Gelingt dies nicht, werden entweder SAP oder die SAP Cloud-Computing Anwender teuer dafür bezahlen.