Si la culture fonctionne, la technique fonctionne aussi

Die DevOps-Bewegung – eine Kombination aus Kultur, Praxis und Tools, mit deren Hilfe Unternehmen Anwendungen und Services mit sehr hoher Schlagzahl bereitstellen können – ist stark vom CALMS-Konzept beeinflusst, das für die Begriffe Culture, Automation, Lean, Measurement und Sharing steht.

Kultur und Austausch – man könnte und sollte bei Letzterem vielleicht eher Kommunikation sagen – stehen am Anfang und am Ende, sie bilden sozusagen den Rahmen des gesamten Konzepts. Doch warum müssen beide Seiten – Dev und Ops – lernen, mehr miteinander zu reden? Die Frage mag im besten Fall naiv, im schlimmsten überflüssig oder sogar dumm erscheinen.

Und doch stellt sie sich seit dem Zusammenbruch des Internet­hypes 2000 und 2001 immer wieder. In der Folge war viel von der Industrialisierung der IT die Rede, auch bei der SAP. Seither galt die Technik nicht mehr als Selbstzweck, sondern musste dem Geschäft dienen und sich dessen Anforderungen unterordnen.

Standards wie ITIL (IT Infrastructure Library; Sammlung von Best Practices für Service Management) rückten bei vielen SAP-Bestandskunden in den Fokus, mit deren Hilfe die IT konsequent auf das Geschäft ausgerichtet werden sollte.

Und doch flammt die Diskussion wieder mit voller Wucht auf, seit die Unternehmens-IT von den großen Cloud-Anbietern herausgefordert wird. Es sind vor allem die Anwender, die ihre IT-Kollegen ihre Unzufriedenheit mit deren Arbeit spüren lassen.

Denn sie erwarten das gleiche Maß an Verfügbarkeit, Geschwindigkeit, Einfachheit und Komfort, wie sie es als Konsumenten mittlerweile gewohnt sind. Ist es ein Zufall, dass im Agile Manifesto, einer Art Charta für agile Softwareentwicklung, die Kundenorientierung an oberster Stelle steht?

Immer deutlicher wird damit, dass ITIL nicht alle oder sogar nur sehr wenige der daran geknüpften Erwartungen erfüllt hat. Doch was ist der Grund? ITIL konnte zwar tatsächlich IT und Geschäft näher zusammenbringen. Doch den IT-inhärenten

Widerspruch zwischen Entwicklung und Betrieb vermag das Regelwerk nicht aufzulösen. Denn es ist nun einmal die grundlegende Aufgabe der Entwickler, mit ihrer Arbeit auf Änderungen der geschäftlichen Anforderungen so schnell und so gut wie möglich einzugehen und diese umzusetzen.

Auf der anderen Seite ist es die grundlegende Aufgabe des IT-Betriebs, für die Stabilität und Zuverlässigkeit der IT-Dienste zu sorgen, die durch Änderungen am Programm-Code gefährdet werden. ITIL wurde jedoch niemals dafür konzipiert, diesen grundlegenden Zielkonflikt aufzulösen, während den großen Cloud-Anbietern genau das zu gelingen scheint.

Vertrauen statt Angst

Die meisten Unternehmen sind nach dem Prinzip der Arbeitsteilung organisiert. Jeder ist Experte auf seinem Gebiet und beherrscht die Aufgaben seines Verantwortungsbereichs aus dem Effeff. Weil aber nur die Experten auf ein und demselben Gebiet dieselbe Sprache sprechen, entstehen um sie herum unsichtbare Mauern, die mit der Sprachbarriere einhergehen.

Winzige Türen dazwischen erlauben die Übergabe der Arbeitsergebnisse. Was innerhalb der Mauern passiert, bleibt für die anderen unsichtbar. Wer seine Ergebnisse übergeben hat, ist die Verantwortung los und muss sich um das Gesamtergebnis nicht kümmern – das perfekte Wasserfallmodell.

„In Projekten, die nach diesem Modell organisiert sind, konzentrieren sich die einzelnen Teammitglieder oftmals fast ausschließlich auf den Erfolg ihrer jeweiligen Aufgabe, nicht auf den Erfolg des Ganzen.

Je umfangreicher und strategischer das Projekt, desto eher werden die fast zwangsläufig resultierenden Fehler oder Verzögerungen in Kauf genommen, um die übergeordneten Ziele und Zusagen gegenüber den Fachabteilungen doch noch zu erfüllen“

weiß James Roberts, CTO bei Basis Technologies, aus Erfahrung.

„Leider sehen wir diese Herangehensweise bei SAP-Bestandskunden immer wieder und immer noch recht häufig.“

Wo Silogrenzen Alltag sind, kommunizieren SAP-Entwickler und ihre Kollegen im IT-Betrieb nicht oder zumindest viel zu wenig miteinander. Erstere sind für Changes, Customizing etc. verantwortlich und übergeben die Ergebnisse ihrer Arbeit, ohne zu verstehen oder zu überprüfen, ob darin Probleme für ihre Kollegen in der Server-, Speicher- oder Netzwerkadministration, in der Qualitätssicherung oder beim Management der Testumgebung enthalten sind.

Läuft die Software nicht wie erwartet, werden die Entwickler nicht verantwortlich gemacht, während der IT-Betrieb alle Hände voll damit zu tun hat, Workarounds zu finden, um die Zahl und die Dauer der Unterbrechungen möglichst gering zu halten.

