Plattformen als Motor cross-funktionaler Teams

Teamautonomie liegt voll im Trend. DevOps, wo man nur hinschaut. Teams stellen sich immer häufiger cross-funktional auf. Aus gutem Grund.

Kurze Wege und lokale Entscheidungen kommen – nicht nur, aber besonders – modernen verteilten, aber auch Technologie-lastigen Architekturen wie Microservices entgegen, wo viele verschiedene technische Komponenten und Frameworks zusammenkommen. Die Auswahl der technischen Basis für Microservices soll bestmöglich zur Aufgabenstellung passen. Da liegt es doch auf der Hand, dass das Entwicklungsteam nicht nur passende Technologien auswählt, sondern diese auch gleich selbst testet und betreibt.

Technologie-lastige Architekturen gehören nicht nur deshalb untrennbar mit DevOps zusammen, weil ein “über die Mauer werfen” zu einem klassischen OPS-Team gar nicht mehr möglich ist. …Besonders nicht in größeren Unternehmen, wenn gleich mehrere Teams alle ihre diversen Lösungen an ein zentrales OPS-Team übergeben würden.

Schnelle Leitung versus Komplexität

Aus eigener Erfahrung kann ich sagen, dass die Arbeit in einem cross-funktionalen Team viele Vorteile mit sich bringt, wenn man Betriebsthemen im Teamchat oder mit dem Menschen gegenüber klären kann. Allerdings bringt es auch eine hohe Komplexität mit sich. Das Team ist nicht nur für den Betrieb von fachlichen Services verantwortlich, sondern auch für das Aufsetzen, Automatisieren und Betreuen einer CI/CD Pipeline und geeigneter Monitoring- und Alerting-Tools mit den zugehörigen Dashboards. Das schließt ein, sich laufend Gedanken zu machen, was überwacht werden soll bzw. auf welchen Ereignissen Alerts benötigt werden. Natürlich gehören auch die passenden Laufzeit-Umgebungen und der Umgang mit zum Beispiel Passwörtern, Zertifikaten oder Firewalls dazu. All das ist notwendig, um stetig stabile Features zu liefern.

Hier bekommen wir schnell ein Problem, weil es schlecht skaliert. In größeren Unternehmen mit vielen autonomen Entwicklungsteams ist es nicht besonders effizient, wenn jedes Team wieder vor der Aufgabe steht einen passenden Buildserver aufzusetzen, ein Cluster für verschiedene Umgebungen produktivfähig zu gestalten bzw. Deployment-Prozesse zu definieren. Dann gibt es ein Trade-off zwischen Autonomie und Effizienz.

Communities und Gilden?

Ein erster folgerichtiger Schritt, den viele Unternehmen mit mehreren autonomen Teams gehen, ist das durch Spotify bekannt gewordene Konzept der Communities oder auch Gilden (mehr in diesem Artikel). Ziel ist das Vernetzen der Teams zu unterschiedlichen Themen. Die Einführung von Communities durfte ich bereits als Teil ein Entwicklungsteams, aber auch bei einem aktuellen Kunden begleiten.

Es ist positiv, wenn Teams von anderen lernen, wie diese gewisse Hürden und Probleme gemeistert haben. Sie können Vorgehensweisen oder Automatisierungen für den eigenen Kontext übernehmen. Dieses Vorgehen bedeutet nicht, dass für gut befundene Lösungen auch wirklich von allen Teams genutzt werden.

Möglichst viele Freiheiten helfen den Teams besonders am Anfang eines Projekts schnell Geschwindigkeit aufzunehmen. Sie können so selbstorganisiert gute technische Endscheidungen für das jeweilige Produkt treffen. Teams lernen eigenständig, was gut funktioniert; sie sammeln eigene Erfahrungen.

Querschnittslösung erwünscht

