Mit seiner serviceorientierten Architektur (SOA) erlaubt SAP den Kunden Applikationen in neuer Form zu erstellen. Flexible Business Prozesse rufen dabei 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 und ABAP Funktionen zu bauen und einzuführen. Und genau damit tun sich die traditionellen SAP Entwickler und Integratoren doch 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 einfach als nicht passend abgetan. Dabei verwendet selbst SAP für das Managen der Standardsoftware-Komponenten ein komponentenorientiertes Softwareentwicklungverfahren. Dies lässt sich leicht daran erkennen, wie alle Komponenten der Standardsoftware und deren Abhängigkeiten systemtechnisch sauber im System Landscape Directory, 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- (ASAP-) Einführungsmethodik umgesetzt – sofern diese überhaupt methodisch eingeführt werden. Schliesslich handelte es sich bei SAP Einführungen nicht in erster Linie um Entwicklungsprojekte, sondern um die reine Einführung und Anpassung eines Softwarepakets. Doch spätestens mit SOA hat sich die Welt verändert. Für die SAP Community scheint es 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 Systemkomponenten 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 nun 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. Sollten hier nicht noch geschrieben werden warum Die BPM Methodology hilft primär bei der Abstrahierung von Business Prozessen ins BPM – Tool von SAP, macht aber keine Aussage darüber wie konsequent die Software-Engingeering hinsichtlich des Komponentenmodells umgesetzt werden sollte.

SOA ist ein starkes Architekturkonzept für SAP selbst, um die eigenen Systeme flexibel und attraktiv weiter zu entwickeln und um Kunden Services zur Verfügung zu stellen. Kunden zeigt SAP jedoch nicht auf, wie und womit sie selbst serviceorientierte Systeme mit SAP Funktionalität bauen sollen.

Wie schon erwähnt setzt selbst SAP beim Entwickeln von SOA basierten Bestandteilen seiner Software nicht mehr auf die Methoden und Werkzeuge der guten alten ABAP-Zeiten. SAP hat im Bereich des Lebenszyklus-Management seiner Standardapplikation die Hausaufgaben gemacht und setzt auf moderne komponentenbasierte Methoden und Werkzeuge. Es ist nun an der SAP Kunden- und Berater-Community dies für Ihre eigenen Umsetzungen zu tun, um analog professionellem, modernem Software-Engingeering andernorts 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 einmal von SAP keine Methoden und Werkzeuge angeboten werden und alte Ansätze nicht mehr genügen.

Fazit

Damit eine, wie von 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 erst recht 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 Softwareentwicklung 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.