Die Entwickler wiederum werden immer wieder in ihrer Arbeit unterbrochen, wenn sie ihre Artefakte nicht unmittelbar testen können, sondern Tickets eröffnen und warten müssen, bis die passende Testumgebung technisch und zeitlich für sie bereitsteht. Beide Seiten sind nur ungenügend mit der Arbeit der Kollegen zufrieden. So droht aus Schweigen langsam Misstrauen zu werden.

In einer solchen Kultur und den entsprechenden Strukturen können die Erwartungen der Anwender im Cloud-Zeitalter nicht erfüllt werden. Die Unternehmen müssen einen Weg finden, von einer Kultur des Misstrauens zu einer Kultur des Vertrauens zu kommen.

Geeignete maschinelle Regressionstests, mittels derer sich die Qualitätssicherung nach dem Vorbild des Shift-Left-Testing in Richtung Entwicklung zurückverlagern lässt, könnten hier zu einem wesentlichen Teil Abhilfe schaffen.

Fehler zu beheben und kurzfristige Anforderungsänderungen einzuarbeiten, noch bevor ein neues Release in den Produktivbetrieb geht, ist gerade im SAP-Umfeld in der Regel um 20 bis 40 Mal billiger.

Vorbild Fertigung

Es mag vielleicht überraschen, aber die Idee einer besseren, weil verantwortungsvollen und vertrauensvollen Zusammenarbeit ist viel älter als die IT-Industrie. Sie wurde zuerst in der verarbeitenden Industrie angewandt, und zwar bereits vor rund achtzig Jahren. Denn offensichtlich sind die Probleme der Arbeitsteilung und des Spezialistentums so alt wie diese selbst – und kein Produkt neuer Technologien und Arbeitsweisen.

Als Antwort auf diese Probleme hat der Physiker und Statistiker Walter Shewhart den Regelkreis PDSA (Plan-Do-Study-Act) entwickelt, der von Shewharts Schüler William Edwards Deming zu einer Theorie ausgebaut wurde.

Das von dem Ingenieur und Doktor der mathematischen Physik entwickelte Managementprogramm fand jedoch zuerst nicht in den USA, sondern im Nachkriegs-Japan eifrige Anwender.

Das Toyota-Produktionssystem, welches das Unternehmen in wenigen Jahrzehnten zum weltweit größten Autobauer machte, steht beispielhaft für den Einfluss von Demings Ideen, die erst in den 1980er-­Jahren in den USA von einem breiteren Publikum und insbesondere den Managern wahrgenommen und teilweise auch umgesetzt wurden.

Konzepte wie Total Quality Management, bei dem die Qualität anders als bei Stichproben zu jeder Zeit und an jedem Punkt in der Prozesskette gemessen wird, oder die heute allseits bekannte und praktizierte Just-in-Time-Produktion stehen für diese veränderte Wahrnehmung.

Der Clou und das Revolutionäre an diesem Ansatz war, dass jeder für seinen eigenen Bereich nicht nur verantwortlich war, sondern auch die Qualität in jedem Schritt für alle und insbesondere das Management transparent gemacht wurde.

Das Prinzip dahinter: Fehler passieren. Aber wenn sie nicht aufgedeckt oder erst am Ende des Fertigungsprozesses festgestellt werden, ist es vielleicht zu spät, um noch korrigierend eingreifen zu können, oder aber sehr arbeitsintensiv und aufwändig, in zeitlicher wie in finanzieller Hinsicht. Außerdem fehlen die Messpunkte, die Auswertungen ermöglichen, um den Prozess kontinuierlich zu verbessern.

Continuous Everything

Die Methoden der kontinuierlichen Qualitätssicherung und Verbesserung sind längst Standard in der Fertigungsindustrie. Dessen Basis bilden Verantwortung, Transparenz, kurze Zyklen und Teamorientierung, die dank DevOps auf ganz ähnliche Art und Weise auf die Welt der IT übertragen werden.

Continuous Integration, Continuous Testing, Continuous Delivery und Continuous Improvement sind alles Elemente eines erfolgreichen DevOps-Ansatzes. Dieser verfolgt das Ziel, jegliche Änderung ohne Risiko und idealerweise ohne menschliches Zutun bereitzustellen, sobald sie verfügbar ist.

Arbeitsweisen und Rollen müssen entsprechend angepasst werden, um die Ergebnisse, die mit DevOps möglich sind, auch tatsächlich zu erzielen – wie es in der Fertigung bereits geschehen ist.

Silogrenzen müssen niedergerissen, klar abgegrenzte Aufgabenbereiche durch das Arbeiten in multidisziplinären Teams ersetzt werden. Mit nur einem Ziel vor Augen: verbesserte Zusammenarbeit. Sie ist der Schlüssel dazu, die definierten geschäftlichen Ziele mittels DevOps zu erreichen.

Die Kultur ist, wie bereits erwähnt, in der Tat ein wesentlicher Teil des Dev­Ops-Konzepts und betrifft insbesondere die Bestandteile C, M und S im CALMS-Ansatz. Verpassen Sie nicht den zweiten Teil des Artikels in der kommenden Ausgabe, welcher sich mit den Auswirkungen von Automatisierung (A) und Lean Management (L) auf Arbeitsstrukturen und -prozesse beschäftigt. Ebenso erfahren Sie mehr zur Rolle, die diverse Tools dabei spielen, DevOps auch in komplexen SAP-Landschaften zum einfachen Standard werden zu lassen.