Auch neue und komplexe Systeme können stabil sein

Oberstes Ziel aller SAP-Organisationen dieser Welt lautet Stabilität. Gemäß der Devise „Never touch a running system“ sammeln sie weiterhin Patches, Anpassungen und Individualentwicklungen, vereinen sie in einem großen Release, unterziehen dieses ausgiebigen und wiederholten Tests und setzen es einmal oder höchstens zwei Mal im Jahr produktiv. Auch in der neuen S/4-Welt soll sich daran nichts ändern. Nicht zuletzt deshalb verkürzen viele SAP-Bestandskunden die Diskussion über das Thema Cloud unzulässigerweise auf die Frage nach dem idealen Implementierungs- und Betriebsort der neuen Softwaregeneration aus Walldorf.

Dabei ist die Cloud für die SAP in erster Linie eine Frage der optimalen Architektur für Software und die Softwareentwicklung der Zukunft. Das bedeutet funktionsspezifische und wiederverwendbare Services statt Softwaremonolithen und das Veröffentlichen von Korrekturen, Änderungen und Erweiterungen in hoher Schlagzahl, sobald sie verfügbar sind. Vorbei sind damit die Zeiten großer Releases in ebenso großen zeitlichen Abständen.

Damit einher geht die von SAP ausgegebene Devise „Keep the core clean“. Walldorf ermutigt SAP-Bestandskunden, individuelle Anpassungen nur noch als Extensions zu entwickeln und bereitzustellen. Und damit kein Nebeneinander von schnellen und flexiblen Änderungen im Kern einerseits und in den Extensions andererseits entsteht, empfiehlt die SAP ihren Kunden, dem goldenen Pfad ihres Cloud Application Programming Model (CAP) zu folgen. Die Entwickler können sich in diesem Modell auf ihre spezifischen Aufgaben konzentrieren und Code in anderen Programmiersprachen als Abap entwickeln. Alles geht in Richtung offener Standards für eine höhere Kompatibilität und Wiederverwendbarkeit, auch und gerade im Zusammenspiel mit Drittanwendungen.

Immer mehr Änderungen in immer kürzerer Zeit, viele kleine Releases in hoher Frequenz, mehr Programmiersprachen, konsequente Trennung von Datenbank-, Applikations- und Darstellungsebene – die SAP-Welt wird in der neuen Generation komplexer. Mehr Komplexität bedeutet aber mehr Aufwand und mehr Fehlerquellen, der Horror für SAP-Organisationen, die umso beharrlicher am Status quo festhalten.

Dabei verläuft die Grenze zwischen Befürwortern und Gegnern des Wandels nicht zwischen IT und dem Rest des Unternehmens, sondern innerhalb der IT zwischen Entwicklung und Betrieb. Gestern bestellt, heute geliefert – das erwarten nicht nur die Fachanwender, sondern auch die Entwickler. Sie wollen nicht warten, bis die Testumgebung für ihre mit agilen Methoden erstellten Änderungen und Erweiterungen bereitsteht, noch wollen sie sich mit deren Auswirkungen auf Betrieb und Stabilität der Produktivumgebung aufhalten.

Ihr Ideal besteht in Standardisierung und Auto-matisierung. Doch dafür brauchen sie ihre Kollegen im IT-Betrieb. Und die müssen sie besser verstehen. Genau darauf zielt das DevOps-Konzept ab, das durch die enge Zusammenarbeit in interdisziplinären Teams die dafür nötige Basis schafft.

DevOps ist zuallererst eine Frage der Kultur. Und weil diese in vielen SAP-Organisationen fehlt, bleibt das Vertrauen in diesen Ansatz aus. Ohne dieses Vertrauen entsteht aber auch keine Graswurzelbewegung, die irgendwann eine kritische Masse erreicht und gleichsam von selbst für den nötigen Wandel sorgt. Das hat die Erfahrung der vergangenen drei bis fünf Jahre wider Erwarten gezeigt.

Ein Machtwort aus dem Management muss Dev-Ops erzwingen. Denn ohne Agilität wird in der Cloud-Ära aus einem „running system“ schnell ein „failing system“. Eine durchgängige Tool-Chain – von der Entwicklung und iterativen Fehlerbehebung bis zum Testen und Ausliefern des Codes – hilft, die Akzeptanz für diese Entscheidung zu fördern: Damit das in der Zusammenarbeit gewonnene Vertrauen nicht an der harten Realität der Produktivsysteme zerbricht, sondern beide – Entwicklung und Betrieb – von der schnellen und häufigen, jedoch risikoarmen Softwarebereitstellung profitieren.