SAPs Marketing hat eine lange Tradition, aktuelle Schlagworte konsequent für sich zu nutzen. Cloud Computing ist in, also redet SAP von Cloud Computing. Um jedoch SAP als Cloud-Angebot 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 Geschäftsprozesse 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 Cloud-Leistungen schon längs-tens 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.
1. Paketsoftware: Vier IBM-Softwarespezialisten gründen SAP mit einem der ersten transaktionalen Modelle auf Mainframe-Basis, SAP R/2 ist geboren. Anfänglich ausschliesslich mit Modulen für das Rechnungswesen, sukzessive werden Module für neue Bereiche wie Logistik in der von SAP selbst entwickelten Programmiersprache ABAP entwickelt.
2. Client Server: SAP portiert R/2 auf IBM AS/400. Das System läuft allerdings nie zufriedenstellend. In einem zweiten Schnellversuch wird erfolgreich auf HP Unix portiert. Daraus ergibt sich die ABAP-basierte Client-Server-Applikation SAP R/3. Diese verfügt gegenüber R2 über eine grafische Benutzeroberfläche. Wie schon für R/2 werden sukzessive neue Funktionalitäten entwickelt, und es entstehen weitere Releases bis SAP R/3- Rel. 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 dem Release 3.0 hat es SAP geschafft, Markttrendsetter zu sein. Der Begriff ERP wird schon fast ein Synonym für SAP R/3. Grossfirmen setzen immer mehr darauf. Durch das Wachstum und den Gross-einsatz und 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: SAP hat eine Antwort auf die Internet-Euphorie: SAP R/3 Rel. 3.1 mit ITS (Internet-Transaction-Server). 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. Komponentenarchitektur: Um neue, trendige Applikationen in die Plattform integrieren zu können, versucht SAP mit SAP R/3-Release 4.0 den starken SAP-Basis-Kernel vom 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 Applika-tionen basiert nur noch auf ALE. Die Trennung der SAP-Basis ist auch die Grundlage für weitere nicht mehr rein als Enterprise Resource Planning einzustufende Business-Funktionalität: BW (Business-Warehouse) und CRM (Cus-tomer Relationship Management). SAP ist nun zwar immer noch auf ABAP basierend, aber bestehend aus verschiedenen ABAP-Komponenten – ABAP-heterogen!
6. Single-Sign-on: SAP erkennt, dass das Anmelden der Benutzer an nunmehr verschiedenen Systemen als Konsequenz der ABAP-Heterogenität beseitigt werden muss. Es wird mit SAP R/3-Rel. 4.5 ein ABAP-Workplace lanciert. Dieser stellt auf Basis SAP GUI Single-Sign-on zur Verfügung, welcher die Absprünge in die unterschiedlichen ABAP-Produktivsys-teme steuert.
7. Portal: Der gesamte Markt spricht von Portalen, und SAP kann mit seinem ABAP-basierenden Portal Workplace den modernen Ansprüchen an Portale 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. Java und ABAP gehen eine folgenschwere Verbindung ein.
8. 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: Das SAP-Marketing springt auf die nächste Architekturwelle auf: serviceorientierte-Architektur (SOA). So lanciert SAP ESOA, mittlerweile SAP SOA genannt. Unter anderem erfüllt SAP damit vermeintlich eine der Voraussetzungen für ein Cloud-Computing-Angebot.
Diese 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 System mit einer Architektur zustande, das eine Anzahl produktiver Systeme mit Datenbanken im grossen zweistelligen Bereich umfasst. Dies ohne die der Produktion vorgelagerten Entwicklungs-, Test-, Staging-, Prototyp- und Schulungssysteme. Diese Komplexität zu managen, kann sehr aufwendig werden. Und nun soll mit der nächsten Marketingwelle – Cloud Computing – ein solches System für die Anforderungen von einzelnen Anwendern «On Demand» aufgebaut werden? Und dies als Internet-Service 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 «Business by Design» für jeden Kunden auf einer logisch eigenen Installation von SAP. Wie will SAP die Individualität jeder 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 aufgezeigten «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 Client-Server-Welt um weitere Architekturebenen als Unterstützung für die Internet-Technologie. SAP selbst muss nun im Infrastrukturbereich weitere zusätzliche produktive Server-Ebenen hinzufügen, was die Komplexität des Systems und Unterhalts noch erhöht. Dank der letzten Technologie-Evolution von SAP, nämlich SAP SOA, werden Business-Funktionen im Web zur Verfügung gestellt, im SAP-Standard allerdings bloss ein einstelliger Prozentsatz. Hierbei ist zu beachten, dass Webfunktionalität von SAP oft nicht 1:1 bei Kunden installierter SAP-Funktionalität entspricht. In SAPs Brust schlagen zwei Herzen, eines für die alteingesessenen «Abapeure» und eines für die neuen «Java-Freaks». Diese schlagen jedoch nicht immer synchron.
Kann nun eine auf einem 20 Jahre alten Konzept basierende Funktionalität und das zugehörige Sys-tem-umfeld den Ansprüchen von modernem Cloud Comput-ing Rechnung tragen? Aus meiner Sicht ist die von Cloud Computing geforderte Virtualisierung und Skalierbarkeit von Sys-temwelt und Da---tenhaltung für eine dermassen auf individuellen Einstellungen basierenden, transaktionalen Verarbeitung von Geschäftsdaten im grossen Umfang nicht mit vernünftigem Aufwand machbar. SAP versucht ein weiteres Mal auf einer Marketing-Welle mitzureiten – «auf der Wolke mitzufliegen». Ob es sich bei dieser Wolke für SAP um eine gefährliche Gewitterwolke 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 Sys-teme. Werkzeuge wie SAP Solution Manager sind für diese umfassende 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 SAPs «Cloud»-Angebot Business by Design nur schleppend vorankommt? Ein schnelles Anwachsen von Business-by-Design-Anwendern ohne eine entsprechend ausgeklügelte, individuelle Kundenprovisionierungs- und Lifecycle-Management-Lösung wäre auf jeden Fall fatal für SAP.
Für den SAP-Business-by-Design-Kunden ist dies im Prinzip kein Problem, solange das Angebot preislich und technisch stimmt. Aber ist SAP wirklich in der Lage, über Marketing-Mitteilungen hinaus ein solches Angebot 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.
· Die SAP-Technologie basiert auf 20 Jahre alten Funktionalitäten.
· Es ist fraglich, ob die für Cloud Computing nötige Virtualisierung und Skalierbarkeit von SAP mit vernünftigem Aufwand gewährleistet werden kann.
· Die Verarbeitung von Geschäftsdaten geschieht zu individuell, als dass dies möglich wäre.
