DevOps & Delivery

Platform Engineering im Mittelstand: Developer-Plattform ohne Plattform-Armee

Wie mittelständische Engineering-Organisationen mit 20–100 Entwicklern die Vorteile einer Internal Developer Platform realisieren, ohne ein 15-Personen-Plattform-Team zu finanzieren – mit Thinnest-Viable-Platform-Ansatz, Golden Paths für .NET und ehrlicher Kosten-Nutzen-Rechnung.

📖 9 Min. Lesezeit
Platform Engineering Internal Developer Platform Golden Path DevOps Team Topologies Developer Experience .NET Azure Backstage Mittelstand DORA-Metriken

Auf Konferenzen klingt Platform Engineering nach Spotify und Netflix: ein eigenes Plattform-Produkt, ein Developer-Portal mit Service-Katalog, ein 20-Personen-Team, das die "Developer Experience" orchestriert. Dann fährt der CTO eines Mittelständlers nach Hause zu seinen 45 Entwicklern, sechs Produktteams und einem Betriebsteam von drei Leuten – und legt das Thema als "nicht unsere Liga" zu den Akten.

Das ist die falsche Schlussfolgerung aus der richtigen Beobachtung. Die Konferenz-Variante von Platform Engineering ist für den Mittelstand tatsächlich überdimensioniert. Das zugrundeliegende Problem aber ist im Mittelstand genauso real wie bei den Tech-Giganten – oft sogar drängender: Produktteams verlieren einen erheblichen Teil ihrer Kapazität an undifferenzierte Infrastruktur-Arbeit. Jedes Team baut seine eigene Pipeline, löst Monitoring anders, verwaltet Secrets nach eigenem Geschmack und wartet auf das Betriebsteam, wenn eine neue Umgebung gebraucht wird. Multipliziert über sechs Teams ist das gelebte Verschwendung – und ein stilles Sicherheitsrisiko, weil sechs verschiedene Lösungen sechs verschiedene Lücken haben.

Dieser Artikel zeigt, wie Platform Engineering in einer Organisation mit 20–100 Entwicklern aussieht: welches Problem es löst, wie eine "Thinnest Viable Platform" konkret aufgebaut wird, was sie kostet und woran Sie messen, ob sie sich trägt.

Für wen dieser Artikel relevant ist: CTOs, Engineering-Manager und Lead-Architekten in mittelständischen Software-Organisationen – insbesondere im .NET/Azure-Umfeld –, die zwischen "jedes Team macht alles selbst" und "wir bauen ein Herkules-Plattform-Projekt" den tragfähigen Mittelweg suchen.

Das Problem hat einen Namen: Kognitive Last

Der theoretische Unterbau kommt aus Team Topologies: Ein Stream-aligned Team (Produktteam) soll seine kognitive Kapazität auf das Produkt richten – nicht auf Kubernetes-Manifeste, Pipeline-YAML und TLS-Zertifikate. Eine Plattform ist in diesem Modell kein Portal und kein Tool, sondern ein Mechanismus, der den Produktteams kognitive Last abnimmt, indem er die immer gleichen Infrastruktur-Entscheidungen einmal gut trifft und als Self-Service bereitstellt.

Im Mittelstand äußert sich das Fehlen einer solchen Plattform in wiederkehrenden Symptomen:

  • Neue Services dauern Tage bis Wochen, bis sie deploybar sind – nicht wegen der Fachlichkeit, sondern wegen Pipeline, Umgebungen, Berechtigungen und Monitoring-Anschluss.
  • Onboarding neuer Entwickler dauert Wochen, weil jedes Repository anders funktioniert.
  • Das Betriebsteam ist der Flaschenhals, durch den jede Umgebung, jede Firewall-Freigabe und jedes Zertifikat muss – klassisches Ticket-Ops.
  • Sicherheits- und Compliance-Standards divergieren, weil sie in jedem Team individuell (nicht) umgesetzt werden. Spätestens mit NIS2 wird aus dem Ärgernis eine Haftungsfrage.
  • Die DORA-Metriken stagnieren, obwohl die Teams fähig sind – die Reibung liegt zwischen den Teams und der Infrastruktur, nicht in ihnen.

Wenn Sie drei dieser fünf Symptome wiedererkennen, ist Platform Engineering für Sie kein Buzzword, sondern ein Hebel.

Thinnest Viable Platform: Klein anfangen, ernst meinen

