Foto: laksena - shutterstock.com
Kein Zweifel: DevOps hat vielen IT-Organisationen dabei geholfen, Anwendungen und Services schneller zu entwickeln und bereitzustellen. Allerdings kommt es nicht selten vor, dass IT-Führungskräfte in den höchsten Tönen von DevOps schwärmen, während sich ihre Teams in eine völlig falsche Richtung bewegen und auf unausgegorene oder völlig unzureichende Tools oder Praktiken setzen.
Sicherzustellen, dass die Entwicklungsteams nicht (absichtlich oder unabsichtlich) vom Pfad der DevOps-Tugend abkommen, liegt in der Verantwortung des CIO. Die folgenden sieben Warnzeichen können darauf hindeuten, dass Ihre DevOps-Initiative nicht mehr als Schall und Rauch ist.
1. DevOps im Silo
Das erste Anzeichen für eine Fake-DevOps-Implementierung lässt sich mit einem Blick aufs Organigramm erkennen, weiß Fernando Cuadra, Principal Consultant beim Beratungsunternehmen ISG: "Wenn DevOps in einem eigenen Silo untergebracht ist, getrennt von Technik und Betrieb, ist das ein erstes Anzeichen dafür, dass keine Verantwortlichkeit für diesen Bereich gegeben ist. CIOs, die ein separates DevOps-Team schaffen, erzeugen eine weitere Komplexitätsebene, die es zu managen gilt."
Stattdessen sollte das Organigramm so designt sein, das die Teams in der Lage sind, Probleme ganzheitlich über alle relevanten Bereiche hinweg zu lösen. "Entscheiden Sie sich für den Aufbau funktionsübergreifender Teams, vom Design bis hin zum Betrieb", rät Cuadra. "Bei DevOps geht es nicht um Pipelines und CI/CD, sondern darum, die Wertschöpfung mit minimalen Reibungsverlusten im gesamten Unternehmen selbst zu steuern."
2. Tool- statt Menschenfokus
Unternehmen, die sich zu sehr auf die Tool- und technologieorientierte Seite der DevOps-Kultur konzentrieren und Menschen und Prozesse außen vor lassen, können aus dem Gleichgewicht geraten. "Es ist wichtig, die aktuellen Business-Praktiken und -Bedürfnisse zu bewerten", meint Mohan Kumar, Senior Architect bei TEKsystems. Er empfiehlt: "Verankern Sie die DevOps-Kultur in Kommunikation, Zusammenarbeit, Feedbackerfassung und Datenanalysen."
Eine experimentierfreudige Umgebung, die es Entwicklern erlaube, zu scheitern und zu lernen, schaffe eine von Schuldzuweisungen innerhalb des Unternehmens befreite Kultur, so der Experte. "Nutzen Sie die kollektive Intelligenz der Teams, um einen Strom kreativer Ideen zu fördern", fügt er hinzu. Die Einführung von DevOps sei ein iterativer Prozess, weshalb der CIO zunächst den aktuellen Zustand des Entwicklungsteams bewertet und dann schrittweise eine Strategie der kontinuierlichen Verbesserung aufbaut, die Menschen, Prozesse und Tools einbezieht. "Letztlich ist Kreativität ein Muskel, der ständig trainiert werden muss, um sich weiterzuentwickeln", so Kumar.
3. Zu wenig Automatisierung
Auch Teamleiter, die Automatisierungsmentalität vermissen lassen, können zu DevOps-Schwindel beitragen. dies gilt insbesondere für solche, die daran scheitern, Zeit und Ressourcen in den Aufbau einer starken Architektur mit automatisierter Code Delivery zu stecken.
Bevor Sie eine Automatisierungsinitiative in Angriff nehmen, sollten Sie daher den Entwicklungsbedarf, die bestehenden Verträge und die aktuellen Projektteams sorgfältig begutachten, wie Ian Fogarty, Managing Director of Technology and Operations beim Beratungsunternehmen Accenture Federal Services, empfiehlt: "Prüfen Sie, ob die Fähigkeiten der Organisation so weit entwickelt sind, dass Sie die Infrastruktur automatisieren können."
Wie Kumar anmerkt, kann Automatisierung jedoch ein zweischneidiges Schwert sein. Es sei allzu leicht, unbeabsichtigt von fehlerhaften manuellen zu fehlerhaften automatisierten Prozessen überzugehen. "Widerstehen Sie dem Drang, so viel wie möglich zu automatisieren, und beschränken Sie Ihre Initiative auf sinnvolle Punkte. Das ultimative Ziel sollte sein, Software-Releases in einen wiederholbaren, zuverlässigen und automatisierten Bereitstellungsprozess zu verwandeln."
4. Planlose Automatisierung
Automatisierung kann wie eben gelesen von großem Nutzen sein. Allerdings stürzen sich immer noch viele Unternehmen ohne ausreichende Analyse und Planung in die DevOps-Automatisierung.
Aaron Oh, Managing Director DevSecOps bei Deloitte Risk & Financial Advisory, plaudert aus dem Nähkästchen: "Wir haben Unternehmen erlebt, die der Automatisierung Priorität einräumen, ohne andere Aspekte wie Governance, Mitarbeiter, Prozesse und Technologie zu berücksichtigen. Solche Unternehmen verschwenden in der Regel viel Zeit mit der Überprüfung und Korrektur von Automatisierungsaufgaben."
Statt sich direkt in die Automatisierung zu stürzen, empfiehlt Oh die Einführung einer starken Governance und die Standardisierung von Anforderungen und Prozessen: "Die Zusammenarbeit zwischen den einzelnen Geschäftsbereichen ist ein wesentlicher Bestandteil von DevOps. Dabei sollten eventuell vorhandene organisatorische Hindernisse beseitigt werden - es ist wichtig, dass die Führungsebene hier den Ton angibt. Außerdem sollten intelligente Orchestrierungs-Tools zum Einsatz kommen, um Silos zu beseitigen und eine effiziente Kommunikation zu ermöglichen."
5. Unrealistische Erwartungen
Führungskräfte im Technologiebereich sollten sich auf ein Engagement konzentrieren, das über die bloße Einführung neuer technologischer Tools und Verfahren hinausgeht. "Sie müssen der Veränderung der Unternehmenskultur und der Denkweise der Mitarbeiter Vorrang einräumen", appelliert Tim Potter, Principal bei Deloitte Consulting, und ergänzt: "Sie müssen außerdem auch realistische Fristen setzen, damit die Transformation im Unternehmen Fuß fassen kann. Ein Unternehmen, das einfach nur mehr automatisierte Tools einsetzt und bestehende Anwendungsteams, die sich von Anfang bis Ende um Produktionsprobleme kümmern, 'DevOps-Teams' nennt - wird von den erzielten Ergebnissen sehr wahrscheinlich enttäuscht sein."
Zudem sollten sich IT- und Tech-Entscheider laut dem Deloitte-Mann darauf einstellen, dass sich die Performance nach der Umstellung auf DevOps zunächst verschlechtert, bevor sie sich verbessert: "Sie müssen darauf vorbereitet sein, ihre Anwendungsteams zu unterstützen, damit sie testen und lernen und sich mit dem neuen Modell vertraut machen können. Unangemessene Erwartungen und ein unzureichender Zeitrahmen für die Umstellung können zu Fake-DevOps-Initiativen führen."
6. Teams, die in der Vergangenheit leben
Alte Gewohnheiten lassen sich bekanntlich nur schwer ablegen. Jahrzehntelang folgte die Softwareentwicklung der traditionellen Wasserfallmethodik, einem Prozess, bei dem es darum ging, Anforderungen im Voraus zu sammeln, Funktionen zu entwickeln und die Ergebnisse schließlich zur Freigabe an die Qualitätssicherung und andere Teams zu übergeben. Das hatte Folgen, wie auch Ashish Kakran, Principal bei der IT-Risikokapitalgesellschaft Thomvest Ventures, weiß: "Früher hat es Monate gedauert, bis die Kunden neue Funktionen zu sehen bekamen."
Wenn es den Entwicklungsteams nicht gelinge, sich vollständig vom Wasserfallmodell zu lösen, könne es zu seltsamen Kombinationen von Prozessen kommen, warnt Kakran und schlägt vor, die DevOps "Epics" und "Stories" eines Teams zu analysieren, um sich ein Bild von dessen Status zu machen: "Der gesamte Kontext eines laufenden Projekts wird oft in diesen Aufgaben erfasst. Wenn bereits ein einmonatiges Projekt in Aufgaben mit wenig oder gar keinem kontinuierlichen Kunden-Feedback aufgeteilt ist, ist das ein Zeichen dafür, dass das Team sich selbst zum Scheitern verurteilt - sei es durch das versäumte Deadlines oder die Bereitstellung von User Experiences, die den Namen nicht verdienen."
7. Flexibilitätsmängel
DevOps ist keine One-Size-fits-All-Methodologie. Um maximale Effektivität zu erzielen, sollten DevOps-Workflows und -Tools auf die spezifischen Anforderungen des Unternehmens abgestimmt werden. Diese können je nach Größe, Anwendungstyp und Entwicklungskompetenz sehr unterschiedlich ausfallen.
Dabei sollte DevOps niemals statisch sein: Die Prozesse und Tools müssen angepasst werden, wenn das Unternehmen wächst und sein Streben nach kontinuierlicher Verbesserung verfolgt. Das erfordert nach Meinung von Wing To, Vice President of Engineering bei Digital.ai, flexible Tools und die Fähigkeit, KPIs zu analysieren. Er ergänzt: "IT-Führungskräfte sollten auch den Kulturwandel berücksichtigen, der erforderlich ist, um Entwicklungs- und Betriebsteams zusammenzubringen. Anstatt eine separate DevOps-Abteilung einzurichten, die ein weiteres Silo und noch mehr Prozessengpässe schafft, sollte die Methodik in jeden Geschäftsbereich integriert werden." (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.