Für nachhaltige Lösungen braucht es bei manchen Problemen allerdings Querschnittlösungen. Das kann zum Beispiel eine Deployment-Pipeline in die Cloud sein, der Umgang mit Rollen und Rechten innerhalb der Anwendung, oder auch die Versionierung von Schnittstellen zwischen den Systemen der Teams. Die einzelnen Teams haben, nicht selten aus einem Feature-Druck heraus, die eigenen Aufgabenstellungen im Fokus – und das ist genau richtig. Lösungen werden dann in erster Linie so gebaut, dass sie für das eigene Team tragen; die Probleme des Nachbar-Teams sind nicht im Fokus, dadurch werden Probleme nicht übergreifend gelöst. Neue Teams werden auf die gleichen Stolperstellen treffen, und wieder eigene (und möglicherweise sogar ähnliche) Lösungen bauen. Was mir dabei noch aufgefallen ist: Nicht selten haben Teams getrennte Budgets, die nicht gern für übergreifende oder unternehmensweite Lösungen genutzt werden, die in der Regel ja auch aufwändiger sind.

Es kommt der Punkt, wo man die daraus entstehende Divergenz ein Stück weit wieder einfangen möchte. Bei wachsender Teamstärke wird ein gesundes Gleichgewicht zwischen der Freiheit der Teams und Normierung bzw. Alignment immer wichtiger. Basierend auf der Erfahrung der Teams sollten sinnvolle Rahmen gesetzt werden, um eine skalierbare, effiziente Produktionsstraße für eine nachhaltige Anwendungslandschaft auf Enterprise-Level zu entwickeln.

Viele Unternehmen finden nur schwer das richtige Maß zwischen sinnvollen Vereinheitlichungen, um mit den wachsenden Herausforderungen einer Enterprise-IT klar zu kommen, und der Autonomie von Feature-Teams. Entweder wird der Enterprise-Faktor überdimensioniert oder durch zu starke Entkopplung der Teams entsteht kein klares Landschaftsbild.

Im nächsten Abschnitt möchte ich eine Lösung für dieses Dilemma zeigen, die zwar eher bei den „Großen“ zu finden ist, sich aber nach meiner Erfahrung sehr gut auf das kleinere Kontexte anwenden lässt.

Google, Netflix und Co.

„Automation doesn’t just provide consistency. Designed and done properly, automatic systems also provide a platform that can be extended, applied to more systems. … A platform also centralizes mistakes. “

Aus: Site Reliability Engineering: How Google Runs Production Systems, 2016

Wo mehrere Teams arbeiten, gibt es vielerlei wiederkehrende Querschnittsthemen, die nicht direkt Teil des Produktes sind, aber genauso automatisiert und betrieben werden müssen. Diese redundant in Feature-Teams oder bei Gilden bzw. Communities aufzuhängen funktioniert, wie bereits erwähnt, nach meiner Erfahrung nur begrenzt, da der Fokus der Teams auf der Entwicklung der eigenen Features liegt oder für übergreifende Themen keinen Budgets in den Teams existiert.

Sehr geeignet ist ein eigenständiges „Plattform-Team“. Ein Plattform-Team ist nicht für den Betrieb von fachlichen Services oder Anwendungen anderer Teams verantwortlich – das liegt weiterhin in der Verantwortung der jeweiligen Teams. Ein Plattform-Team greift jegliche Form von Querschnittsautomatisierung auf und löst sie in Abstimmung mit den Feature-Teams oder Gilden übergreifend und nachhaltig. Außerdem ist das Plattform Team für den Betrieb der Querschnittslösungen verantwortlich. Das kann klassische Themenfelder wie Build + Deployment, Release-Strategie, Container-Umgebung, Security, Testing oder Monitoring umfassen, oder die Automatisierungen für strategisch wichtige Third-Party-Tools, etwa Datenbanken oder Messaging-Systeme. Es geht darum, die Teams in möglichst vielen Bereichen durch entwickelte Tools, Skripte oder Systeme gut bei der Entwicklung zu unterstützen.