Der Begriff stammt von Matthew Skelton und Manuel Pais und ist die wichtigste Leitplanke für den Mittelstand: die dünnste Plattform, die den Zweck erfüllt. Das kann am Anfang buchstäblich eine gut gepflegte Wiki-Seite mit verbindlichen Vorlagen sein. Entscheidend ist nicht die Technologie, sondern drei Eigenschaften:

  1. Self-Service: Ein Produktteam bekommt das Ergebnis (neuer Service, neue Umgebung, neues Dashboard) ohne Ticket und ohne Wartezeit.
  2. Golden Path statt Zwang: Die Plattform bietet einen bequemen, empfohlenen Weg ("goldener Pfad"), der die Standards einhält. Wer begründet abweichen will, darf das – trägt dann aber die Verantwortung selbst. Diese Freiwilligkeit ist der kulturelle Unterschied zwischen Plattform und Verbotsliste, und sie entscheidet über die Akzeptanz.
  3. Plattform als Produkt: Die Nutzer sind die eigenen Entwickler, und sie werden wie Kunden behandelt – mit Feedback-Schleifen, Roadmap und der ständigen Frage, was Adoption verhindert.

Für eine typische .NET/Azure-Organisation besteht die erste Ausbaustufe aus vier Bausteinen – wohlgemerkt ohne Developer-Portal, ohne Kubernetes-Pflicht, ohne neue Produktnamen:

Baustein Konkret Nutzen
Service-Template Ein dotnet new-Template bzw. Template-Repository: Projektstruktur, Logging, Health Checks, Auth-Anbindung, Dockerfile, fertige CI/CD-Pipeline Neuer Service in Stunden statt Tagen deploybar – mit Standards ab Zeile 1
Pipeline-Bibliothek Wiederverwendbare Pipeline-Bausteine (GitHub Actions Reusable Workflows / Azure DevOps Templates): Build, Tests, Scans, Deployment Eine Stelle für Qualitäts- und Security-Gates statt sechs Kopien mit Drift
Infrastruktur-Module Terraform-/Bicep-Module für die Standardfälle: Web-App mit Datenbank, Function mit Queue, inklusive Netzwerk, Identity und Alerting Umgebungen per Pull Request statt per Ticket – und auditierbar
Observability-Baseline Einheitliches Logging-Schema, vorgefertigte Dashboards und Alert-Regeln, die das Template automatisch anschließt Jeder Service ist ab dem ersten Deployment beobachtbar

Diese vier Bausteine adressieren erfahrungsgemäß 80 Prozent der Reibung – zu einem Bruchteil der Kosten eines Portal-Projekts.

Wer baut das? Das Plattform-Team in Mittelstandsgröße

Die Standardfrage: "Dafür haben wir doch kein Team." Die Antwort hängt von der Organisationsgröße ab:

  • Bis ~30 Entwickler: Kein dediziertes Team. Eine Plattform-Gilde aus zwei, drei erfahrenen Entwicklern mit explizit budgetierter Zeit (z. B. 20 Prozent) pflegt Templates und Module. Wichtig ist das Budget – eine Gilde, die Plattform-Arbeit "nebenbei" machen soll, macht sie nicht.
  • 30–80 Entwickler: Zwei bis drei Personen als dediziertes Plattform-Team, oft aus dem bisherigen Ops-/DevOps-Team heraus entwickelt. Das ist weniger eine Neueinstellung als eine Umwidmung: Dieselben Leute, die heute Tickets abarbeiten, bauen stattdessen die Self-Service-Wege, die die Tickets überflüssig machen.
  • Ab ~80 Entwicklern: Ein echtes Plattform-Team von drei bis fünf Personen mit Produkt-Verantwortung trägt sich in der Regel problemlos – hier lohnt dann auch die Diskussion über ein Portal wie Backstage. Vorher selten: Ein Portal ohne gepflegten Inhalt ist eine Fassade mit Wartungskosten.

Die kritischste Personalentscheidung ist nicht die Größe, sondern die Haltung: Das Plattform-Team braucht Produktdenken und Empathie für Entwickler-Workflows. Ein Plattform-Team, das Gatekeeper-Reflexe aus dem klassischen IT-Betrieb mitbringt, baut keine Plattform, sondern eine neue Genehmigungsinstanz mit besserem Tooling.

Die Ökonomie: Was es kostet und wann es sich trägt

Eine ehrliche Rechnung für eine Organisation mit 50 Entwicklern, konservativ gerechnet:

Kosten: Zwei Plattform-Ingenieure (voll zugerechnet) plus Werkzeugkosten – grob 250.000–300.000 € pro Jahr.

