Geringere Kosten, weniger Fehler, schnellere Lieferung neuer Software. Unternehmen, die ihre Organisation bereits auf die Fusion der Entwicklung mit dem IT-Betrieb eingeschworen haben und dieses Prinzip "leben", haben klare Vorteile gegenüber Wettbewerbern, die noch nicht auf DevOp" setzen. Sie sparen tausende Personentage bei der Produktionssetzung integrativer Themen und bei Testingaufwänden und-Kosten. Kein Wunder, dass das Thema momentan extrem wichtig ist.

Das "Blame Game" beenden

Agile Methoden haben bereits gezeigt, dass funktionierende Software über implementierbare Inkremente schneller entstehen kann als zuvor. Einen Schritt weiter geht man bei DevOps, denn nun wird Software im Schulterschluss mit dem IT-Betrieb produziert, der dafür zuständig ist, die neue Software in der Live-Umgebung ans Laufen zu bringen.

Jeder kennt das Blame Game aus der Vergangenheit, in dem sich Entwickler und Mitarbeiter aus dem IT-Betrieb gegenseitig bezichtigten, daran Schuld zu sein, dass neue Software in der Produktion Probleme machte. Quasi über den Zaun geschmissen wurde vermeintlich fertig programmierter Code, der sich ein ums andere Mal als Risiko darstellt. Die Folge: instabile Plattformen, negative Auswirkungen auf das Business und unzufriedene Endkunden.
Um das Risiko möglichst gering zu halten, wurden Anforderungen künstlich aufsummiert, gesammelt getestet und nur ein paar Mal im Jahr in die Produktion aufgespielt. Die Einführung neuer Softwarebausteine verzögerte sich und die Komplexität der Systeme stieg, gleichzeitig erhöhte sich das Risiko - ein Teufelskreis. Der Release-Zyklus eines Elektronikhändlers wurde dadurch derart lang, dass ihm die Konkurrenz wie zum Beispiel Onlinehändler zuvor kam und seine Innovationskraft schneller unter Beweis stellte. Dabei ist heute klar: Jede neue Business-Anforderung kann ein neues Release bedeuten.

DevOps verlangen neue interne Arbeitsweisen

Kommunikation und Kollaboration fördern, eine Mannschaft aufbauen, gemeinsame Ziele für interdisziplinäre Teams definieren und kommunizieren ist ein nicht zu unterschätzender Erfolgsfaktor, für die nachhaltige Organisationstransformation in Richtung DevOps. Eine klare DevOps-Vision - unterstützt vom Top Management - begleitet von einer zielgruppengerechten Kommunikations- und Trainingsstrategie - ist entscheidend.
Der Paradigmenwechsel bezüglich zukünftiger Aufgabenbereiche innerhalb eines Teams sowie das Zusammenarbeitsmodell zwischen Teams müssen mit den Mitarbeitern im Coaching-Ansatz erarbeitet werden. Der Weg zur Erreichung der Vision ist individuell - der "One-size-fits-all"-Ansatz für alle Teams und Abteilungen oder gar ein Ausklammern der Aufgabenstellung stellt ein Risiko für DevOps dar. Zu guter Letzt unterliegt auch das Change Manangement dem Continuous Improvement-Gedanken und muss regelmäßig überprüft und gegebenenfalls angepasst werden.

Neben der neuen Arbeitsweise gehört ein hoher Grad an Automatisierung zum Erfolgsrezept von DevOps. Anders als noch vor zehn Jahren gibt es heute unzählige Tools auf dem Markt, die Automatisierungen in der Softwareproduktion unterstützen. Ob als Beschreibung der Infrastrukturlandschaft in Form von Code - sogenannte "Infrastructure-as-a-Code", um die Plattform schnell und reproduzierbar verfügbar zu machen oder zur Bereitstellung und von Software-Versionen. Unterstützt von Virtualisierungstechnologien und Cloud-Ansätzen dauert der Aufbau einer Maschine nur noch Minuten und schon kann das Testen beginnen. Auch die Möglichkeit Umgebungsfehler automatisch zu erkennen und zu beheben - das sogenannte Self-Healings - trägt zur Steigerung der Stabilität von Produktions-Umgebungen und Endkundenzufriedenheit bei.

