Erfolgsfaktoren für Platform Engineering

In unserem Blog-Artikel Platform Engineering – Die DevOps Evolution? haben wir die Beweggründe für Platform Engineering beleuchtet und die typischen Bausteine beschrieben. In dieser Fortsetzung beschäftigen wir uns mit der Frage, wie Platform Engineering (als Prozess) und Internal Developer Platforms (IDPs, als Produkt) möglichst erfolgreich im Unternehmen etabliert werden können.

Wir legen den Fokus dabei insbesondere auf die folgenden Fragen: Ab wann lohnt es sich, als Unternehmen überhaupt in Platform Engineering zu investieren? Welche Erfolgsfaktoren muss ich dabei im Blick behalten?

Wann sollte ich Platform Engineering betreiben?

IDPs versprechen viel: verbesserte Developer Experience und schnellere Produktentwicklung sowie Einhaltung von Good Practices, Security und Compliance. Allerdings ist nicht für jedes Unternehmen der Aufbau einer IDP unbedingt sinnvoll. Platform Engineering funktioniert vor allem über Skaleneffekte (mehr dazu später). Je mehr Teams für die Nutzung von Plattform-Services infrage kommen, desto besser kann die IDP ihre Vorteile ausspielen. Im Umkehrschluss heißt das: In Start-ups, Kleinstunternehmen oder Firmen mit sehr kleiner IT-Sparte sind sie meist wenig hilfreich und erfordern zu viele Vorabinvestitionen im Verhältnis zum erzielten Einsparpotential.

Eine genaue Beschäftigten- oder Teamzahl, ab der eine IDP gewinnbringend aufgebaut werden kann, gibt es natürlich nicht. Aus unserer Erfahrung zeigt sich, dass Platform Engineering sehr individuell gestaltet werden und zum Unternehmen passen muss. Eine individuelle Bewertung ist wichtig, z. B. auf Basis folgender Fragestellungen:

• Arbeiten die Teams bereits mit relativ homogenen Prozessen, Tools und Technologien?
• Findet bereits ein regelmäßiger Austausch zwischen den Teams oder stellvertretenden Personen statt?
• Sind die Teams in Bezug auf die an sie gestellten Anforderungen sehr unterschiedlich (bspw. unterliegt eine Geschäftssparte höheren regulatorischen Anforderungen als andere)?
• Wie beeinflussen Unternehmensvision, -strategie und IT-Strategie die Teams und verwendete Tech Stacks?

Diese Auswahl an Fragen ist ebenfalls keine vollständige Liste. Sie soll veranschaulichen, dass die Entscheidung, eine IDP aufzubauen, sehr individuell getroffen werden muss.

Welche Erfolgsfaktoren spielen für IDPs eine wichtige Rolle?

Schauen wir uns an, welche Faktoren uns in unseren bisherigen Projekten als entscheidend aufgefallen sind. Sie sind sowohl organisatorischer als auch technischer Natur.

Management Buy-In

Ohne Unterstützung der C-Suite geht es nicht. Je nach Größe des Unternehmens wird die Anzahl der Mitglieder eines Platform-Teams schnell zweistellig. Die damit verbundenen Vorab-Investitionen und die daraus resultierenden langfristigen Vorteile müssen dem Management klar kommuniziert werden.

Darüber hinaus sind die Akzeptanz und die Unterstützung durch die fachlichen Teams ausschlaggebend für den Erfolg einer Plattform. Hier kann das Management unterstützen, den IDP-Gedanken im Allgemeinen und konkrete plattformbezogene Vorhaben im Speziellen in Unternehmensbereiche außerhalb des Plattform-Teams zu tragen.

Cloud Abstraction Layer Trap vermeiden

Beim Bau einer IDP wollen wir besonders wertstiftende und oft verwendete Komponenten und Prozesse zentral bereitstellen. Oft neigen IDP-Vorhaben jedoch dazu, eine Art dünnen „Opinionated Configuration Wrapper“ um eine Cloud-API bereitzustellen. Wir nennen das die „Cloud Abstraction Layer“-Falle.

Ein Teil der Anforderungen (insbesondere aus dem Bereich Compliance) lässt sich durch vorkonfigurierte Subscriptions bei Azure oder AWS schnell abdecken. Policies verhindern zum Beispiel das Bereitstellen von Ressourcen in Regionen außerhalb der EU. Diese Abstraktion des Cloud-Layers ist aber höchstens die halbe Miete: Golden Paths, Self-Service-Ansätze, sowie Beratung und Training der User-Teams sind mindestens genauso wichtig, wenn nicht sogar wichtiger.

