Platform Engineering: Braucht mein Unternehmen eine interne Developer Platform?

Wie viele Softwareentwicklungsteams machen dieselbe Arbeit in leicht unterschiedlicher Weise, obwohl es aus Endkund*innensicht völlig irrelevant ist, wie es gemacht wird? Wie viele Teams (Stream Aligned Teams) sind langsam, weil sie sehr viele Infrastruktur- und Build&Deploy-Aufgaben haben – und nicht z. B. weil sie zu viele Abhängigkeiten zu anderen Value-Stream-Teams haben? 

Zu diesen querschnittlichen Aufgaben zählen zum Beispiel der Container-Build oder sogar der ganze Build-Prozess, der Security-Scan, die Kafka-Entwicklungsumgebung oder das neue Datenbankschema in der Testdatenbank.

Die Kernfrage ist damit: Können wir solche Aufgaben effizienter erledigen, indem wir die Teams davon entlasten? Und was ist uns diese Beschleunigung wert?

Beschleunigung von Entwicklungsteams (Value-Stream-Teams) ist einer der Hauptgründe für die Entwicklung einer gemeinsam genutzten Plattform. 

Was ist neu an Platform Engineering?

An den Treibern für Veränderung (Beschleunigung, Vereinheitlichung, Zentralisierung von Spezialwissen) ist nichts neu. Nie haben Cross-Functional Teams" alles alleine erledigt – auch wenn wir uns einer auf DevOps-Prinzipien basierenden Herangehensweise verschrieben haben. Es gab immer Vorgaben (z. B. AWS-Cloud, React und Java). Vorgaben schränken ein, aber sie beschleunigen eben auch, weil wir nicht alles immer wieder von Neuem ausdiskutieren müssen.

Die zentrale Frage für Platform Engineering ist eher: Welche Teile der Landschaft werden zentral bereitgestellt? Und: Was davon muss von den Teams genutzt werden? 

„Vereinheitlichung“ als weiterer Grund für interne Entwicklerplattformen

Neben Geschwindigkeit durch Entlastung der Teams gibt es einen weiteren Grund für die Bereitstellung einer Plattform für alle Value-Stream Teams: Vereinheitlichung. Sie verspricht geringere Kosten, einfacheren Wechsel von Mitarbeiter*innen zwischen Teams, geringeren Aufwand, wenn Teams z. B. eine Komponente wegen einer Sicherheitslücke austauschen müssen (auch das kann natürlich bei Vereinheitlichung schneller gehen). 

Aber Vereinheitlichung ist immer ein zweischneidiges Schwert. Jeder, der selber entwickelt hat, weiß, wie sehr „One-Size-Fits-All“ ein Team lahmlegen kann. Der Zwang, unbedingt die zentrale Datenbank zu verwenden, kann dazu führen, dass ein Team drei Monate auf einen Zugang zu einem eigenen Schema in der Entwicklungsdatenbank warten muss (ist mir passiert – die Realität war sogar noch schlimmer). Aber alle sicherheitskritischen Aspekte, alles mit Zugängen zu (Cloud-)Umgebungen und vor allem dem „Billing“ für diese Zugänge sollten einheitlich sein. Aber wo genau die Grenze liegt, muss immer wieder neu ausbalanciert werden.

Brauche ich eigene Platform-Team(s)?

Irgendjemand muss natürlich diese Plattform bereitstellen und sich um sie kümmern. Unsere Heuristik: Ab 5–8 Entwicklungsteams lohnt es sich fast immer, ein eigenes Platform-Team zu etablieren. Aber das ist wirklich nur eine Heuristik. Wir empfehlen, mit kontinuierlich aktueller Dokumentation zu beginnen und nicht mit einem großen Team etwas zu bauen. Außerdem: Oft gibt es schon Plattform-Teams, sie wissen nur nicht, dass sie eins sind und was das für sie bedeutet. Denn Plattform-Teams haben als Kunden die anderen Entwicklungsteams und damit braucht es Service-Level-Agreements und frei verfügbare Kapazität, um schnell reagieren zu können. 