Der Fokus des Plattform-Teams liegt dabei nicht auf spezifischen Lösungen für einzelne Feature-Teams. Das Plattform-Team denkt in Plattformen, die so vielen wie möglich zum „Self-Service“ verhelfen. Auch Unternehmens- oder Konzernreglementierungen oder -Ziele können dabei eine Rolle spielen.

SRE von Google

Sehr beeindruckend zeigt das die Rolle des „Site Reliability Engineers“, die Google sehr anschaulich im gleichnamigen Buch beschreibt. Die SRE-Teams helfen Feature-Teams dabei, Zielvereinbarungen in Hinblick auf Zuverlässigkeit in Zahlen auszudrücken und diese Ziele zu erreichen. Hier dreht sich alles um Automatisierung auf Basis einer Plattform. Das beginnt bei eigenen Systemen zur automatischen Steuerung von Paketen, die möglichst viele verschiedene Teams beim Release-Prozess diverser Produkte unterstützt, und geht bis zu eigens geschriebenen Cluster-Systemen zur dynamischen Verwaltung von Hardware. Das Profil eines SRE-Engineers entspricht im Kern der eines Entwicklers mit Hintergrundwissen zu Themen wie Netzwerk oder Unix. Ein SRE-Engineer soll maximal 50 Prozent seiner Zeit mit operativen Aufgaben verbringen; die andere Zeit investiert er oder sie in Entwicklung von Automatisierungslösungen, um Dinge für möglichst viele Feature-Teams zu verbessern.

Auch wenn SRE von Google als Implementierung von DevOps beschrieben wird, meidet Google den Begriff DevOps, da „Operations“ mit immer wiederkehrenden Aufgaben in Verbindung gebracht wird. Der Fokus dieses Profils soll sein, durch Automatisierung wiederkehrende Aufgaben so weit wie möglich zu reduzieren. Ein SRE-Team wächst bei Google deutlich weniger als ein Ops-Headcount. Die Menge der „Operation“-Tätigkeiten entwickelt sich parallel zur Größe der Anwendungslandschaft. Die gleiche Plattform kann dagegen nach dem SRE-Verständnis eine Hand voll oder eben auch mehrere Hundert Umgebungen bereitstellen.

Netflix beschreibt das im eigenen Blog ähnlich:

„…one of the primary goals of the platform is to enable other teams to focus on business logic, making experimentation, implementation, operation of stream processing jobs easy. By having a platform to abstract the ‘hard stuff’, removing complexities away from users, this would unleash broader team agility and product innovations.“

Aus: Netflix-Techblog bei medium

Die meisten sind nicht Google

Wenn ich dieses Modell zeige, geht es nicht darum, sich mit Google oder Netflix zu messen und ebenso komplexe Plattformen zu bauen. Es geht darum zu überlegen, wie man die Produktivität von Feature-Teams gesamtheitlich fördern kann, und weiterhin Innovation zulässt.

… und müssen es auch nicht werden

Wie so etwas in der Praxis aussehen kann, habe ich bei einem Kunden miterlebt. Der Großkonzern hat fürs Umsetzen der Digitalisierungsstrategie für bestimmte Themenfelder eigenständige Projektzentren gegründet, die aus diversen selbstorganisierten Teams bestehen. Diese Teams agieren weitestgehend unabhängig und kommen so in einer deutlich höheren Geschwindigkeit voran als es im Konzernrahmen möglich wäre. In dem Projektzentrum, in dem ich mitwirken durfte, gibt es ein übergreifendes Ops-Team, das sich anfänglich um die Betreuung und Automatisierung von reinen Infrastruktur-Themen gekümmert hat, zum Beispiel Maschinen und Umgebungen in der Cloud.

