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."