Ähnlich ist es auch bei Tools, die im Rahmen von Plattformen immer wieder genannt werden: Backstage alleine macht noch keine IDP! Dieser Punkt lässt sich daher noch weiter fassen:

Nicht einfach nur eine technische Lösung

Ähnlich dem vorherigen Argument der Cloud Abstraction Layer Trap kann es auch problematisch sein, die IDP als rein technisches Produkt aufzufassen: Eine Sammlung loser Komponenten, die die Entwicklungs-Teams zwar nicht selbst betreiben müssen, bei deren Kombination und Einsatz sie aber auch keine konkrete Unterstützung erhalten.

Das ist einerseits unpraktisch, weil Teams dann doch wieder wertvolle Zeit damit verbringen, immer wieder ähnliche Integrationen zu bauen (z. B. Deployment-Pipelines, Infrastructure-as-Code-Setups). Und andererseits, weil das IDP-Team so gar nicht sinnvoll evaluieren kann, welche typischen Probleme und Anwendungsfälle die Teams haben.

Hier ist ein Umdenken wichtig: Das Plattform-Team betreibt ein Produkt. Es sollte möglichst schlüsselfertig sein. Wir machen nicht nur „Betrieb“, wir arbeiten kundenorientiert. Dazu gehört auch, eine Community rund um die Plattform aufzubauen und zu pflegen (Stichwort „Hilfe zur Selbsthilfe“). Einheitliches und gewissenhaftes Branding hilft ebenfalls, den Produktcharakter der Plattform zu stärken. Damit sind wir auch schon beim nächsten Faktor:

Die IDP als Produkt verstehen

Auch wenn die darüber verfügbaren Services „nur“ internen Developern zur Verfügung stehen, sollte die Plattform als eigenes Produkt wahrgenommen werden. Die Nutzer:innen dieser Plattform haben hohe Ansprüche an Funktionalität, Stabilität und Dokumentation. Je besser das Wertversprechen der Plattform kommuniziert und erfüllt wird, desto besser die Kundenbindung.

Zusätzlich hilft Produktmarketing, die Bekanntheit zu steigern: Ein einprägsamer Name, ein Logo mit Wiedererkennungswert und Plattform Evangelists sind Möglichkeiten, einen Wiedererkennungswert zu erzeugen.

Um diese Kommunikation nachhaltig zu gewährleisten, kann es hilfreich sein, Methoden aus dem Produkt-Management (z. B. bei der Product Discovery) anzuwenden. Da auf eine IDP diverse Stakeholder einwirken (das betreibende Team, die Entwicklungsteams, Compliance-Verantwortliche, Management, …), müssen auch Kapazitäten für Produktverantwortung geschaffen werden.

Arbeit wirklich effizienter machen

Platform Engineering muss immer eine Balance finden, zwischen tatsächlicher Arbeitsvereinfachung für die Teams einerseits und der Erfüllung von Compliance- und Governance-Anforderungen andererseits. Letzteres ist unbestreitbar ein wichtiger Aspekt für das Management Buy-In (s. o.). Trotzdem sollte die  IDP nicht zu sehr auf diese Seite des Spektrums ausgerichtet sein, da sie sich sonst schnell wie eine Aneinanderreihung von „Compliance-Feuerreifen“ anfühlen kann, durch die die Teams springen müssen.

Entsprechend muss der Effizienz- und Effektivitäts-Gedanke maßgebend für das Design einer Plattform sein. Die IDP muss für die Teams echte Pain Points lösen und die Arbeit tatsächlich effizienter machen. Im besten Fall sind die Effizienzsteigerungen auch noch messbar, s. hierzu auch unten Erfolg bei IDP-Projekten messen.

Kein Zwang

Eine IDP sollte nicht bereits kurz nach ihrer Einführung als „alternativlos“ angesehen werden. Teams zu zwingen, Platform-Services zu nutzen (insbesondere verbunden mit Deadlines), sorgt schnell für Unmut. Die Plattform sollte ein Angebot sein, das durch seine Features überzeugt. Das Framing „Teams wollen die Plattform nutzen, weil sie ihnen Arbeit abnimmt und die kognitive Last reduziert“ ist extrem wichtig für die langfristige Akzeptanz. Es wird sehr oft Teams mit besonderen Anforderungen geben, die die Plattform nicht bieten kann (s. auch „Die 80/20-Regel“). Es muss ein valider, gangbarer Weg sein, dass diese Teams ihre Services (oder Teile davon) außerhalb der Plattform entwickeln dürfen. Eine modulare IDP-Gestaltung hilft hier dabei, dass deren Produkte trotzdem noch Platform-Services nutzen können, wo möglich.