Zusammen mit den Ops-Rollen der jeweiligen Teams und später auch über Gilden, wurde transparent, womit sich die Teams beschäftigen. Aus der Erfahrung heraus waren die Teams in der Lage ihre Bedürfnisse an das OPS Team zu formulieren. Daraus hat sich mit der Zeit ergeben, dass jedes Team auf Abruf Kubernetes-Instanzen zu Verfügung gestellt bekommt. Dabei handelt es sich nicht um leere Kubernetes-Umgebungen, sie enthalten standmäßig bereits „Logging as a Service“ in Form von Kibana und Fluentd, und „Monitoring as Service“ in Form einer Prometheus-Instanz und eigens entwickelten Kubernetes-Controllern, die automatisch Metriken auf Grundlage von speziellen Annotationen der fachlichen Microservices abrufen. Außerdem wird eine „Vault as a Service“-Instanz auf Basis von „Hasicorp Vault“ zur Verfügung gestellt.

Aktuell wird an einer Konsolidierung beim Build-Prozess gearbeitet. Denkbar ist eine „as a Service“-Variante, die die Erfahrungen der Teams mit dem Package Manager HELM (mehr siehe hier) in eine gemeinsame Lösung überführen. Dieser gesunde Konsolidierungsprozess macht es auch möglich, die neuen Produkte ganzheitlich mit der bestehenden Landschaft des Großkonzern zu verknüpfen.

Ein anderes sehr schönes Beispiel habe ich auf der Kubecon Mai 2018 in Kopenhagen gesehen – hier gibt es den aufgezeichneten Vortrag.

Die New York Times hat es geschafft im großen Umfang Entwicklerteams auf eine einzige gemeinsame Build- und Deployment-Pipeline zu heben. Kern dabei ist ein Plattform Team, dass unter anderem bedarfsorientierte OpenSource-Plugins (mehr hier) für das gemeinsam genutzte Tool drone entwickelt.

Hard Stuff ist Ansichtssache

Jedes Unternehmen muss individuell herausfinden, was der „hard stuff“ ist, der als Querschnitt zwischen den Teams existiert.

Das bedeutet nicht, dass das Plattform-Team den anderen einfach ein Set an Tools vorschreibt. Es übernimmt im besten Fall die Aufgabe, zusammen über Communities oder Gilden wiederkehrende Herausforderungen oder Aufgabenstellungen sichtbar zu machen und eine gemeinsame Basis zu schaffen, in der jedes Team seine Bedürfnisse mit einbringen kann. Das Backlog füllt sich aus den querschnittlichen Problemen anderer. Ich habe auch schon miterlebt, wie tolle Lösungen aus einzelnen Teams generalisiert und für alle zur Verfügung gestellt wurden.

In jedem Unternehmen ist die Grenze jeweils eine andere, was in eine gemeinsame Plattform gehört und was weiterhin Teil der Feature-Teams bleibt.

Es ist ungemein produktivitätsfördernd, wenn neue Teams alle bestehenden Ressourcen und Vorteile der Teamautonomie nutzen können, um in Höchstgeschwindigkeit einen MVP zu liefern, ohne sich mit unterstützenden Themen wie Build- und Release-Prozessen auseinandersetzen zu müssen. Wenn ein Plattformteam auf dem richtigen Level agiert, also ohne einschränkend zu wirken, wird es von den Entwicklern geschätzt und als Unterstützung gesehen, die hilft, das eigene Ziel zu erreichen.

Außerdem muss nicht jedes neue Produkt auf der gemeinsamen Basis aufsetzen. Es kann gut sein, dass spezielle Anforderungen auch andere Tools benötigen. Dann mag es eine sinnvolle Entscheidung sein, wenn einzelne Teams einen anderen Weg gehen.

Zusammenfassend würde ich sagen: Ein querschnittsorientiertes Plattform-Team widerspricht nicht dem Ansatz crossfunktionalen Teams. In der richtigen Balance werden Querschnittsthemen nachhaltig und wirtschaftlich gelöst und Feature Teams können ungehindert mehr Ressourcen in Produktinnovation investieren.

---

Über den Autor