Platform Engineering Beratung
Foliensatz zur Plattformstrategie — Wir bauen die Plattform mit eurem Team und übergeben sie in den Betrieb.
Beratung und Umsetzung für Teams, deren Auslieferung an der eigenen Plattform hängt: Internal Developer Platform, CI/CD und Kubernetes-Betrieb. Wir bauen mit und übergeben, statt nur zu empfehlen.
Wir arbeiten in eurem Repository, in eurem Cluster, mit euren Reviews. Das Mandat endet, wenn euer Team die Plattform ohne uns ändert — nicht, wenn ein Dokument abgenommen ist.
FIT-CHECK BUCHENWarum Plattformarbeit stecken bleibt
Plattformarbeit scheitert selten an der Technik. Sie scheitert daran, dass niemand sie zu Ende bringt: Das Team hält den Betrieb am Laufen, und die Plattform bleibt das Projekt für später.
Was bleibt, ist eine halbfertige Zwischenschicht. Skripte, die eine Person kennt. Pipelines, die in jedem Team anders aussehen. Ein Cluster, an dem niemand mehr etwas ändern möchte.
Jede Woche in diesem Zustand kostet Liefergeschwindigkeit — und zwar bei allen Teams gleichzeitig, weil alle denselben Weg in die Produktion nehmen.
Woran ihr es im Alltag merkt
Sechs Situationen, die wir in Plattformprojekten regelmäßig antreffen. Je mehr davon zutrifft, desto weniger hilft eine weitere Zielbild-Diskussion.
- Ein neuer Service braucht Wochen bis zur Produktion. Der größte Teil davon ist Warten auf Infrastruktur, nicht Entwicklung.
- Jedes Team beschreibt seine Infrastruktur anders. Der Wechsel zwischen zwei Repositories fühlt sich an wie der Wechsel zwischen zwei Firmen.
- Das Plattform-Team arbeitet eine Ticketliste ab, statt Self-Service zu bauen. Die Liste wird trotzdem länger.
- Ein Cluster-Upgrade wird verschoben, weil niemand sagen kann, was danach nicht mehr läuft.
- Onboarding heißt: Jemand richtet die Entwicklungsumgebung persönlich ein. Eine Anleitung dafür gibt es nicht.
- Eine Developer Platform wurde begonnen, und niemand entscheidet, ob sie fertig gebaut oder wieder abgeschaltet wird.
Was danach anders ist
Kein Zielbild, sondern Zustände, die am Ende entweder eingetreten sind oder nicht. Sie sind gemeinsam mit eurem Team überprüfbar.
- Ein Team bringt einen neuen Service in Produktion, ohne dafür ein Ticket beim Plattform-Team zu öffnen.
- Infrastruktur ist deklarativ beschrieben und wird über denselben Weg ausgerollt wie Anwendungscode.
- Ein Cluster-Upgrade ist ein geplanter Vorgang mit Runbook, kein Risiko, das jedes Quartal weiterwandert.
- Neue Entwicklerinnen und Entwickler kommen über eine dokumentierte Umgebung zum ersten eigenen Deployment.
- Euer Team ändert die Plattform selbst — auch die Teile, die wir gebaut haben.
Welche dieser Zustände erreichbar sind, hängt vom Ausgangspunkt ab. Wir sagen vor dem Angebot, welche wir für nicht erreichbar halten, statt sie in den Vertrag zu schreiben.
Was enthalten ist
Der Weg vom Commit in die Produktion
Wir gehen die Auslieferungskette selbst durch und schreiben auf, welche Station wie lange dauert, wo sie wartet und wer eingreifen muss.
Internal Developer Platform
Self-Service für die Wege, die Teams täglich gehen: neuer Service, neue Umgebung, neues Deployment. Als Schnittstelle, die euer Team erweitern kann.
CI/CD und GitOps
Pipelines, die reproduzierbar bauen, und ein deklarativer Rollout-Weg, der denselben Stand in jeder Umgebung herstellt.
Kubernetes-Betrieb
Cluster-Aufbau und Betriebsvorbereitung: Upgrade-Pfad, Ressourcengrenzen, Zugriffsrechte und Runbooks für die Fälle, die nachts auffallen.
Observability
Metriken, Logs und Traces an einem Ort, verknüpft mit genau den Alarmen, auf die tatsächlich jemand reagiert.
Übergabe
Dokumentation, Pair Programming und ein Termin, an dem euer Team die Plattform ohne uns ändert. Danach endet die Zusammenarbeit.
So läuft eine Zusammenarbeit
Vier Schritte, in dieser Reihenfolge. Nach dem zweiten könnt ihr abbrechen und behaltet trotzdem ein Ergebnis, mit dem ihr weiterarbeiten könnt.
Fit-Check
Ein Gespräch über das, was gerade nicht funktioniert, und darüber, ob wir dafür die richtige Adresse sind. Wenn nicht, sagen wir es in diesem Termin.
Analyse
Wir sehen uns Repositories, Pipelines und Cluster selbst an und schreiben auf, welcher Engpass welchen Effekt auf die Liefergeschwindigkeit hat.
Umsetzung im Team
Jede Änderung geht über einen Pull Request, den jemand aus eurem Team liest. Wir arbeiten in euren Repositories, nicht neben ihnen.
Übergabe
Gemeinsame Betriebsübernahme, Dokumentation und eine Liste der Dinge, die wir bewusst nicht gebaut haben — mit Begründung.
Zusammenarbeitsmodelle
Vier Wege in die Zusammenarbeit. Welcher passt, entscheidet sich im Fit-Check; die Seiten dahinter nennen Umfang, Dauer und Preis im Detail.
Zuerst analysieren
Wenn noch nicht feststeht, woran es liegt: eine Analyse mit festem Umfang, die mit einer priorisierten Roadmap endet.
Zuerst stabilisieren
Wenn eine bestehende Plattform gerade Schaden anrichtet und vor jedem Umbau erst einmal Ruhe einkehren muss.
Plattform aufbauen
Wenn aus einer Kubernetes-Umgebung eine Plattform werden soll, die euer Team allein betreibt — mit festem Start- und Endtermin.
Laufende Begleitung
Begleitung über mehrere Monate mit festen Tagen pro Woche, wenn die Plattformarbeit dauerhaft eine erfahrene Hand braucht. Umfang und Laufzeit legen wir pro Fall fest.
Was ihr überprüfen könnt
Ehrlich gesagt: Auf dieser Seite steht keine Zahl aus einem Kundenprojekt. Was wir vorher gebaut haben, wurde nie so gemessen, dass es hier etwas belegen würde — und wir erfinden dafür keine Werte.
An dieser Stelle stünde eine Kennzahl. Es gibt keine: In keinem früheren Projekt wurde die Wirkung so gemessen, dass sie hier etwas belegen würde. Sobald ein Kunde eine Messung freigibt, steht sie hier — vorher nicht.
Referenzen
Woran wir gearbeitet haben, beschrieben ohne Kennzahlen, weil wir keine erhoben haben.
Liefermodell
Wer die Arbeit macht, wer sie liest und bei wem die Lieferverantwortung bleibt.
Fachartikel
Wie wir über Plattformen, Pipelines und Betrieb denken — öffentlich und in voller Länge nachlesbar.
Passende Fallstudien
Fallstudien zu dieser Leistung, mit Kontext, Eingriff und Übergabe. Jede erscheint erst, wenn der Kunde die Veröffentlichung schriftlich freigegeben hat.
Zu dieser Leistung ist noch keine Fallstudie veröffentlicht. Die erste ist in Arbeit und wartet auf die Freigabe des Kunden.
Was nicht enthalten ist
Der Umfang einer Zusammenarbeit ist erst klar, wenn auch die Gegenseite beschrieben ist. Diese vier Anfragen sagen wir in der Plattformarbeit regelmäßig ab — lieber vor dem Angebot als mitten im Projekt.
Rund-um-die-Uhr-Betrieb, Rufbereitschaft und SLA-gebundene Betriebsverantwortung
Wir bauen Plattformen und übergeben sie betriebsfähig. Den Betrieb selbst übernehmen wir nicht — das kann ein Managed-Service-Provider zusagen, wir nicht.
Zertifikate, Audit-Freigaben und Konformitätserklärungen
Die technische Umsetzung in Richtung ISO 27001, NIS2 oder AI Act gehört zur Arbeit. Das Testat ausstellen darf nur eine akkreditierte Prüfstelle — dafür braucht es einen Auditor, keinen Ingenieur.
Projekte ohne eigenes Entwicklungsteam
Wissenstransfer ist fester Bestandteil jeder Zusammenarbeit. Ohne Team, das übernimmt, wird daraus dauerhaftes Outsourcing — ein Modell, das wir nicht anbieten.
Festpreis für eine Gesamttransformation, bevor jemand hineingesehen hat
Eine ungeprüfte Legacy-Landschaft zu bepreisen ist Raten. Wir schätzen nach einer kurzen Analyse — und sagen auch, wenn sich der Umbau nicht lohnt.
Häufige Fragen zur Plattformberatung
Braucht es dafür ein eigenes Plattform-Team?
Ein eigenes Team ist nicht nötig, ein eigenes Entwicklungsteam schon. Wir übergeben die Plattform an Menschen, die sie danach ändern — ohne diese Menschen wird aus der Zusammenarbeit dauerhaftes Outsourcing, und das bieten wir nicht an.
Wir haben schon eine Plattform. Fangt ihr trotzdem von vorn an?
Nein. In den meisten Projekten existiert bereits ein Cluster, eine Pipeline und ein halbes Portal. Wir arbeiten damit weiter und bauen nur das neu, wofür wir einen Grund nennen können.
Wie stellt ihr sicher, dass unser Team die Plattform danach betreiben kann?
Durch die Arbeitsweise, nicht durch eine Schulung am Ende. Jede Änderung läuft über einen Pull Request aus eurem Team, Runbooks entstehen beim ersten Vorfall, und die Betriebsübernahme ist ein eigener Schritt im Projekt.
Arbeitet ihr auch mit Kubernetes-Alternativen?
Ja. Der größte Teil der Arbeit — Auslieferungsweg, Self-Service, Observability, Übergabe — ist unabhängig von der Laufzeitumgebung. Wo Kubernetes nicht die richtige Wahl ist, sagen wir das vor dem Angebot.
Wie schnell könnt ihr anfangen?
Wir führen nur wenige Projekte parallel, deshalb klären wir die Verfügbarkeit vor dem Angebot. Im Fit-Check nennen wir einen realistischen Starttermin, auch wenn er später liegt als gewünscht.
Was passiert, wenn die Analyse ergibt, dass die Plattform nicht das Problem ist?
Dann steht das im Ergebnis. Der Engpass liegt manchmal in der Zuständigkeit oder im Zuschnitt der Teams — und dafür ist ein Plattformprojekt die teuerste denkbare Antwort.
Ist die Plattform euer Engpass?
Ein Gespräch über den Zustand eurer Auslieferung — und eine ehrliche Einschätzung, ob wir dafür die richtige Adresse sind.