Schriftliche DevOps-Schulung

Wie bauen Sie Ihre DevOps-Organisation auf und entwerfen Ihre Softwarearchitektur?

Nach Conways Gesetz spiegeln die Systeme, die eine Organisation entwirft, zwangsläufig ihre Kommunikationsstrukturen wider. Mit anderen Worten: Ihre Software kann nur so gut sein wie die Kommunikation und Zusammenarbeit Ihrer Teams. Wie Sie Ihre Teams aufstellen, wirkt sich daher auf die Softwarearchitektur, die IT-Leistung und schließlich auf das Geschäftsergebnis aus.

Ihre Organisationsstruktur bestimmt, welche Software entsteht

Die meisten Unternehmen, vermutlich auch Ihres, unterteilen die Softwarebereitstellung in mehrere Teams und erhalten am Ende eine Architektur mit genau derselben Anzahl an Schichten. Kontrollierte Versuche haben gezeigt, dass eine Organisation mit 6 Teams eine Architektur mit 6 Schichten entwickelte. Eine andere Organisation mit 3 Teams erhielt dieselbe Aufgabe und entwickelte eine Architektur mit 3 Schichten. Es gibt viele ähnliche Beispiele.

Ein namhafter Versicherer mit weltweit 86.000 Beschäftigten hatte in einer IT-Einheit zufällig 2 große Funktionsteams. Die Einheit lieferte das Backend für Kunden, Verträge, Rechnungen und Dienstleistungen. Ein Team arbeitete mit Java, das andere mit gespeicherten Prozeduren in PL/SQL. Zudem waren beide von zentralen Servicestellen für IT-Betrieb, Datenbankverwaltung, Infrastruktur, Netzwerke, Sicherheit und Qualitätssicherung abhängig. Das erschwerte die sichere Bereitstellung ihrer Software zusätzlich.

Obwohl die Teams getrennt waren, gelang es ihnen nicht, die geschäftliche Orchestrierungslogik in Java sauber von der Datenzugriffslogik in PL/SQL zu trennen. Sie lieferten Hunderte Funktionen, die jeweils aus verschachteltem Java- und PL/SQL-Code bestanden. Jede Änderung und jede neue Anforderung führte so zu Dutzenden Übergaben zwischen den Teams. Schon kleine Änderungen verursachten lange Warteschlangen und Durchlaufzeiten. Da selbst ihre Auswirkungen in dieser komplexen Umgebung schwer vorhersehbar waren, beschädigten die Teams regelmäßig bestehende Produktionsfunktionen. Es kam zu Ausfällen, deren Behebung wiederum Zeit, Nacharbeit, Eskalationen und Stress verursachte.

Um diese Arbeitsweise zu ändern, schlossen sich die beiden Funktionsteams zu einem Produktteam zusammen. Sie gestalteten die Software schrittweise um und machten die Datenzugriffsschicht zu einer Reihe von API-Funktionen. Zudem entwickelten sie ein neues Geschäftssystem, das vollständig von der internen Funktionsweise der Datenzugriffs-API entkoppelt war. Schon früh besserte sich die Stimmung: Java- und PL/SQL-Fachleute arbeiteten nun für den Erfolg des gemeinsamen Produkts. Mit der lose gekoppelten Architektur sind die Folgen von Änderungen leichter erkennbar, Änderungen schneller und einfacher umsetzbar und Fehler leichter zu finden und zu beheben. Die durchschnittliche Durchlaufzeit neuer Funktionen sank von 4 Monaten auf 3 Wochen. Die Warteschlange für Vorfälle ist inzwischen fast leer. Die freie Kapazität nutzt das Team für weitere Reviews, Refactoring und Verbesserungen seiner Codebasis.

Matrixorganisationen, Funktionsteams und die Illusion der Kostenoptimierung

Ihre Unternehmen sind in Funktionsteams für Fachgebiete wie Datenbanken, Netzwerke, Betrieb, Informationssicherheit, Qualitätssicherung, Release-, Projekt- und Produktmanagement aufgeteilt. Projektteams setzen sich aus Personen aus verschiedenen Fachsilos zusammen. In solchen Projektmatrixorganisationen, die Produkte und Dienstleistungen bereitstellen, ist das Projektmanagement meist dafür verantwortlich, dass etwas geliefert wird. Das Produktmanagement sorgt dafür, dass das Richtige geliefert wird.

In dieser Organisationsform verstehen Funktionsteams wenig oder gar nichts vom Gesamtumfang der Arbeit, zu der sie beitragen. In extremen, aber häufigen Fällen interessieren sie sich weder für das Gesamtbild noch für die IT- und Geschäftsleistung des Produkts oder Dienstes. Sie konzentrieren sich darauf, sich abzusichern, falls Projekte scheitern und sich alle gegenseitig die Schuld geben.

Funktionsteams bearbeiten meist lange Warteschlangen von Tickets. Es dauert daher oft lange, bis sie Ihr Projekt unterstützen können. Weil Projekte um dieselben Fachkräfte konkurrieren, ist eine Eskalation oft der einzige Weg, schnell Aufmerksamkeit zu bekommen. Ständige Eskalationen belasten das Arbeitsklima und das Vertrauen zwischen den Teams.

Wiederholte Übergaben, Verzögerungen, Qualitätsprobleme, Nacharbeit, Engpässe und Stress prägen Ihren Alltag. Solange sich Ihre Matrixorganisation an einer undurchsichtigen und trügerischen Vorstellung von Kostenoptimierung orientiert, ist sie kaum zu besseren Ergebnissen in der Lage. Durch Qualitätsprobleme, Nacharbeit und Verzögerungen sind funktionale Organisationen wahrscheinlich teurer als jede beliebige andere Organisationsform. Wenn Ihre Organisation wichtige Funktionen wie Qualitätssicherung und IT-Betrieb bereits an weit entfernte Standorte ausgelagert hat, kann Ihre IT womöglich nur noch mit Mühe zuverlässig liefern und Anforderungen erfüllen, die für die Aufrechterhaltung des Geschäfts entscheidend sind.

Wie löst DevOps dieses große Problem? Mit produkt- und serviceorientierten Teams

DevOps empfiehlt, die vermeintliche Kostenoptimierung von Funktionsteams durch eine nachweislich wirksame Optimierung der Geschwindigkeit zu ersetzen. Richtig umgesetzt spart DevOps zudem Kosten, während Sie und Ihr Team schnell und kontinuierlich liefern.

DevOps empfiehlt produkt- und serviceorientierte Teams. Sie sind unabhängig, funktionsübergreifend, autonom, eigenständig arbeitsfähig und meist klein. Sie decken alle Phasen des Softwarelebenszyklus für ein Produkt oder einen Dienst ab, von Architektur, Entwurf und Programmierung über Tests und Experimente bis hin zu Deployment, Betrieb und Wartung. Ihre Verantwortung gilt einem Produkt oder Dienst und reicht über ein vorübergehendes Projekt hinaus. Sie haben richtig gelesen. Wer kann Software besser betreiben und warten als diejenigen, die sie gebaut haben? Niemand. Deshalb geben die erfolgreichsten DevOps-Teams bei Amazon und Netflix ihre Produkte und Dienste nach dem Release nicht ab. Sie betreiben und warten ihre Software auch in ihren eigenen Produktionssystemen.

Ihre Organisation finanziert Produkte und Dienstleistungen langfristig

Um die Geschäftsleistung zu steigern, finanziert Ihre Organisation keine befristeten Projekte mehr, deren konkrete Ergebnisse langfristig schwer zu beurteilen sind. Mit DevOps finanziert sie ihren eigenen Auftrag, Zweck und die damit verbundenen Produkte und Dienstleistungen. Der Erfolg Ihrer Teams wird nun anhand der IT- und Geschäftsleistung sowie der Kapitalrendite im jeweiligen Geschäftsbereich beurteilt, in dem sie Produkte, Dienste und Microservices für interne und/oder externe Kunden bereitstellen. Ihre Teams übernehmen die Verantwortung für ihre Produkte und Dienstleistungen. Damit endet die Arbeit in Fachsilos, die Geschäftsergebnisse kaum beachten.

Wie bauen Sie Ihre DevOps-Teams und Ihre Softwarearchitektur auf?

DevOps schlägt keineswegs vor, alle laufenden Projekte Ihrer Organisation auf einmal umzubauen. Sie können Ihre Teams mit geringer Störung und dennoch spürbarer Wirkung auf DevOps vorbereiten, indem Sie Fachleute in Projektteams aufnehmen. Haben Ihre Teams Expertise in Bereichen wie Qualitätssicherung, Informationssicherheit, Datenbanken, Netzwerke, Server und Betrieb, können sie ihre Softwareprodukte und -dienste eigenständig entwerfen, bereitstellen und warten.

In den neuen produkt- und serviceorientierten DevOps-Teams gehören Verfügbarkeit, Qualität, Leistung, Informationssicherheit und Compliance zur täglichen Arbeit aller. Wie sollen Teams hochverfügbare, sichere und hochwertige Anwendungen für die Belastung und Last ihrer Kunden entwickeln, wenn sie nichtfunktionale Anforderungen erst nach Entwurf und Entwicklung beachten? Wie gut können externe Fachleute Sicherheit und Qualität beurteilen, wenn sie in keine Entwicklungsphase Ihrer Produkte und Dienste eingebunden waren? Leistungsstarke Teams holen sich daher bei externen Fachleuten Rat. Die volle Verantwortung für alle nichtfunktionalen Anforderungen behalten sie in jeder Phase des Softwarelebenszyklus.

