1. Dezember 2025
Man kann nur so erfolgreich sein, wie die Rahmenparameter es zulassen
Rund 30 Menschen, die nie zusammengearbeitet hatten, sollten auf der grünen Wiese eine Internal Developer Platform bauen — ohne definierte Rollen, ohne Entwicklungsprozess, ohne Entscheidungsverfahren und vor allem ohne einen Kunden, der ein konkretes Problem hatte.
Eine Orchestrierungsebene schaffen, die Ressourcen über mehrere unternehmensinterne Cloud-Plattformen hinweg bereitstellt — und dafür die organisatorischen Voraussetzungen herstellen: Struktur, gemeinsame Sprache, Priorisierung und einen belastbaren Werkzeugentscheid.
Struktur und Scrum-of-Scrums-Setup etabliert, Orchestration Team aufgebaut, Domänenmodell durchgesetzt. Nach der Erkenntnis, dass der Eigenbau das falsche Paradigma verfolgte, gemeinsam evaluiert und mit Kratix in wenigen Wochen eine produktionsreife Umgebung inkl. Onboarding-Szenario aufgebaut. Eingesetzt wurde sie nie — es fehlten Mandat, Kundenbedarf und ein tragfähiges Kostenmodell. Von 30 Beteiligten blieben zuletzt sechs; es war mein Team.
Ich arbeite seit 2007 in der Softwareentwicklung. Automotive, Medizintechnik, komplexe IT-Systeme. Entwickler, Architekt, Lead Engineer, Product Owner, Teamleiter. In diesen Jahren gab es schwierige Projekte, zähe Projekte, Projekte unter widrigen Umständen — aber am Ende ist immer etwas ausgeliefert worden. Etwas, das jemand benutzt hat. In einem Fall fährt es bis heute in Autos herum.
Dann kam ein Vorhaben, das in drei Jahren nichts ausgeliefert hat. Kein Kunde. Kein produktiv genutztes Produkt. Kein tragfähiges Geschäftsmodell.
Das ist der Text darüber. Nicht, weil Scheitern per se lehrreich wäre — das ist es meistens nicht. Sondern weil ich in diesen drei Jahren mehr über die Bedingungen von Erfolg gelernt habe als in den fünfzehn Jahren davor, in denen sie einfach da waren und ich sie für selbstverständlich hielt.
Systeme, Produkte und Organisationen sind im Folgenden neutralisiert, wo sie nicht öffentlich sind.
Der Nullpunkt: dreißig Fremde auf der grünen Wiese
Es gibt einen Moment, den vermutlich jeder Product Owner kennt, der in ein neues Vorhaben kommt: Man sitzt in der ersten Runde, alle sind da, alle sind kompetent — und niemand kann die Frage beantworten, woran genau man eigentlich arbeitet.
Bei uns war das der Ausgangszustand, nur in größerem Maßstab. Für das Vorhaben waren rund 30 Menschen akquiriert worden, die noch nie zuvor miteinander gearbeitet hatten, verteilt über mehrere Standorte im internationalen Kontext. Grüne Wiese. Keine definierten Rollen. Kein etablierter Entwicklungsprozess. Keine Gesamtstruktur — und, das war der eigentliche Kern: kein Verfahren dafür, wie in diesem Gebilde überhaupt Entscheidungen getroffen werden.
Was es gab, war eine Idee — eine Plattform, die die Werkzeug- und Cloud-Landschaft des Konzerns interoperabel macht — und ein paar Beispiele, wie das vielleicht aussehen könnte. Das war der gesamte Auftrag. Ehrlicherweise hatte zu diesem Zeitpunkt niemand von uns wirklich verstanden, was das eigentlich ist.
Die Folge war vorhersehbar, aber niemand hatte sie vorhergesehen: Jeder ordnete sich selbst dort ein, wo er glaubte, den größten Mehrwert zu liefern. Keine Steuerung, keine verbindlichen Zuständigkeiten, keine Pflichten. Dreißig kompetente Menschen, die alle etwas Sinnvolles taten — und deren Arbeit sich nicht zu einem Produkt fügte.
Was wir richtig gemacht haben
Ich nenne diesen Teil zuerst und kurz, weil er nicht die Pointe ist — aber er gehört zur Wahrheit.
Einige Kollegen und ich haben angefangen, überhaupt erst Projektstrukturen einzuziehen, während die Mannschaft bereits umsetzte, was kaum jemand vollständig verstand. Wir haben uns auf ein Scrum-of-Scrums-Setup verständigt, weil es für ein Vorhaben dieser Größe das tragfähigste Modell war.
Das war kein Selbstläufer. Dahinter stand eine Gruppe von Leuten, die Strukturen schätzt und den Wert eines Backlogs verstanden hat — und das ist auch im 21. Jahrhundert nicht bei jedem angekommen. Im internationalen Kontext kommen andere Leadership-Muster und andere Vorstellungen davon hinzu, wie Verantwortung verteilt und wie entschieden wird. Ein Prozessmodell einzuführen ist deshalb nie primär eine methodische Frage. Es ist eine kulturelle.
Aus dieser Arbeit heraus entstand das Orchestration Team — und ich wurde sein Product Owner.
Das Zweite, was ich getan habe, war kein Feature. Es war, ein Domänenmodell zu erzwingen: Space, Resource Group, Managed Resource Group, Resource, Service. Fünf Begriffe. In Gesprächen mit vier Stakeholdern bekam man vorher fünf Definitionen davon, was eine „Ressource” ist. Ab dem Tag, an dem die Begriffe standen, hörten Diskussionen auf, die vorher in jedem Refinement neu geführt wurden.
Das ist die erste Aufgabe eines Platform-POs: Terminologie, nicht Roadmap. Man kann nicht priorisieren, was man nicht benennen kann.
Es hat trotzdem nicht gereicht. Und der Grund dafür stand von Anfang an im Raum.
Der Satz, an dem das Vorhaben gescheitert ist
Es wurde mehrfach und von verschiedenen Seiten eingefordert: Wir brauchen einen Kunden. Wir brauchen jemanden, der ein Problem hat.
Die Antwort darauf war immer dieselbe:
„Unsere Kunden wissen nicht, was sie brauchen. Wir müssen etwas bauen, das so gut ist, dass sie es uns aus der Hand reißen.”
Dieser Satz war in der Vergangenheit für andere Themen offenbar ein Erfolgskonzept gewesen. Deshalb war er schwer angreifbar — er hatte Historie.
Ich habe ihm nie geglaubt. Ich habe aber sehr lange geglaubt, dass irgendwann trotzdem ein Kunde auftauchen wird, der damit etwas anfangen kann.
Er ist nicht aufgetaucht.
Rückblickend ist das der einzige Satz, den man hätte kippen müssen, um alles andere zu retten. Alle weiteren Fehler — und es gab viele — sind Folgefehler davon. Wenn niemand mit einem konkreten Schmerz am Tisch sitzt, gibt es kein Kriterium, an dem man Prioritäten misst. Und ohne dieses Kriterium ist jede Diskussion Geschmackssache, jede Roadmap eine Meinung, und jede Umstrukturierung genauso gut begründbar wie die vorherige.
Ein Backlog ohne Problembesitzer ist eine Wunschliste mit Prozess.
Das Fallbeispiel: Customer Onboarding
Am ehrlichsten lässt sich die Realität einer internen Plattform an einem einzigen Thema zeigen. Bei uns war das der Kunden-Onboarding-Prozess.
Die Aufgabe klang trivial: Ein Entwicklerteam meldet sich über ein Formular an und bekommt danach seinen Arbeitsbereich — über drei Plattformen hinweg konsistent bereitgestellt.
Tatsächlich standen dahinter drei APIs, drei Validierungslogiken und drei Vorstellungen davon, wann eine Bestellung als genehmigt gilt. Eine Plattform validierte serverseitig, die andere erwartete Vorvalidierung durch den Aufrufer. Eine kannte ein Business-Approval mit bis zu 30 Tagen Laufzeit, die andere provisionierte in Minuten. Der Sequenzdiagramm-Entwurf für den einfachsten Fall hatte fünf Beteiligte.
Dazu die schönste Ironie des Vorhabens: Das offizielle Bestellformular-System des Konzerns hätte für unsere Anforderung 6 bis 12 Monate Entwicklungszeit gebraucht — Erfahrungswert aus anderen Abteilungen. Für ein Formular. Wir haben stattdessen eine Landingpage mit eigenem Order-Flow gebaut, weil das der einzige Weg war, in diesem Quartal überhaupt etwas auszuliefern.
Die Zahlen dazu sind aufschlussreicher als jede Architekturdiskussion:
- Lag die Genehmigung vor, war ein Space in zwei Tagen bereitgestellt.
- Die Genehmigung selbst konnte bis zu 30 Tage dauern — weil sie Kosten auslöst und deshalb einen kaufmännischen Freigabepfad durchläuft.
- Brachte ein Team seine eigene Umgebung mit, war die Sache in Minuten erledigt.
Im ungünstigsten Fall lag der technische Anteil an der Gesamtwartezeit damit bei rund sechs Prozent. Alles andere war Freigabe, Abstimmung und Formular.
Das ist die unbequemste Zahl des Vorhabens — und sie hat die spätere Architekturdiskussion stärker beeinflusst als jedes Werkzeug. Denn sie zeigt zweierlei: Plattformarbeit erzielt ihre Wirkung nicht in schnellerer Provisionierung, sondern im Wegfall von Schritten. Und: Der schnellste Weg zu einer laufenden Umgebung war der, bei dem die Plattform gar nichts provisionierte, sondern nur delegierte. Genau dieser Gedanke wurde später zum Kern der Architektur.
Noch etwas kam dazu: Wir haben uns die Bestandszahlen angesehen und festgestellt, dass praktisch jeder Kunde, den wir onboarden wollten, die Voraussetzungen auf beiden Zielplattformen längst hatte. Das Onboarding-Problem, an dem wir Monate gearbeitet hatten, war in weiten Teilen selbst konstruiert. Wenn alle relevanten Zielinformationen bereits validiert, genehmigt und vorhanden sind, braucht man kein Onboarding-Szenario. Man braucht eine Abfrage.
Bevor man einen Prozess automatisiert, muss man prüfen, ob er überhaupt stattfinden muss. Automatisierung macht überflüssige Schritte nur schneller überflüssig.
Wir haben die falsche Sorte Software gebaut
Nach etwa einem Jahr hatten wir etwas Lauffähiges. Es tat, was wir ihm gesagt hatten. Und genau das war das Problem.
Was wir gebaut hatten, war ein prozeduraler Ablaufmotor: eine Kette definierter Schritte, die in definierter Reihenfolge definierte Dinge anlegte. Für jeden neuen Anwendungsfall musste ein neuer Ablauf geschrieben werden. Keine Zustände, die das System selbst wiederherstellen konnte, keine Zielumgebungen, die es selbst auswählte, keine Fähigkeiten, die es generisch anbieten konnte.
Ein Orchestrator, der nur statisch ist, ist kein Orchestrator. Er ist Automatisierung mit besserem Namen.
Die unbequemere Erkenntnis lag daneben: Wir hatten den Begriff Platform Orchestrator falsch verstanden. Wir dachten in Workflows — Schritt A, dann B, dann C. Tatsächlich nimmt ein Platform Orchestrator eine Absichtserklärung entgegen („dieses Team braucht diese Fähigkeit”) und sorgt kontinuierlich dafür, dass die Welt diesem Zustand entspricht. Ein anderes Paradigma.
Der teuerste Fehler ist der, der sich zwei Jahre lang wie Fortschritt anfühlt.
Diesen Fehler nehme ich auf meine Kappe. Er war fachlich, er war meiner, und ich habe ihn zu spät gesehen.
Die Evaluierung: fünf Produkte, ein Kriterienkatalog
Was folgte, ist der Teil, auf den ich rückblickend am meisten stolz bin — nicht wegen des Ergebnisses, sondern wegen der Art, wie es zustande kam. Ich habe die Entscheidung nicht als PO verkündet. Wir haben als Team evaluiert.
KubeVela — technisch interessante Ergebnisse, aber das Projekt wirkte nicht aktiv gepflegt, die Dokumentation reichte für ernsthaftes Troubleshooting nicht aus, und wir konnten keinen Partner identifizieren, der uns im Ernstfall kommerziell unterstützt. Für eine Komponente im Zentrum einer Konzernplattform war das Governance- und Supportrisiko zu hoch.
Humanitec — teuer. Reine SaaS-Lösung. Das Setup wirkte in der Ersteinschätzung sehr komplex, und der Support während der Proof-of-Concept-Phase war bestenfalls mittelmäßig. Wenn ein Anbieter schon im Verkaufsprozess nicht liefert, ist das ein belastbares Signal.
Spacelift — solides Produkt, aber nicht für unsere Zielgruppe gebaut. Es adressiert nicht Application Engineers, sondern ist im Kern ein Wettbewerber zu Terraform Cloud/Enterprise mit Fokus auf IaC-Automation-Management. Das ist etwas anderes als Orchestrierung. Zusätzlich SaaS und technologisch stark an Terraform gebunden.
Crossplane — der stärkste Alternativkandidat. Sehr aktive Community, große Fähigkeitsbreite, breite Marktakzeptanz. Was uns davon abgehalten hat, war ehrlicherweise nicht das Produkt, sondern wir: Der konzeptionelle Zugang fiel uns schwer, und wir hatten niemanden, der uns in vertretbarer Zeit hindurchgeführt hätte.
Kratix — lieferte konzeptionell genau das, wonach wir gesucht hatten.
Warum Kratix — und warum das eine PO-Entscheidung war
- Technologieunabhängig in der Orchestrierung. Keine Bindung an ein einzelnes IaC-Werkzeug.
- On-Premises betreibbar. In unserem regulatorischen Umfeld kein Nice-to-have.
- Verständliches Konzept. Das Destinations-Modell war in einem Nachmittag erklärbar — bei Crossplane war es das für uns nicht.
- Backstage-Plugin verfügbar. Hartes Requirement, kein Wunsch.
- Kostenlose Proof-of-Value-Phase, gemeinsam mit dem Hersteller in unserer eigenen Infrastruktur. Kein Sandbox-Demo, sondern echte Umgebung, echtes Team, echte Systeme.
- Syntasso als Vendor. Das Know-how, das die Mannschaft dahinter in wenige Wochen eingebracht hat, hätten wir uns intern in Monaten nicht angeeignet.
Der letzte Punkt verdient Ehrlichkeit, weil er die eigentliche Entscheidungslogik offenlegt: Unser Kubernetes-Wissensstand war nicht besonders hoch. Ein Produkt zu wählen, das technisch vielleicht die reinere Lösung gewesen wäre, dessen Konzepte wir aber nicht in vertretbarer Zeit durchdringen konnten, wäre falsch gewesen — egal wie gut es auf dem Papier abschneidet.
Die Risiken haben wir offen benannt: Kratix war ein junges Projekt, Syntasso ein kleiner Anbieter. Dem gegenüber stand die Bereitschaft, gemeinsam mit uns am Produkt zu arbeiten — und die haben sie eingelöst.
Werkzeugwahl ist keine Benchmark-Übung. Das richtige Werkzeug ist das, mit dem dieses Team in dieser Zeit unter diesen Bedingungen liefern kann. Vendor-Support ist dabei ein Architekturkriterium, kein Einkaufsdetail.
Die Demo, die den Unterschied erklärt hat
Diese Präsentation habe ich oft gehalten, weil sie in fünf Minuten zeigt, was ein Platform Orchestrator eigentlich ist — und warum das etwas anderes ist als Automatisierung.
Der Aufbau: ein zentraler Platform Cluster. Zwei getrennte Kubernetes-Cluster als Destinations, die zwei unterschiedlichen Entwicklungsabteilungen gehören.
Schritt 1 — die Promise. Ich beschreibe einen nginx-Service als Promise. Eine Promise ist YAML und enthält vier Dinge: die API, über die ein Team den Service bestellen kann (technisch eine Custom Resource Definition), die Abhängigkeiten, die vorher auf dem Ziel liegen müssen, die Workflows, die bei Bestellung und über den Lebenszyklus laufen, und die Destination-Regeln — also wohin überhaupt ausgeliefert werden darf.
Schritt 2 — die Bestellung. Beide Abteilungen fordern den Service an. Der nginx läuft auf beiden Clustern. Bis hierhin ist das reine Provisionierung. Das kann jedes Skript, und genau das hatten wir vorher selbst gebaut.
Schritt 3 — der eigentliche Punkt. Ein Security-Patch. Ich ändere ihn einmal, in der Promise, auf dem Platform Cluster. Kratix reconciled daraufhin die Promise und lässt die Configure-Workflows für alle bestehenden Ressourcen erneut laufen. Beide Cluster bekommen den Patch.
Kein Ticket. Keine Migration durch die Teams. Keine Liste, in der jemand pflegt, wer welche Version fährt.
Ob es ein Security-Patch ist, eine Policy, ein Basis-Image oder eine Compliance-Vorgabe, ist an dieser Stelle völlig egal. Der Mechanismus ist derselbe. Das ist Fleet Management: Man pflegt das Angebot, nicht die Installationen.
„Aber ein zentraler Knopf für alles ist im Konzern kein Feature, sondern ein Risiko”
Dieser Einwand kam in jeder Demo, und er ist berechtigt. Unterschiedliche Abteilungen haben unterschiedliche Freigabeprozesse, Wartungsfenster und Auditpflichten. Ein Rollout, der überall gleichzeitig durchschlägt, wäre im Konzern nicht einsetzbar.
Dafür gibt es zwei Mechanismen:
Destination-Selektoren. Jede Destination trägt ganz normale Kubernetes-Labels — environment: dev, zone: eu, was immer man modellieren will. Die Promise legt über destinationSelectors fest, welche Labels ein Ziel tragen muss, damit es beliefert wird. Ein Rollout läuft damit nur dort, wo er laufen soll.
Versionierung über Promise Revisions. Ändert man nicht nur den Inhalt, sondern die Promise-Version, legt Kratix eine neue Revision an. Neue Anfragen bekommen automatisch die aktuelle Version; bestehende Ressourcen bleiben auf ihrer Revision, bis sie bewusst hochgezogen werden. Genau daran kann der Freigabeprozess einer Abteilung hängen.
Das Ganze ist durchgehend deklarativ und GitOps-basiert. Der Platform Cluster schreibt die gewünschten Dokumente in einen State Store — ein Git-Repository oder einen Bucket — und auf den Zielclustern zieht ein GitOps-Agent wie Flux oder ArgoCD sie und wendet sie an. Es gibt keinen Push-Kanal in die Zielumgebung hinein, keine Zugangsdaten, die die Plattform vorhalten müsste, und keinen Zustand, der nur im Kopf des Betriebs existiert.
Der Vorbehalt, den ich nicht auflösen konnte
Ein ehrlicher Einwand gehört dazu: Diese Labelsysteme sind Individualentwicklung. Man modelliert die Freigabe-, Wartungs- und Verantwortungslandschaft eines Konzerns in ein selbstgebautes Schema aus Schlüssel-Wert-Paaren. Technisch funktioniert das hervorragend. Die Frage ist, ob man Individualentwicklung vor die Enterprise-Prozesse setzen will — oder ob man zuerst die Prozesse ordnen müsste.
Wir haben diese Frage nie zu Ende diskutiert. Aber ich habe eine Antwort darauf gefunden, und sie ist die wichtigste Erkenntnis, die ich aus dem gesamten Thema mitnehme.
Die eigentliche Erkenntnis: Es fehlt eine Rolle
Die Frage nach Individualentwicklung gegen Enterprise-Prozess ist gar nicht technisch zu beantworten. Sie ist eine Rollenfrage.
Ein zentrales Team kann und soll die operative Basis stellen: die Umgebung, den Platform Cluster, die zentrale Steuerung, die Architekturvorgaben und die Wartung dieser zentralen Plattform. Das ist Betrieb, und dafür ist eine operative Einheit richtig aufgestellt.
Was ein zentrales Team nicht leisten kann, ist das Schreiben der Blueprints — der Golden Paths, der Templates, der Promises. Dafür braucht es jemanden, der zwischen zwei Welten steht: auf der einen Seite die zentralen Artefakte und deren Aktualisierungen, auf der anderen die individuellen Bedürfnisse der Entwicklungsbereiche. Jemand, der pragmatisch entscheidet, wo ein individueller Prozess sinnvoll ist und etabliert werden muss — und wo nicht.
Diese Rolle heißt Platform Engineer, und es kann sie in mehreren Ausprägungen geben. Uns hat sie gefehlt. Nicht als Skill — als besetzte Position mit Auftrag.
Platform Engineering ist Standardisierung, nicht Werkzeug
In einem Großkonzern müsste das auf hoher Ebene etabliert werden: Promises, deren Nutzung verbindlich ist. Abweichungen bleiben möglich — aber sie müssen begründet werden. Wer aus der Reihe tanzt, trägt die Beweislast, nicht der Standard.
Ein Beispiel, das den Punkt greifbar macht. Nimm zwei Bereiche desselben Konzerns:
- Einen sicherheitskritischen Automotive-Bereich, der am Insassenschutz arbeitet — etwa an der frühzeitigen Erkennung von Stauenden, die in den Regelalgorithmus eines autonom fahrenden Fahrzeugs einfließt.
- Ein Team, das eine Webanwendung baut.
Für beide spielen SaaS-Dienste eine Rolle. Beide brauchen irgendwann etwas so Banales wie einen gehosteten nginx. Aber sie entwickeln unter vollständig unterschiedlichen Prozessen und Qualitätsanforderungen.
Ein einheitlicher, standardisierter Weg für dasselbe technische Ergebnis wird von beiden Gruppen deshalb völlig unterschiedlich wahrgenommen:
- Die Automotive-Gruppe freut sich: Ein hochgradig komplizierter Prozess mit allen erforderlichen Schritten, Nachweisen und Qualitätssicherungen ist plötzlich Standard — und läuft automatisiert.
- Die Web-Gruppe empfindet genau denselben Prozess als Overhead.
Und genau hier liegt der Kompromiss, den Platform Engineering überhaupt erst möglich macht: Wenn die Automatisierung den Weg für beide Gruppen ausreichend beschleunigt, akzeptiert auch das Produkt mit den geringeren Anforderungen den strengeren Prozess. Nicht weil es muss, sondern weil er schneller ist als der eigene.
Das ist die eigentliche Leistung einer Plattform. Nicht: jedem geben, was er will. Sondern: den strengsten sinnvollen Standard so schnell machen, dass niemand mehr einen Grund hat, ihn zu umgehen.
Warum wir das nicht liefern konnten
Diese Erkenntnis kam mit einer unbequemen Konsequenz.
Wir waren eine operative Einheit. Das Maximum, das wir beitragen konnten, war die Bereitstellung der Toolkette sowie Onboarding und Trainings für die Kunden, die diese Technologie später nutzen. Die Blueprints und vor allem die Verbindlichkeit hätten von woanders kommen müssen.
Ohne eigene Kunden wäre die sinnvolle Maßnahme gewesen, das Thema auf Konzernebene verstanden zu bekommen und eine Plattformgruppe mit dem politischen Mandat auszustatten, es als Standardverfahren durchzusetzen. In einer Organisation mit mehr als 500.000 Mitarbeitern muss ein solches Thema dafür hoch genug getrieben werden. Als Product Owner einer operativen Abteilung ist die Etablierung eines solchen Standards unendlich schwierig: Die Zahl der Führungsebenen, die man durchdringen müsste, ist groß, und auf jeder davon kommen eigene Interessen dazu.
Das ist keine Ausrede. Es ist die präzise Beschreibung dessen, was mir gefehlt hat und was ich aus meiner Position heraus auch nicht hätte herstellen können: Mandat.
Warum Day 2 der eigentliche Wert ist
Provisionierung ist der einfache Teil. Sie ist die Kennzahl, über die alle reden, und sie ist die, die man in einer Vorstandsrunde zeigen kann.
Der schwierige Teil ist Day 2: einen einmal ausgelieferten Standard über Jahre weiterzuentwickeln, ohne die Organisation jedes Mal anzuhalten. Sicherheitsvorgaben ändern sich. Basis-Images laufen aus. Policies kommen dazu. Wer das über Tickets und Migrationsprojekte löst, hat keine Plattform, sondern einen Dienstleister mit Backlog.
Unser selbstgebauter Orchestrator konnte Tag 1. Für Tag 2 hatte er nicht einmal ein Modell.
Und trotzdem: die Umgebung wurde nie eingesetzt
Innerhalb weniger Wochen standen wir dort, wo wir in zwei Jahren Eigenentwicklung nicht hingekommen waren: eine produktionsreife Umgebung inklusive Onboarding-Szenario, die der Organisation hätte angeboten werden können.
Verhindert hat den Einsatz nicht die Technik, sondern eine Kombination aus fünf Faktoren, die ich für typisch halte, wenn ein kleines Werkzeug auf einen großen Konzern trifft:
- Lizenzverhandlungen. Die anfänglich veranschlagten Kosten lagen hoch.
- Vendor-Onboarding. Ein kleiner Anbieter durchläuft denselben Beschaffungs- und Regulatorikpfad wie ein Milliardenkonzern — mit demselben Aufwand, aber ohne dessen Apparat.
- Unsicherheit über die Kundenakzeptanz. Würden interne Teams mit Kratix arbeiten wollen statt mit dem bekannteren Crossplane? Wir konnten es nicht belegen — und Unsicherheit schlägt in Entscheidungsgremien fast immer die Argumente.
- Fehlende Trägerschaft. Portal-, Operations- und Monitoring-Teams hatten mit dem Thema Orchestrierung wenig Berührungspunkte. Eine Lösung, die nur ein Team versteht, wird nicht eingeführt — egal wie gut sie ist.
- Feature-Überlappung mit dem Portal. Dass zwei Komponenten scheinbar dasselbe konnten, machte jede Abgrenzung erklärungsbedürftig — und Erklärungsbedarf kostet in solchen Prozessen mehr als Funktionslücken.
Ich bin bis heute vom Konzept des Platform Orchestrators überzeugt. Ich halte die Entscheidung für Kratix nach wie vor für richtig. Beides hat nichts geändert.
Sieben Reboots
Über die Laufzeit hat sich das Vorhaben etwa sieben Mal grundlegend neu ausgerichtet. Mal Fokus hierhin, mal dorthin. Jedes Mal mit guten Argumenten, jedes Mal von Leuten, die es ernst meinten.
Das ist der Punkt, den ich vorher nicht auf dem Schirm hatte: Veränderung ist kein Fortschritt. Wenn die Richtungsänderung nicht die richtige ist, hilft sie nicht — sie kostet nur zusätzlich. Und sie kostet doppelt, weil jede Neuausrichtung die Lernkurve zurücksetzt und nach außen signalisiert, dass man immer noch nicht weiß, was man tut.
Nach drei Jahren war das der eigentliche Schaden: Glaubwürdigkeitsverlust. Nicht bei den Kunden — die kannten uns kaum. Sondern in der eigenen Organisation. Ab einem gewissen Punkt glaubt niemand mehr, dass man das Ding noch reißt. Und dieser Punkt kommt früher, als man denkt.
Der Portal-Schwenk
Irgendwann fiel die Entscheidung, das selbstgebaute Portal aufzugeben und auf ein kommerziell gemanagtes Backstage zu wechseln. Der Anbieter war Roadie; wir haben das Self-Hosting bewusst nicht selbst betrieben.
Ich bekam die Enterprise-Fragen nicht beantwortet, die für ein Konzernumfeld nicht verhandelbar sind: Multi-Tenancy. Audit-Logs. Konnektivität. Dazu ein Plugin-Ökosystem, das für die verschiedenen Dienste nicht homogen umgesetzt ist — Backstages größtes Verkaufsargument und gleichzeitig sein größtes Risiko. Die meisten Plugins sind nicht enterprise-ready, decken jeweils nur einen Ausschnitt ab und sind untereinander nicht konsistent. Wer eine Plattform darauf gründet, gründet sie auf eine Sammlung, nicht auf ein System.
Für ein kleineres Team mit überschaubarer Zielumgebung ist Backstage plus CI/CD völlig ausreichend — das würde ich jederzeit empfehlen. Für eine Plattform, die viele Kunden und viele Zielumgebungen tragen soll, ist es das nicht.
Und die Optik war das eigentliche Problem: Zwei Jahre Eigenentwicklung einstellen, um einen SaaS-Dienst anzubieten — das ist intern schwer zu erklären.
Ich wollte an den Kunden
An dieser Stelle kam eine Umstrukturierung, an der ich selbst mitgewirkt habe. Ich habe den Orchestrator abgegeben und Customer Experience & Engineering übernommen.
Der Grund war nicht Resignation. Ich hatte die Überzeugung: Wenn wir so weitermachen wie bisher, bauen wir noch einmal zwei Jahre an etwas, von dem ich nicht weiß, ob es irgendjemandes Problem löst. Mit CXE hatte ich die Möglichkeit, endlich direkt an den Kunden zu kommen. Wir hatten ja keine — der erste Fokus war deshalb überhaupt erst Kundenakquise.
Was wir dann gebaut haben, ist das Einzige aus drei Jahren, das ich uneingeschränkt als Ergebnis bezeichne — auch wenn es kein Produkt war, sondern ein Verfahren.
Wir haben die Proof-of-Value-Phase, die wir selbst beim Vendor erlebt hatten, für unsere eigene Situation nachgebaut. Eine kostenlose Kampagne, mehrwöchige Begleitung, klar gegliedert:
- Phase 1, maximal zwei Wochen: Kleinschulungsprogramm. Der Kunde lernt die grundsätzlichen Funktionalitäten des Produkts kennen.
- Phase 2, zwei bis vier Wochen: Hands-on mit Daily. Die Problemfelder des Kunden waren im Vorfeld identifiziert worden; wir haben versucht, sie gemeinsam abzubilden. Der Kunde konnte meine Teammitglieder für alles nutzen — Meinung einholen, Empfehlungen, Infrastrukturprobleme lösen, Entwicklungsaufgaben delegieren oder gemeinsam entwickeln.
- Abschlusswoche: Alle Ressourcen in eine gemeinsame Auswertung, ehrlich, mit Ergebnis.
Dazu haben wir KI-generierte Trainingsvideos erstellt, um die Erfahrung später skalieren zu können, und das gesamte Kunden-Onboarding in diesen Prozess hinein aufgebaut — von der Akquise über die POV-Phase bis zur späteren Buchung und Bereitstellung.
Das Ergebnis: Das Produkt hat keinen einzigen Kunden überzeugt. Für den Prozess haben wir viel Lob bekommen.
Das ist kein Trostpreis. Ein wiederholbares Verfahren, mit dem man ein Produkt ehrlich am Kunden prüft, ist genau das, was in den zwei Jahren davor gefehlt hat. Wir hatten es nur zu spät und für das falsche Produkt.
Was ich nicht mitgedacht hatte
Hier liegt mein zweiter eigener Fehler, und er wiegt schwerer als der erste.
Ich habe die Frage nach dem Kunden gestellt. Ich habe die Frage nach dem Markt nicht gestellt.
Wir haben ein kostenpflichtiges Plattformprodukt in eine Phase hinein angeboten, in der die gesamte Organisation Kosten abbaute und maximal sparte. Etwas Neues zu verkaufen ist schon schwer genug, wenn es kostenlos ist. Mit einem Angebot aufzukommen, das zusätzliche Kosten verursacht, während jeder Bereich seine Ausgaben rechtfertigen muss — das war strukturell aussichtslos, und es war absehbar.
Was ich stattdessen hatte, war Hoffnung. „Es wird schon irgendwie laufen.” Das ist keine Strategie, das ist ein Gefühl mit Roadmap.
Ein technologisch richtiger Ansatz ist noch kein tragfähiges Geschäftsmodell. Diese beiden Dinge habe ich jahrelang nicht sauber getrennt.
Wie es ausgegangen ist
Das Vorhaben hat angefangen, sich selbst abzubauen. Von ursprünglich rund 30 Leuten wurde bei der Umstrukturierung auf 17 reduziert, danach ging es weiter — Menschen, die von Anfang an dabei und längst enttäuscht waren, sind ausgestiegen. Andere Länder haben sich zurückgezogen. Zuletzt waren sechs übrig.
Und diese sechs waren im Wesentlichen mein Team.
Das ist die eine Zahl aus diesen drei Jahren, auf die ich wirklich stolz bin. Von dreißig auf sechs — und die sechs, die geblieben sind, waren die, die zufrieden waren. In einem Umfeld, in dem alle anderen das Vertrauen verloren hatten, ist mein Team zusammengeblieben. Retention ist in einem demoralisierten Programm keine weiche Kennzahl. Sie ist die härteste, die es gibt.
Am Ende wurde das Vorhaben mit meiner Gruppe in ein anderes, bereits erfolgreich etabliertes Produkt überführt — eine Cloud-Zugangsplattform, die auf einem Hyperscaler aufsetzt und mit unternehmensspezifischen Diensten umgeben ist. Ein Produkt, das funktioniert, weil es das Richtige anbietet: den Compliance-konformen Weg für Entwickler in die Cloud, zu einem Zeitpunkt, an dem sich die gesamte Entwicklung vom On-Premises-Ansatz dorthin verschoben hat. Ein No-Brainer, den die Verantwortlichen zusätzlich sauber und kostenseitig überzeugend in der Organisation platziert haben.
Man kann daraus alles lernen, was in unserem Vorhaben gefehlt hat: Es gab einen Bedarf. Es gab einen Zwang. Es gab ein Kostenmodell, das jemand tragen wollte.
Und dann die Frage, die mir am häufigsten gestellt wird: Warum bin ich nicht früher gegangen?
Ich bin geblieben, weil ich an das Team geglaubt habe, das ich gebaut hatte. Weil ich lange überzeugt war, dass der nächste Schritt der richtige sein könnte — Kratix, später ein umfassenderes Produkt wie Harness, für das ich zuletzt argumentiert habe, weil ich dort alles vertreten sah, was wir brauchten. Auch daraus wurde nichts, und selbst wenn, wäre es erneut an den Lizenzkosten gescheitert.
Rückblickend hätte ich früher gehen und mich gegen praktisch jede Richtungsentscheidung stellen müssen. Ich habe es nicht getan.
Die Entscheidung ist dann für mich getroffen worden.
Das eigentliche Learning
Wenn ich aus drei Jahren einen Satz mitnehme, dann diesen:
Es ist ein gewaltiger Unterschied, ein Problem zu erkennen — und die Rahmenbedingungen so zu verändern, dass es gelöst wird.
Ich war gut im ersten Teil. Ich habe früh gesehen, dass der Kunde fehlt, dass das Paradigma falsch ist, dass Eigenentwicklung nicht trägt, dass das Portal die Enterprise-Fragen nicht beantwortet. Jede dieser Diagnosen war richtig, und die meisten waren früher richtig als der Rest der Organisation.
Es hat nichts genützt. Erkenntnis ohne die Fähigkeit, den Rahmen zu verändern, ist folgenlos. Und — das ist die zweite, unbequemere Hälfte — selbst die Fähigkeit garantiert nichts. Auch die richtige Absicht und die richtige Entscheidung bewirken nicht zwangsläufig das richtige Ergebnis. Es gibt Rahmen, die man nicht bewegen kann. Dann bleibt nur, das rechtzeitig zu erkennen und die Konsequenz zu ziehen.
Man kann nur so erfolgreich sein, wie die Rahmenparameter es zulassen. Das klingt fatalistisch. Es ist das Gegenteil: Es ist die Aufforderung, die Rahmenparameter zu prüfen, bevor man drei Jahre investiert.
Die zehn Fragen, die ich heute stelle
Das ist der Teil, der mir tatsächlich etwas wert ist. Bevor ich heute in ein Plattformvorhaben einsteige — als PO, als Lead, als Mitarbeiter — will ich diese Fragen beantwortet haben. Nicht ausweichend, sondern konkret.
1. Wer hat das Problem? Namentlich. Nicht „die Entwickler”. Nicht „das Unternehmen”. Ein Team, eine Abteilung, ein Mensch mit einem Namen und einem Kalendereintrag.
2. Was passiert bei diesem Kunden, wenn wir nichts bauen? Wenn die Antwort „nichts Schlimmes” lautet, gibt es kein Problem — es gibt eine Idee.
3. Was kostet ihn die Lösung, und aus welchem Budget? Ein internes Produkt ohne geklärtes Kostenmodell ist kein Produkt. Es ist eine Kostenstelle mit Roadmap. Und in einer Sparphase ist es tot, bevor es startet.
4. Wann benutzt der erste Kunde das erste Inkrement produktiv? Nicht: wann ist Go-live. Wann tippt zum ersten Mal jemand echte Arbeit hinein. Liegt die Antwort mehr als ein paar Monate in der Zukunft, ist das Vorhaben ein Versprechen, kein Produkt. Agil zu arbeiten heißt nicht, in Sprints zu planen. Es heißt, Inkremente zu liefern, die der Kunde früh tatsächlich verwendet, zu denen er Feedback gibt und die er ab einem Punkt in seine tägliche Arbeitsroutine integriert. Alles andere ist Wasserfall mit Standup.
5. Gibt es einen Zwang oder eine politische Welle? Freiwillige Adoption interner Plattformen ist die Ausnahme, nicht die Regel. Entweder die Geschäftsführung verpflichtet die Nutzung, oder der Kunde arbeitet von Anfang an mit daran, weil er es sowieso braucht. Ohne eines von beidem baut man in den luftleeren Raum.
6. Wer schreibt die Blueprints — und ist diese Rolle besetzt? Ein zentrales Team kann die Plattform bauen und betreiben. Die Golden Paths, Templates und Promises schreibt jemand anderes: Platform Engineers, die zwischen zentralem Standard und den Bedürfnissen der Bereiche vermitteln und entscheiden, wo Individualität gerechtfertigt ist. Fehlt diese Rolle, entsteht entweder ein Standard, den niemand benutzt, oder ein Wildwuchs, den niemand pflegt.
7. Bauen wir für einen Bedarf oder für eine Vermutung — und woran würden wir merken, dass wir falsch liegen? Wenn es kein Kriterium gibt, an dem das Vorhaben scheitern darf, gibt es auch keines, an dem es gelingen kann.
8. Trägt die Fachabteilung mit, die es später betreiben soll — oder lernt sie noch? Eine Organisation, die parallel das Produkt baut, die Technologie lernt und die Anforderungen erst formuliert, hat drei Unbekannte in einer Gleichung. Das ist machbar, aber es ist ein Risiko, das man benennen und einplanen muss statt es zu übersehen.
9. Ist der technologische Ansatz auch ein Geschäftsmodell? Technisch richtig und wirtschaftlich tragfähig sind zwei verschiedene Prüfungen. Beide müssen bestanden werden.
10. Was ist der Abbruchpunkt — und wer darf ihn aussprechen? Das ist die Frage, die in unserem Vorhaben nie jemand gestellt hat, und sie ist die wichtigste. Sieben Neuausrichtungen waren möglich, weil niemand befugt und niemand bereit war zu sagen: Es reicht.
Zum Schluss
Ich habe lange gebraucht, um diesen Text schreiben zu können, ohne dass er entweder nach Rechtfertigung oder nach Abrechnung klingt. Beides wäre falsch.
Die Menschen in diesem Vorhaben waren kompetent und haben es ernst gemeint. Die Entscheidungen wurden nicht leichtfertig getroffen. Die Idee war nicht dumm. Und trotzdem sind drei Jahre vergangen, ohne dass am Ende jemand etwas in der Hand hatte.
Das ist keine Geschichte über Schuld. Es ist eine Geschichte über Rahmenbedingungen — und darüber, dass die Prüfung dieser Rahmenbedingungen keine Vorarbeit ist, die man nach dem Kickoff abhakt. Sie ist die Arbeit.
Ich bin nach wie vor überzeugt vom Konzept des Platform Orchestrators. Ich würde die Entscheidung für Kratix wieder treffen. Ich würde das Team wieder so bauen.
Was ich anders machen würde: Ich würde die zehn Fragen stellen, bevor ich zusage. Und wenn sie unbeantwortet bleiben, würde ich das als Antwort werten.