Was ist Platform Engineering? Erklärt in 5 Minuten

Platform Engineering ist schwerer zu erklären, als es sein sollte. Man begegnet dem Begriff viel eher als eng gefasstes Marketing-Label denn als der umfassenden Disziplin, die er beschreibt.

Die meisten Unternehmen verkaufen keine Software. Sie verkaufen Autos, Versicherungen, Bananen, Bootsfahrten und vieles mehr. Ihre Software existiert, damit sie ihr Geschäft betreiben können, und ihre IT-Systeme existieren, damit sie ihre Software entwickeln und ausführen können. Keines von beiden generiert für sich genommen Umsatz, doch beide können erhebliche Hindernisse für die Wertschöpfung darstellen.

Eine Internal Developer Platform (IDP) ist die Gesamtheit von Tools, Services und Workflows, die Entwicklerteams benötigen, um die Verantwortung für die Entwicklung und den Betrieb ihrer Softwarekomponenten zu übernehmen. Platform Engineering ist die Disziplin, die sich mit der Konzipierung und der kontinuierlichen Verbesserung von IDPs befasst, die es Softwareteams ermöglicht, sich auf ihre Software und das dahinterstehende Geschäft zu konzentrieren, anstatt auf die zugrunde liegenden IT-Systeme.

Das Kernparadigma: Die Plattform ist ein Produkt

Plattformteams behandeln ihre IDP wie ein Produktportfolio. Entwicklerteams sind ihre Kunden.

Man kann Teams dazu zwingen, die eigene Plattform zu nutzen, aber man kann sie nicht dazu zwingen, sie zu mögen. Zwingt man sie, provoziert man Schatten-IT. Einige Teams werden ihren eigenen Weg gehen, egal ob das Unternehmen es erlaubt oder nicht. Jedes Plattformangebot steht daher im Wettbewerb mit Alternativen. Diesen Wettbewerb zu gewinnen, ist die Aufgabe des Plattformteams.

Deshalb beginnen Plattformteams wie Produktteams zu arbeiten:

• Nach Nachfrage priorisieren. Bauen, was Teams anfordern und was die Wertströme benötigen.
• Messen statt raten. Die Nutzung pro Angebot und die Zufriedenheit der Entwickler steuern die Roadmap.
• Kundensupport bieten. Und jede Supportanfrage als Fehlerbericht betrachten. Denn sie bedeutet, dass etwas auf der Plattform komplizierter ist, als es sein sollte.
• Angebote vermarkten. Ein Angebot, das niemand kennt, könnte genauso gut gar nicht existieren. Vermarktung durch Demo-Sessions, Communities of Practice, interne Blogbeiträge, Newsletter.
• Sich kontinuierlich verbessern. Dazu gehört, dass Teams aus dem herauswachsen, was gebaut wurde. Genauso wie das Einbringen von Ideen, nach denen niemand gefragt hat.

Interne Kunden zahlen nicht, und das Plattformteam wird so oder so finanziert. An dieser Stelle hinkt die Metapher. Es gibt keinen monetären Markt, der Produktdenken erzwingt. Deshalb muss man sich für Platform Engineering bewusst entscheiden.

Das Ziel sind Plattformangebote, die Entwickler tatsächlich nutzen wollen, weil der Weg über die Plattform der einfache Weg ist und nicht weil es ihnen befohlen wurde.

Wie man mit Platform Engineering startet

Platform Engineering ist eine umfassende Disziplin, und eine IDP kann wie ein Gebilde tausend beweglicher Teilen wirken. Der Einstieg muss jedoch nicht schwer sein. Im Folgenden werden drei Praktiken vorgestellt, von denen keine eine bereits bestehende Plattform voraussetzt.

1. Goldene Pfade

Ein goldener Pfad ist ein offiziell unterstützter Weg für eine wiederkehrende Aufgabe, wie das Erstellen einer Datenbank oder das Bereitstellen eines neuen Service. Ein Plattformteam betreut diesen Pfad und steht dafür gerade, wenn etwas schiefgeht. Es ist nicht der einzige Weg, den Teams wählen können. Aber wenn sie einen anderen Pfad einschlagen, sind sie auf sich allein gestellt.

Wie viel man in Automatisierung investiert, hängt davon ab, wie oft die Aufgabe anfällt. Etwas das ein Team zweimal im Jahr tut, verdient eine Anleitung mit klaren Schritten. Etwas das jede Woche getan wird, verdient wiederverwendbare Komponenten, eine kuratierte Pipeline und integrierte Sicherheits- und Compliance-Prüfungen. Wer gerade erst anfängt: Auch eine Anleitung ohne jegliche Automatisierung ist bereits ein echter Golden Path.