Eine weitere Möglichkeit

Google verbindet sehr erfolgreich Funktionsteams mit produkt- und serviceorientierten DevOps-Teams. Beide verstehen den Auftrag der Organisation für ihre Produkte und Dienste als gemeinsames Ziel. Funktionsteams erstellen Vorlagen wie Checklisten und Anwendungsgerüste sowie Self-Service-Systeme, etwa für die eigenständige Bereitstellung und Konfiguration von Servern und Netzwerken. Damit werden sie nicht zum Engpass für die Produkt- und Serviceteams. Sie arbeiten schon in frühen Entwicklungsphasen mit diesen Teams zusammen, unterstützen sie, prüfen Entwürfe, Code und Tests konstruktiv in Peer-Reviews und beraten die Teams laufend.

Wie groß sollte Ihr DevOps-Team sein?

Die ideale Größe liegt bei 5 bis 10 Personen. Ein kleines Team vereinfacht Kommunikation und Abstimmung. Teamleitung und Teammitglieder verbringen weniger Zeit mit Nebentätigkeiten und Koordinationsaufwand. Auch der Umfang der betreuten Produkte und Dienstleistungen bleibt begrenzt. Das verringert die Komplexität und erleichtert Wartung und Betrieb. Alle behalten das Gesamtbild im Blick und sammeln etwas Führungserfahrung, weil sie an einem entscheidenden Auftrag für ihre Organisation mitarbeiten. Die Teamleitung stimmt sich mit der höheren Führungsebene über die Ziele ab und vermittelt sie dem Team.

Was tun, wenn ein Team mit bis zu 10 Personen Ihr Produkt und Ihren Dienst nicht mehr bewältigen kann?

Gliedern Sie ein neues Produkt oder einen neuen Dienst aus und stellen Sie ein eigenes DevOps-Team dafür auf. Produkte und Dienste können sich an zahlende externe Kunden richten. Für interne Kunden können Sie ebenfalls Produkte, Dienste oder sogenannte Microservice-APIs mit eigenen Teams aufbauen. Wird etwa das Abrechnungssystem für ein Team mit bis zu 10 Personen zu groß, könnte ein separates Team die API für den Datenbankzugriff übernehmen. Ein weiteres könnte die API für Online-Zahlungen und ein drittes die Stapelverarbeitung betreuen. Alle sollten ein gemeinsames Code-Repository und eine gemeinsame Deployment-Pipeline nutzen, damit kontinuierliche Integration, schnelle Auslieferung und der Erfolg der Organisation gesichert sind.

In eng gekoppelten Architekturen können kleine Änderungen an einer Anwendung zahlreiche Arbeitsabläufe beeinträchtigen. Produkte, Dienste und Microservice-APIs sollten deshalb lose gekoppelt sein. Jedes DevOps-Team sollte nur einen Teil der lose gekoppelten Architektur verantworten. Es kann seine Software dann eigenständig entwerfen, entwickeln und bereitstellen. Ein Frühwarnmechanismus in der Deployment-Pipeline sollte die Teams automatisch und schnell über mögliche Nebenwirkungen eines Code-Check-ins informieren.

Wie können Teams mit bis zu 10 Personen den gesamten Softwarelebenszyklus von der Architektur bis zum Betrieb eigenständig abdecken?

Ermutigen Sie alle im Team, Generalisten zu werden, und geben Sie ihnen Gelegenheit, kontinuierlich neue Fähigkeiten aufzubauen.

Stellen Sie ausschließlich Personen ein, die unabhängig von ihren aktuellen Kenntnissen und ihrer Erfahrung lernen und sich weiterentwickeln wollen. Meiden Sie Menschen, die erwarten, anhand eines festgelegten Rollen- und Aufgabenprofils bewertet zu werden. Ihre Organisation, Produkte und Dienstleistungen bleiben schließlich nicht unverändert.

Anforderungen ändern sich spätestens morgen, wenn nicht schon heute.

FAZIT

In diesem Kapitel haben wir die Nachteile von Matrixorganisationen und ihren Fachsilos sowie den Lösungsansatz von DevOps erläutert.

DevOps empfiehlt kleine Teams mit bis zu 10 Personen, die auf Produkte, Dienste oder Microservice-APIs ausgerichtet sind.

In diesen Teams sollten breit aufgestellte Full-Stack-Entwickler arbeiten, die alle Phasen des Softwarelebenszyklus von Entwurf bis Wartung eigenständig abdecken.

DevOps setzt auf eine lose gekoppelte serviceorientierte Architektur (SOA), in der jedes Team einen Teil der Architektur verantwortet und betreibt.