Nach eigenen Erfahrungen sinken bei Unternehmen die Kosten in der Softwareproduktion um zehn bis zwanzig Prozent, die Lösungen sind doppelt so schnell ausgeliefert und die Fehlerquote sinkt um 30 Prozent. Womit hängt das zusammen?

• Kosten sinken
  Ein Mitarbeiter ist über die Virtualisierung in der Lage ohne langen Vorlauf diverse Maschinen per Knopfdruck parallel bereitzustellen. Er kann zudem wiederkehrende Standard-Aufgaben automatisiert ablaufen lassen. Wenn etwa ein Stammdatensystem ein Backup importierter Daten auf ein Laufwerk ablegt, ist es nicht nötig, dass ein Mitarbeiter täglich ins System schaut, um sicherzustellen, dass das Verzeichnis nicht überläuft und gegebenenfalls das Produktivsystem lahmlegt. Das übernimmt in Zukunft die Maschine. Skripte, also kurze Anweisungen über Code, die den Self-Healing-Prozess anstoßen. Durch die allgemeine Verbreitung dieser Automatisierungstechnologien sind inzwischen solche Skripte schon verbreitet und via Copy-Paste zu implementieren. Automatisierte Prozesse schaffen für den Mitarbeiter Raum für wichtigere Aufgaben.

• Time to Market
  Einerseits die täglichen Abstimmungen in den Projektmannschaften und andererseits die Automatisierungen schaffen die Möglichkeit, den Softwareentwicklungsprozess zu beschleunigen und – neben schneller Bereitstellung neuer Anforderungen - eine kontinuierliche Verbesserung von Software ohne ein großes Risiko für das Live-System zu ermöglichen. Letzteres lässt sich anhand der Fehlersuche verdeutlichen.

• Fehlerquote reduzieren
  Schon während des Entwicklungsprozesses werden sowohl neue als auch existierende technisch wie fachlich Funktionalitäten getestet, die später im Live-System dem Endkunden zur Verfügung stehen werden. Testautomatisierungen stellen unter anderem die Reproduzierbarkeit des Qualitätssicherungprozesses (Quality Assurance, QA) dar – jedoch decken diese nicht immer alle Komponenten des Endsystems ab.
  Mit der Einrichtung entsprechender kontinuierliche Pipelines, mit denen jede Code-Änderung zunächst auf seine Funktionsfähigkeit hin untersucht, anschließend die Software auf einer „frischen Maschine“ bereitgestellt und getestet wird, ermöglicht die frühzeitige Erkennung und Behebung von Fehlern.
  Der technischen Validierung folgt die fachliche Prüfung. Hier liegt das Hauptaugenmerk darauf, ob die Geschäftsprozesse durchgängig (End-to-End) funktionieren. Ein Beispiel hierfür ist ob eine abgesetzte Online-Bestellung richtig verarbeitet, an die angeschlossene Systeme weitergegeben und ausgeliefert wird. Der QA-Prozess nimmt so nur noch wenige Stunden oder Tage und nicht mehr Wochen oder Monate in Anspruch. Die große Regression, bei der noch händisch die Geschäftsprozesse getestet wurden, ist diesem Prozess gegenüber reine Glückssache.

Die Studie 2015 State of the DevOps Reports hat gezeigt, dass die Initiativen zumeist aus dem Betrieb kommen, dann folgen die Entwickler. Ein wichtiger Impulsgeber fehlt jedoch aktuell noch, der in der Studie als dritter Treiber genannt ist: der Fachexperte. Schon heute zeigt sich: Die Softwareentwicklung ist entschieden besser geworden, doch gibt es noch Unstimmigkeiten mit den Zielen der Geschäftsbereiche. Anforderungen vom Fachbereich ließen sich etwa direkt in die Pipelines einsteuern, um auch hier die Kollaboration und Kommunikation zwischen Fachbereich, Entwicklung und Betrieb zu fördern. Es ist nur eine Frage der Zeit, bis aus DevOps letztlich auch der Change in Richtung BizDevOps angegangen werden muss. (bw)