SAP hat unter dem Code-Namen «Galaxy» während der letzten Monate die Business-Process-Management-Architektur (SAP BPM) aufgebaut. Diese Architektur ermöglicht es SAP, mit ihren Applikationen einen Paradigmawechsel hin zu einer serviceorientierten Architektur (SOA) zu vollziehen. SAP BPM ist allerdings mehr als nur ein neuer serviceorientierter Architekturansatz für die Lösungen von SAP. Es ist ein umfassendes SOA-Entwicklungsframework für SAP, für die Partner und für die Eigenentwicklungen der SAP-Kunden. SAP ermöglicht damit der Klientel, Applikationen in neuer Form zu erstellen. Flexible Business-Prozesse rufen nun granulare, vom SAP-System zur Verfügung gestellte oder vom Kunden geschaffene SAP- Services auf.
Die Entwicklung solcher Lösungen ist allerdings ein Bruch mit der herkömmlichen Art und Weise, SAP zu «customizen», ABAP-Funktionen zu bauen sowie diese einzuführen. Genau damit tun sich die traditionellen SAP-Entwickler und -Integratoren ohne eine SAP, die ihnen bei jedem Schritt Händchen hält, ziemlich schwer.
Ausgereifte und passende konventionelle Software-Engineeringverfahren, wie sie in der Individualentwicklung in der Nicht-SAP-Informatik zum Einsatz kommen, werden von der SAP-Community allzu schnell als nicht passend abgetan. Dabei verwendet SAP für das Verwalten der Standardsoftware-Komponenten selbst ein komponentenorientiertes Softwareentwicklungsverfahren. Dies lässt sich leicht daran erkennen, wie alle Komponenten der Standardsoftware und deren Abhängigkeiten systemtechnisch sauber im System Landscape Directory (SLD), unter Zuhilfenahme des CIM-Modells, abgelegt und verwaltet werden.
SAP-Kundeneinführungen werden meist noch nach der bewährten, angelehnt an die von SAP selbst propagierte Accelerated SAP-Einführungsmethodik (ASAP), umgesetzt – sofern überhaupt methodisch vorgegangen wird. Schliesslich handelte es sich bei SAP-Einführungen ursprüng--lich in erster Linie nicht um Entwicklungsprojekte, sondern um die einfache Anpassung eines Softwarepakets. Doch spätestens mit SOA hat sich die Welt verändert. Für die SAP- Community scheint es nun schwierig, mit diesen rasanten Veränderungen von SAP Schritt zu halten.
Was den im SAP-Umfeld eingesetzten Methoden wie ASAP- und BPM-Methodology fehlt, ist das Managen der unterschiedlichen Artefakte, der logischen und technischen Komponenten und deren Beziehungen untereinander. So ist schon bei simplem Customizing und reiner ABAP-Entwicklung eine effektive Auswirkungsanalyse von Änderungen auf die Sys-temkomponenten in den verschiedenen Phasen der Entwicklung kaum möglich! Falls nur die Einführung des Projekts für die SAP-Initiative im Vordergrund steht, braucht man sich hierüber nicht weiter den Kopf zu zerbrechen. Doch wer irgendwann sein System erweitern muss, ist darauf angewiesen zu wissen, wie beschreibende, logische und technische Lieferobjekte von Business Blueprints über ABAP-Programme und SAP- Customizing zusammenhängen und sich über die Zeit verändern.
Werden die Möglichkeiten der serviceorientierten Architektur von SAP genutzt, ist es unabdingbar, die Objekte der SAP-Landschaft und ihre Zusammenhänge konsequent zu verwalten. Die «SAP Business Process Management Methodology» für die Einführung von Systemen mit flexibel gestaltbaren Business-Prozessen, welche SAP und andere Services konsumieren, hilft in dieser Beziehung kaum weiter. Sie unterstützt primär die Definition der Business-Prozesse, jedoch nicht die Definition und die Umsetzung des zugrunde liegenden SAP-SOA-Komponentenmodells.
SOA ist ein starkes Architekturkonzept für SAP selbst, um die eigenen Systeme flexibel und attraktiv weiterzuentwickeln und um Kunden-Services zur Verfügung zu stellen. Wie wenig weit SAP selbst mit der SOA-Umsetzung bei seinen Systemen fortgeschritten ist, zeigt sich allerdings in konkreten Kundenprojekten schnell. Bisher steht für die Entwicklung von Standardfunktionen des SAP Backends höchs-tens ein kleiner zweistelliger Prozentsatz als aufgebaute Services zur Verfügung. Für weitere Funktionen zeigt SAP den Kunden noch nicht auf, wie und womit sie damit selbst Services entsprechend ihren Anforderungen bauen können.
Beim Verteilen von Hotpackages und neuen Releases zeigt sich, dass SAP die eigene serviceorientierte Architektur noch nicht einmal nutzt, um Abhängigkeiten in der eigenen Software zu reduzieren. Noch immer werden Kunden Änderungen mit Abhängigkeiten kreuz und quer über alle Ebenen der Anwendung zur Verteilung übergeben. Dabei wäre es möglich, durch eine relativ einfache Aufteilung in Systemkomponenten das SAP-Change-Management massiv zu erleichtern.
Ein reales SAP-Grossprojekt, das konsequent auf einer serviceorientierten Architektur aufbaut, hat dies beispielsweise durch die einfache Aufteilung in fünf Systemkomponenten erreicht. Es werden das Portal als rollenorientiertes Interface, der Application Server für die GUI-Logik, die BPEL Process Execution Engine, das SAP-ERP-Backend und der EAI-Bus als Architekturelemente unterschieden. Die Systemkomponenten werden entkoppelt und jede für sich kann mit einer vierstufigen Systemlandschaft für Entwicklung, Test, Qualitätssicherung, Produktion unabhängig umgesetzt werden.
Wie erwähnt setzt selbst SAP beim Ent-wickeln von SOA-basierten Bestandteilen seiner Software nicht mehr auf die eigenen Methoden und auf Werkzeuge der guten alten ABAP-Zeiten. SAP hat im Bereich des Lebenszyklus-Managements seiner Standardapplikation die Hausaufgaben gemacht und verwendet moderne, komponentenbasierte Methoden und Werkzeuge. Es ist nun an der SAP-Kunden- und Berater-Community, dies für ihre eigenen Umsetzungen auch zu tun, um so analog profes-sionellem, modernem Software-Engingeering vor Ort in Unternehmen nachhaltig SAP-Anwendungen warten und weiterentwickeln zu können. Wäre es nicht bemühend, könnte es fast amüsieren, zu sehen, wie schwer sich erfahrene SAP-Berater tun, wenn alte Ansätze nicht mehr genügen und von SAP einmal keine Methoden und Werkzeuge angeboten werden.
Damit eine wie vom SAP-Marketing suggerierte Unternehmens-Applikationslandschaft basierend auf SAP-Services und entsprechender SAP-SOA-Architektur überhaupt erst zum Einsatz kommen kann, muss sich der SAP-Kunde im Klaren sein, wie er die Versionen und die Abhängigkeiten zwischen den unterschiedlichen Systemkomponenten – also technischen und beschreibenden, logischen Komponenten der Entwicklung und auch den verschiedenen Services in der Produktion – verwaltet. Er muss seine gesamten SAP-Entwicklungsverfahren so ausrichten, dass er «morgen» jeden einzelnen «Service» als eigenständige Komponente mit allen Abhängigkeiten unterhalten kann. Dies war auch in der Vergangenheit schon ein Bedürfnis – mit zusätzlichem, eigentlich unnötigem Aufwand allerdings noch im Griff zu behalten. Spätestens mit der aktiven Nutzung einer serviceorientierten Architektur muss eine typische komponentenorientierte Software-entwicklung auch im SAP-Umfeld Einzug halten: Nur so kann ein effektives Impact-Management als Voraussetzung für eine effektive Entwicklung und ein zielgerichtetes Testing zur Verfügung gestellt werden.