Kapazität frei verfügbar zu halten, ist oft eines der schwierigsten Aspekte: Das Platform-Team darf nicht komplett mit geplanten Aufgaben ausgelastet sein. Ein gewisser Prozentsatz darf nicht verplant sein und muss für Supportanfragen frei sein. Wir haben zum Beispiel sehr gute Erfahrungen damit gemacht, explizit Menschen für eine Woche für den Support abzustellen und diese Rolle durch das ganze Team zu rotieren. Manche Menschen haben da keinen Spaß daran, aber solange das Team klein ist, halten wir es für extrem hilfreich, wenn alle Menschen mal Support machen. Das sorgt auch für eher einfache, gut verständliche Plattform-Angebote und Dokumentation.

Freiheit und Regeln im Platform Engineering

Wir kennen das von internen Anwendungen, die oft die schlimmste UX haben. Sie müssen ja verwendet werden, warum dafür Geld ausgeben? Aber die Nutzer*innen verschwenden unglaublich viel Zeit und Energie darauf, die Anwendung zu umgehen. Wenn wir das auf die Idee einer Plattform übertragen:

Es ist zunächst sehr einfach, die Nutzung vorzuschreiben: „Wir haben so viel Geld investiert, wenn nicht alle das benutzen, rechnet sich die Plattform nicht“. Diese Argumentation ist natürlich offensichtlich falsch herum. In Wirklichkeit gilt: Die Investition hat sich nicht gelohnt, wenn niemand die Plattform verwenden möchte.

Aber natürlich gibt es Bereiche, in denen wir eine Verwendung vorschreiben müssen: Alles, was mit Security und Berechtigungen beim Zugriff auf die Plattform zu tun hat, sollte vorgegeben werden. Auch das Erstellen eines Accounts bei einem Hyperscaler und das Einrichten des Billings und ein paar Billing-Alerts sollten vorgegeben sein. Aber das Team sollte die Möglichkeit haben, eigene Billing-Alerts anzulegen. Unsere Empfehlung: Mit so wenig wie möglich Standardisierung zu starten und schrittweise zu erweitern. Wir haben auch schon mehrfach erlebt, dass Value-Stream Teams sich mehr „Guidance“ wünschen, damit sie einfach loslegen können. Deshalb unterscheiden wir drei Bereiche: 

Zuständigkeiten und Regeln für die Plattform 

Die verpflichtenden Teile sollten zunächst nur durch Security- und Compliance geforderte Aspekte enthalten. Alles weitere wird durch das Plattform-Team angeboten. Hier gilt es, nur so viel anzubieten, wie man auch sinnvoll supporten und kontinuierlich pflegen kann. Sonst verspielt man zu viel Kredit bei den Nutzer*innen, besser: Kund*in!. Denn die Nutzer*innen sind Kund*innen. Wenn sie alternative Angebote finden, die einfacher zu benutzen sind, werden sie die verwenden.

Ziele für eine Internal Developer Platform

Deshalb gelten folgende Ziele für die interne Developer-Plattform:

1. Einen neuen Service (Datenbank, Entwicklungsumgebung, Monitoring …) einzurichten, erfolgt genauso schnell, wie bei den bekannten Hyperscalern (das heißt auch: Es muss eine API geben, damit das automatisiert durch die Teams selbst erledigt werden kann).

2. Der neue Service ist automatisch mit den restlichen Services/Systemen der Plattform (Monitoring, IAM …) integriert. Die Integration ist damit schneller und einfacher als wenn das Team die Teile selber zusammenbauen muss.

3. Dokumentation und Support (SLO) sind mindestens so gut wie bei den Hyperscalern. Der Support bei den Hyperscalern ist zwar meist nicht gut, aber man findet zu den meisten Problemen eine Lösung im Internet. Das ist die Messlatte.

4. Wenn noch kein automatischer Service angeboten werden kann: Eine einfach zu verstehende Dokumentation eines erprobten und einfachen Vorgehens zur Nutzung einer Komponente („Golden Path“) ist besser als ein halbgarer Service.

Jetzt besteht die Chance, dass die Nutzer die Plattform verwenden wollen.

Man darf aber nicht vergessen, ein Plattform-Team bedingt eine Abhängigkeit aller Teams, die die Plattform nutzen zu diesem Plattform-Team. Die Kosten dieser Abhängigkeit (Abstimmungsaufwand und Verzögerungen) sind immer wieder neu auszubalancieren.

Wir brauchen „Platform as Product”

Der nächste Schritt ist dann, die Weiterentwicklung der Plattform wie eine Produktentwicklung anzugehen: 

• Regelmäßiges User Research: Bauen, was wirklich gebraucht wird. Sich wirklich neben Kund*innen setzen und zuschauen, ohne einzugreifen, ist oft unglaublich erhellend.

• Scope: Klar sagen, was das Plattform-Team macht und was nicht. Wenn die Plattform erfolgreich ist, steigen die Wünsche der Kund*innen, die nicht erfüllt werden können.

• Support leisten: Der Aufwand hierfür steigt mit der Anzahl der Kund*innen, da er nur begrenzt durch Self-Service und Dokumentation ausgeglichen werden kann. Und der Aufwand muss nicht nur eingeplant werden, es braucht auch oft andere Menschen dafür, als zu Beginn der Plattformentwicklung.

• Roadmaps veröffentlichen: Kunden wollen wissen, was wahrscheinlich als Nächstes kommt, damit sie entscheiden können, ob sie warten oder es selber bauen.

• Release Notes: Aus Kund*innensicht schreiben und nicht nur eine Liste von Ticket-Nummern oder Texten aus Jira, die für die Plattform-Entwickler*innen gedacht waren.

Idealerweise starten wir die Plattform-Initiative mit einem kundenzentrierten Ansatz. Aber oft gibt es ein erstes zentrales Angebot, etwa eine zentrale Datenbank, einen Kubernetes-Cluster und erst dann wird auf einen Plattform-as-Product-Ansatz gewechselt.

Was kommt in die Plattform?

Wie entscheiden wir jetzt, was wirklich zur Plattform gehört und was nicht? Wenn wir User Interviews machen, bekommen wir eine unglaubliche Menge an Ideen. Die Kernfrage ist aus unserer Sicht ganz klassisch: Wodurch werden Teams am meisten entlastet? Was machen im Moment viele Teams selber in ähnlicher Weise, aber jeder für sich? Das sind die perfekten Kandidaten. 

Guten Produktmanager*innen müssen wir das nicht erklären, aber oft kommen wir Plattformverantwortliche aus der Technik. Wir glauben gerne, wenn wir ein Tool wie Backstage einführen, ist alles erledigt. Okay, ich übertreibe, aber ehrlich gesagt, habe ich genau diese Einstellung schon oft genug gesehen. Die Einführung des Tools als Erfolgskriterium lässt sich halt einfach „messen“, die Nutzung auch noch, aber erst deutlich später. Aber den Nutzen zu messen, ist eine eigene Herausforderung. Wie viele Initiativen prüfen den initialen Business Case? Haben sich die Ausgaben wirklich gelohnt?

Postskriptum

Wir hören immer wieder, dass Softwareentwicklungsteams langsam seien. Aber verglichen womit? Und an welcher Stelle im Gesamtprozess geht die Zeit eigentlich verloren? Aus unserer Sicht oft in der Projektvorbereitung, bei der Budgetplanung und einfach dadurch, dass wir nicht die wirklich wichtigen (richtigen) Dinge bauen (build the right thing). Oft ist es sinnvoller (aber auch schwieriger) als erstes hier anzusetzen, als in interne Entwickler-Plattformen zu investieren.