DevOps ist keine Organisation

Kollaboration zwischen Entwicklung und Betrieb wird immer wichtiger. Beim Weg in die Produktion kann die Softwareentwicklung weiter optimiert werden. Erst Software, die in Produktion ist und von echten Nutzern verwendet wird, stellt tatsächlich einen Geschäftswert dar. Dazu muss nicht nur die Softwareentwicklung sondern auch das Deployment schneller sein. Genau das ist das Ziel von Continuous Delivery und einer Deployment Pipeline.

Der Aufbau einer Deployment Pipeline erfordert mehr als nur Wissen über Softwareentwicklung. Das Provisionieren von Servern ist ein Betriebsthema. Die vielen Tests in der Pipeline sind ein Bereich, den die QA besonders gut abdeckt. Der Aufbau einer solchen Pipeline erfordert Skills aus allen diesen Bereichen und daher eine enge Kollaboration. Kein Bereich kann die Pipeline im Alleingang umsetzen.

Auch aus der Sicht der Agilität sind cross-funktionale Teams sinnvoll, die möglichst viele unterschiedliche Fähigkeiten umfassen. Wenn in einem Team viele Experten mit verschiedenen Schwerpunkten zusammenarbeiten, dann kann es viel mehr unterschiedliche Probleme lösen.

Aber die Trennung zwischen Betrieb, Entwicklung und Test ist in der Hierarchie ziemlich weit oben angesiedelt. Oft arbeiten direkt unter dem CIO oder dem IT-Leiter der Leiter des Betriebs und der Leiter der Softwareentwicklung. Diese Trennung geht in den anderen Hierarchiestufen weiter. Die Organisation so zu ändern, dass Betriebler und Entwickler in einem Team gemeinsame Vorgesetzte haben, ist schwierig. Dazu wäre ein grundlegender Umbau der Organisation notwendig. Der ist oft nicht durchsetzbar.

DevOps bedeutet Kollaboration

Aber ist eine solche Reorganisation überhaupt notwendig? Meiner Meinung nach nicht. Es geht um Kollaboration: Wenn der Betrieb, QA und die Entwicklung eng zusammenarbeiten, denn ist DevOps kein
Problem. Ich habe Projekte erlebt, in denen trotz einer getrennten Betriebsabteilung und einer getrennten QA-Abteilung Änderungen in einer halben Stunde in Produktion sind.

Gegenbeispiele sind Betriebsabteilungen, die auch die Entwicklung kontrollieren wollen – beispielsweise durch das Etablieren von Standard-Frameworks. Oder das Vorgehen der Entwicklung in Frage stellen, statt sie in den Projekten zu unterstützen.

Aber selbst wenn Betrieb und Entwicklung kooperieren, kann es zu Reibungsverlusten kommen. In einem Projekt haben beispielsweise Betrieb und Entwicklung eigene Deployment-Lösungen entwickelt – sogar mit denselben Werkzeugen. Das führt nicht nur zu doppelten Aufwänden, sondern auch zu Unterschieden, die zu Fehlern führen können oder die Fehlersuche erschweren. Selbst identische Werkzeuge und der Wille zur Zusammenarbeit lösen also nicht alle Problemen.

Gegen das Zusammenlegen von Betrieb und Entwicklung spricht auch, dass der Betrieb nur zur Unterstützung von Individualsoftware im DevOps-Kontext relevant ist. E-Mail-Server oder Office-Infrastruktur sind ein anderes Thema und können auf jeden Fall in einer getrennten Betriebseinheit verbleiben.

Fazit

DevOps ist also keine Organisationsform, sondern steht für Kollaboration. Wenn die Abteilungen gut zusammenarbeiten, ist eine Änderung der Organisation nicht notwendig. Wenn es bei der Zusammenarbeit zu Schwierigkeiten kommt, stellt sich die Fragen, ob wirklich eine Änderung eines Organigramm die Lösung ist. Vermutlich werden Menschen nicht besser zusammenarbeiten, nur weil sie plötzlich in einem Team sind... ()