2. Self-Service

Keine Tickets, keine Warteschlangen, keine Meetings. Self-Service bedeutet, dass auf dem goldenen Pfad nichts auf eine Person warten muss. Zero-Touch-Sales, aber für Entwickler.

Tickets und Warteschlangen sind der offensichtliche Teil. Ein Team, das eine Staging-Umgebung oder eine Datenbank benötigt, erhält diese in Sekundenschnelle, anstatt einen Antrag zu stellen und darauf zu warten, dass sich das Backlog eines anderen Teams leert. Die Schnittstelle kann eine API, ein Befehl, ein Pull Request oder ein Webportal sein; welche Option man wählt ist unwichtiger als viele erwarten. Was Self-Service ausmacht, ist dass keine dieser Aktionen im Posteingang von jemandem landet.

Meetings sind der interessante Teil, da sie meist gut gemeint sind. Ein Plattformteam, das Entwickler bittet, sich vor dem Onboarding zu melden, möchte helfen. Es betreibt damit aber auch Enterprise-Sales: „Interessiert? Kontaktieren Sie uns!“ Was folgt, sind Kickoff-Calls, Absprachen und gelegentliche Freigabe-Meetings. Das bedeutet der Einstieg hängt von der Verfügbarkeit anderer ab. Die Lösung besteht meist nicht darin, die Meetings besser zu gestalten, sondern Dokumentation und automatisierte Prozessen zu schaffen die so gut sind, dass ein Gespräch gar nicht erst erforderlich ist.

Das bedeutet keineswegs, dass jeder beliebig Ressourcen bereitstellen und Kosten anhäufen kann. Es bedeutet Leitplanken entlang des Pfades statt einer Schranke zum Anhalten. Es gibt nichts mehr zu genehmigen, weil die Optionen, die einer Genehmigung bedürften, gar nicht erst angeboten werden.

3. Reduzierte kognitive Belastung

Kognitive Belastung umfasst alles, was ein Entwickler wissen und entscheiden muss, das nicht direkt mit der Software zu tun hat, die er eigentlich entwickelt.

Infrastruktur-Tools bringen steile Lernkurven mit sich, und ein Team muss möglicherweise mehrere Tools für verschiedene Arten von Änderungen erlernen. Eine gute Abstraktion fängt das ab, sodass Teams die Werkzeuge, auf denen eine Plattform aufbaut, nicht erlernen müssen. Abstraktionen sind jedoch oft lückenhaft ("leaky"), und eine schlechte Abstraktion kostet mehr, als sie spart. Denn wenn sie bricht, muss ein Team sowohl die Abstraktion verstehen, als auch alles was sie verborgen hatte.

Jede sichtbare Option ist eine Entscheidung mehr, die jemand treffen muss. Selbst ein gut gewählter Standardwert bringt jemanden dazu, innezuhalten und sich zu fragen, ob er für den eigenen Use Case passt, was genau zu tun ist und ob man nicht einfach ein anderes Team kopieren kann.

Die Frage bei jedem Konfigurationsparameter auf einem goldenen Pfad lautet daher, ob er überhaupt nötig ist:

• Am besten: Kein Parameter. Die Plattform entscheidet und niemand muss darüber nachdenken.
• Gut: Ein sinnvoller Standardwert, den man bei Bedarf überschreiben kann.
• Am schlechtesten: Ein Pflichtfeld ohne jegliche Hilfestellung.

Es ist einfacher, einen Parameter hinzuzufügen, als einen zu entfernen. Am besten fängt man klein an. Eine gute Plattform legt nur offen, was wirklich eine Entscheidung erfordert und verbirgt worum sich Teams normalerweise nicht kümmern müssen. Für Fälle die niemand vorhergesehen hat bleibt ein Notausgang ("Escape Hatch").

Der konkrete Nutzen

Der erste Gewinn ist Zeit. Jede Stunde, die ein Team damit verbringt, auf ein Ticket zu warten, in einem Kickoff-Call zu sitzen oder herauszufinden, welcher von dutzenden Parametern gesetzt werden muss, ist eine Stunde die nicht für die Weiterentwicklung der Software genutzt wird, die das eigentliche Geschäft unterstŭtzt.

Der zweite Gewinn ist Kapazität. Wenn jede neue Infrastrukturkomponente und jede Änderung als Anfrage beginnt, erhöht jedes neue Team den Arbeitsaufwand der Plattformteams. Dadurch wird die Plattform zum Flaschenhals für die Lieferfähigkeit aller anderen.

Eine Plattform entsteht nicht mit einem großen Knall. Sie entsteht Pfad für Pfad.