© Stmool/Shutterstock.com
Kolumne: Stropek as a Service

Ready for DevOps? DevOps ist mehr als Technik, es ist ein Organisationsprinzip


Keine IT-Konferenz kommt ohne das Schlagwort „DevOps“ aus. Man hört von Continuous Integration and Deployment, Automatisierung, Infrastructure as Code, Telemetrie und vielen anderen Tools und Technologien. DevOps auf technische Fragen zu reduzieren, ist aber ein folgenschwerer Fehler. Melvin Conway hat es schon 1967 in dem nach ihm benannten „Conway’s Law“ auf den Punkt gebracht: „Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations“ [1]. Wenn wir also eine neue Vorgehensweise wie DevOps in der Softwareentwicklung erfolgreich einführen wollen, müssen wir parallel dazu die Kommunikations- und Organisationsstrukturen überdenken, die es in unserem Unternehmen gibt. Ansonsten erreichen wir das Gegenteil dessen, was wir anstreben: Mehr Koordinationsaufwand, weniger Innovation und instabilere Systeme. In dieser Kolumne möchte ich mich dem Thema widmen, welche organisatorischen Maßnahmen DevOps begleiten müssen, insbesondere im Bereich Cloud-basierter SaaS-Systeme.

Was ist DevOps?

Wie der Name schon sagt, bedeutet DevOps, dass Development und Operations näher zusammenrücken. Konkret heißt das, dass von jedem agil arbeitenden Entwicklungsteam beide Aufgabenbereiche abgedeckt werden müssen. Es geht nicht mehr nur darum, Software zu entwickeln, dicke Betriebshandbücher zu schreiben und alles den Administratoren zum Betrieb über den Zaun zu werfen. Bei DevOps arbeiten die Teams nach dem Prinzip „You build it, you run it.“ Sie tragen nicht nur die Verantwortung für die Software, sondern auch für nennenswerte Teile von deren Betrieb.

Schluss mit Abteilungsdenken

Wenn ich in Workshops das Grundkonzept von DevOps bei größeren Firmen präsentiere, ernte ich in der Regel Zustimmung. Teamgeist, Übernahme von Verantwortung für die eigene Arbeit, eigenverantwortliches Arbeiten, kürzere Kommunikationswege – das alles sind erstrebenswerte Ziele. Wenn es dann aber um die praktische Umsetzung geht, wird es schwierig. Plötzlich werden etablierte Organisationen infrage gestellt. Hier einige Beispiele, die regelmäßig Konfliktpotenzial haben:

  • Die Administrationsabteilung drastisch verkleinern und die betroffenen Personen in die Entwicklungsteams integrieren? Das geht doch nicht, die Mentalität ist viel zu unterschiedlich.

  • Den Entwicklungsteams erlauben, eigenständig betriebsrelevante Entscheidungen zu treffen und diese auch umzusetzen? Das führt sicher zu Chaos, schließlich haben die Entwickler keine Ahnung davon, was es heißt, ein Produktionssystem am Leben zu halten.

  • Zugriff auf Produktiv...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang