Thought Leadership
Agilität und Kundenorientierung weiter gedacht führen zu DevOps. Die neue Methodik erfordert ein Umdenken, erhöht aber richtig eingesetzt die Produktivität und Kundenzufriedenheit.
Agile Software-Entwicklungsmethoden wie Scrum und Kanban gehören heute zum Industriestandard. Nach anfänglicher Skepsis haben sie sich auf breiter Front durchgesetzt, weil sie schnellere Release-Zyklen ganz nahe an den Anforderungen des Kunden ermöglichen. Dadurch steigt die Qualität der Software-Services und damit die Zufriedenheit der Kunden. Der nächste logische Schritt heißt DevOps, ein Kunstwort aus Development und IT Operations. Auch hier überzeugen die Vorteile, die die Methodik bietet. Nur wenn die beiden ehemaligen “Silos”, die Software-Entwicklerteams und IT Operations, eng zusammenarbeiten, werden sie für ihre Kunden die bestmögliche Lösung entwickeln. DevOps-Teams sind im Durchschnitt 1,4 Mal innovativer als getrennt voneinander arbeitende Geschäftseinheiten. Auch Integrations- und Akzeptanztests, die in rund der Hälfte der Unternehmen zu Verzögerungen und damit zu einer drohenden verspäteten Auslieferung führen, lassen sich mit DevOps besser meistern. Insbesondere Integrationstests sind essenziell für eine vollständige Automatisierung des Deployment-Prozesses.
Bild: DevOps überwindet die Silo-Grenzen zwischen Development und IT Operations. Die neue Methodik schafft cross-funktionale Teams, die die Wünsche des Kunden schneller und besser erfüllen.
Cloud-Services mit extrem kurzen Release-Zyklen, Container und der Aufstieg von Managed Kubernetes zum Beispiel bei den Public-Cloud-Anbietern Amazon, Microsoft und Google zwingen Unternehmen dazu, alte Muster aufzubrechen und Teams zu bilden, die alle benötigten Rollen und Fähigkeiten abdecken und so die neue Realität besser abbilden. Der Betrieb der Software als Service gehört heute, zusammen mit Development und Deployment, direkt zur Wertschöpfungskette und bestimmt maßgeblich über den Markterfolg der Lösung. Denn eine Anwendung beziehungsweise ein Web-Service haben schließlich nur Wert, wenn sie performant und problemlos im produktiven Einsatz laufen.
Cross-funktionale Teams bilden
In der alten Welt konzentrierte sich die Software-Entwicklung auf die Anwendung, innovative, neue Features und eine kurze Time-to-Market. Ihr Job war nach der Ablieferung des neuen Releases erledigt. Der Fokus der Administratoren lag danach auf der Infrastruktur, auf 24/7-Verfügbarkeit, hoher Performance, kurzen Latenzzeiten und Stabilität. Die «Wall of Confusion», das heißt der Verantwortungsübergang zwischen beiden Geschäftseinheiten wird in der neuen Welt mit Herausforderungen wie Continuous Delivery und Continuous Integration aber zunehmend obsolet, ja hinderlich. Starres Silodenken würde dazu führen, dass eine Geschäftseinheit die Versäumnisse der anderen zeit- und kostenintensiv ausbügeln muss. Je später das Feedback, desto größer die Schleife und desto teurer die Korrektur und Anpassung.
Veränderungen für Devs und Ops
DevOps ist jedoch kein Selbstläufer und verlangt Development und IT Operations einiges ab. Software-Entwickler werden sich stärker mit der Konfiguration von CI/CD-Pipelines und Containern, mit Fragen der IT-Sicherheit (DevSec) und mit der Auslieferung neuer Releases beschäftigen müssen. Neu für das DevOps-Team werden Infrastructure as Code, der Umgang mit der Versionsverwaltung und automatisierte Tests sein. Der IT-Dienstleister ConSol empfiehlt ein methodisches Vorgehen nach bewährten Best Practices.
Wie bei jedem Projekt startet man auch bei einem DevOps-Projekt mit einer klaren Bestandsaufnahme der Ist-Situation. Daran schließt sich die Auswahl der Projektwerkzeuge und des initialen DevOps-Technologie-Stack an. Standardisierte Projektwerkzeuge reduzieren Komplexität und erleichtern die Zusammenarbeit zwischen Entwicklung und Administration.
Danach wird über die Zusammensetzung des DevOps-Kernteams entschieden. Verfügen alle Mitglieder des Teams über die Qualifikation, die sie zur Erfüllung ihrer Aufgabe benötigen? Sind Schulungen zum Aufbau der erforderlichen Skillsets sinnvoll? Dieser Aspekt wird bei der Einführung von DevOps gerne vernachlässigt.