Die 80/20-Regel

Jeder Toggle und jede zusätzliche Variable, die die Teams selbst setzen können, erhöhen die Komplexität für das Plattform-Team. Die Zahl der Feature-Konstellationen kann schnell explodieren.

Eine IDP kann es daher nicht allen recht machen. Das Pareto-Prinzip bei der Auswahl und Priorisierung von Vorhaben anzuwenden, ist sinnvoll. Je mehr Teams von einer Komponente profitieren können, desto besser. Zusätzlich bietet es sich hier an, bei der Erstellung von Golden Paths auf Modularität zu setzen. Team A kann Baustein 1 aus dem Golden Path nutzen, Team B die Bausteine 2 und 3, Team C kann den Golden Path idealerweise komplett anwenden. Und am besten ist es natürlich, möglichst viele Teams vom Typ C zu haben.

Think Big, but Start Small

Auch wenn wir die IDP als Produkt verstehen, mit dem wir eine Mission und Vision verfolgen, sollte dieses Produkt inkrementell und anforderungsbasiert wachsen.

Die Autoren des vielzitierten Buches Team Topologies haben den Begriff der Thinnest Viable Platform (TVP) geprägt. Damit bezeichnen Sie die kleinstmögliche Ausprägung einer IDP, die immer noch wertstiftend für das Unternehmen ist. Oft wird als Extrembeispiel einer sehr „dünnen“ Plattform ein rein textbasiertes Wiki genannt, in dem Good Practices und häufig genutzte Services festgehalten sind. Wenn das ausreicht, um Teams dabei zu helfen, Teile ihrer Arbeit effizienter gestalten zu können, ist der Plattform-Gedanke erfüllt!

In aller Regel wünschen sich Teams mit der Zeit mehr Features von der Plattform. Unter Berücksichtigung der 80/20-Regel kann die IDP dann schrittweise erweitert werden – immer vor dem Hintergrund, dass sie möglichst eine TVP bleiben sollte! Denn auch skalierte Plattformen mit großem Funktionsumfang sollten immer nur so viel wie nötig beinhalten, um den Betriebsaufwand der Plattform mit ihrem Nutzen in der Waage zu halten.

Erfolg bei IDP-Projekten messen

Um den Erfolg einer IDP zu messen, gibt es eine Vielzahl möglicher Metriken. Welche davon zum Einsatz kommen, hängt stark davon ab, welches Hauptziel mit der Platform verfolgt wird. Hier sind einige Ideen:

Ziel	Mögliche Metriken
Technische Exzellenz vorantreiben	Anzahl der Kundensupport-Anfragen / Monat Anzahl der Bugs / Monat Uptime der Systeme Performance / Durchsatz der Systeme
Kundenzufriedenheit steigern (sowohl der Platform-Kunden als auch der Endkunden)	Anzahl der Kundenreviews mit Bewertung >= 4/5 Net Promoter Score Anzahl der Bestandskunden Anzahl der Neukunden Monthly Active Users
Finanzielle Ziele	Umsatz Anzahl der Neukunden Monthly Active Users
Zufriedenheit der Teams erhöhen	Team Velocity Anzahl durchgeführter Experimente / Monat Team Happiness Survey Scores

Natürlich gilt auch für IDPs Goodharts Gesetz: „When a measure becomes a target, it ceases to be a good measure.“

Zusammenfassung

Wie so häufig lautet die Antwort auf die Fragen „Sollte ich eine IDP aufbauen?“ und „Wovon hängt der Erfolg meines Platform-Engineering-Projekts ab?“: Es kommt darauf an.

Wir haben in diesem Artikel einige Kriterien genannt, die uns in unseren bisherigen Projekten begegnet sind. Wir haben außerdem Denkanstöße bezüglich der Frage gegeben, für welche Unternehmen IDPs überhaupt in Frage kommen und welche Metriken man zur Erfolgsmessung einsetzen kann.

Unser Hauptanliegen ist dabei relativ einfach: Eine IDP ist nie ein Produkt von der Stange, sondern muss immer unter Berücksichtigung der Unternehmenskultur, der Teamstrukturen, der Tech Stacks und vieler weiterer Faktoren individuell aufgebaut werden. Nur dann kann sie nachhaltig erfolgreich sein und IT-Teams zu neuen Höhenflügen verhelfen.