Gegenrechnung: Wenn jeder der verbleibenden 48 Entwickler durch Self-Service, Templates und wegfallende Eigenbau-Infrastruktur nur zwei Stunden pro Woche gewinnt – ein Wert, der in den meisten Organisationen deutlich übertroffen wird –, sind das über 4.800 Stunden im Jahr, umgerechnet etwa drei Vollzeit-Entwickler. Dazu kommen die schwerer bezifferbaren, aber realen Effekte: schnelleres Onboarding, weniger Incident-Zeit durch einheitliche Observability, auditierbare Compliance statt Team-Lotterie, und eine Delivery-Geschwindigkeit, die Produktinitiativen nicht mehr ausbremst.

Die Rechnung kippt allerdings ins Negative, wenn zwei Fehler gemacht werden: Überbau (ein Portal-Großprojekt vor den Grundlagen, Kubernetes ohne Not, Eigenentwicklung, wo Managed Services reichen) und Adoptionslosigkeit (die Plattform wird gebaut, aber die Teams nutzen sie nicht, weil sie an ihren Bedürfnissen vorbei entwickelt wurde). Beides sind Management-Fehler, keine Technologie-Fehler.

Messbarkeit: Woran Sie erkennen, dass es funktioniert

Platform Engineering zahlt direkt auf die DORA-Metriken ein – wenn Sie eine Baseline haben. Ergänzend haben sich drei plattformspezifische Kennzahlen bewährt:

  1. Time-to-First-Deployment: Zeit von "wir brauchen einen neuen Service" bis zum ersten Deployment in eine produktionsnahe Umgebung. Zielgröße mit Template und Pipeline-Bibliothek: unter ein Tag.
  2. Adoptionsquote der Golden Paths: Anteil der Services auf den Plattform-Vorlagen. Wächst diese Quote freiwillig, ist die Plattform gut; muss sie erzwungen werden, ist sie es nicht.
  3. Ticket-Volumen Richtung Ops: Die Menge der Infrastruktur-Tickets pro Monat. Diese Kurve soll sichtbar fallen – sie ist die direkteste Messung der Self-Service-Wirkung.

Dazu einmal pro Quartal eine kurze Entwickler-Umfrage zur Zufriedenheit mit den Plattform-Bausteinen. Nicht als Stimmungsbarometer, sondern als Produkt-Feedback: Die häufigste Beschwerde ist die nächste Roadmap-Position.

Ausblick: Die Plattform als Fundament für KI-Agenten

Ein Aspekt, der die Investition gerade zusätzlich verzinst: Alles, was eine gute Plattform ausmacht – Templates, einheitliche Pipelines, Self-Service-Infrastruktur, konsistente Konventionen – ist exakt das, was KI-Coding-Agenten produktiv macht. Ein Agent, der in einer standardisierten Codebasis mit dokumentierten Golden Paths arbeitet, liefert dramatisch bessere Ergebnisse als einer in sechs individuell gewachsenen Setups. Organisationen, die jetzt in Plattform-Grundlagen investieren, bauen gleichzeitig die Landebahn für die agentengestützte Entwicklung der nächsten Jahre. Umgekehrt gilt: Wer KI-Enablement ernst meint, kommt an Standardisierung nicht vorbei – die beiden Themen sind zwei Seiten derselben Investition.

Fazit

Platform Engineering im Mittelstand heißt nicht Backstage, Kubernetes und ein 20-Personen-Team. Es heißt: die immer gleichen Infrastruktur-Entscheidungen einmal gut treffen und als Self-Service verfügbar machen. Die Essenz:

  1. Startpunkt ist das Symptom, nicht das Tool. Ticket-Ops, langsames Onboarding und divergierende Standards sind das Problem – ein Portal zu kaufen löst keines davon.
  2. Thinnest Viable Platform: Service-Template, Pipeline-Bibliothek, Infrastruktur-Module, Observability-Baseline. Diese vier Bausteine zuerst, alles Weitere nach nachgewiesenem Bedarf.
  3. Golden Paths statt Zwang. Freiwillige Adoption ist die Qualitätsmetrik der Plattform. Wer Nutzung erzwingen muss, hat am Kunden vorbei gebaut.
  4. Plattform als Produkt mit budgetiertem Team – ob Gilde mit 20-Prozent-Budget oder zwei dedizierte Ingenieure, entscheidend ist die verbindliche Kapazität und das Produktdenken.
  5. Messen: Time-to-First-Deployment, Adoptionsquote, Ops-Ticket-Volumen, DORA-Trend. Was sich nicht bewegt, wird hinterfragt.

Der Mittelstand hat gegenüber den Tech-Giganten einen unterschätzten Vorteil: kurze Wege und überschaubare Systemlandschaften. Eine fokussierte Plattform-Initiative zeigt hier in sechs Monaten Wirkung, für die ein Konzern zwei Jahre braucht – wenn sie klein anfängt und ernst gemeint ist.

Nächste Schritte

← Zurück zu allen Publikationen