Es gibt einen Moment, in dem die meisten Mittelständler beim Thema Softwareentwicklung kurz innehalten. Es ist nicht der Moment, in dem die erste produktive Microservice-Architektur live geht. Es ist auch nicht der Moment, in dem das DevOps-Mantra "You build it, you run it" zum ersten Mal von einem Team gelebt wird. Es ist vielmehr der Moment, in dem das vierte oder fünfte Team genau dieselbe CI-Pipeline neu schreibt, dieselbe Kubernetes-Manifeste neu erfindet und dieselbe Frage – "Wo legen wir eigentlich Secrets ab?" – wieder im Architekturkreis landet. Spätestens dann ist der Punkt erreicht, an dem Platform Engineering vom Buzzword zum Geschäftsmodell wird.

2026 ist das Jahr, in dem dieser Punkt für sehr viele deutsche Mittelständler erreicht ist. Gartner prognostiziert, dass bis Ende 2026 rund 80 Prozent aller Software-Engineering-Organisationen ein dediziertes Plattform-Team unterhalten werden. Klingt nach Konzern-Realität – ist aber gerade im Mittelstand angekommen. Und es hat einen sehr konkreten Treiber: Generative KI in der Softwareentwicklung. Wer eine durchwachsene Plattform hat, dem helfen KI-Coding-Assistenten nicht – sie verstärken nur die bestehende Dysfunktion. Genau das hat der DORA-Report 2025 bestätigt und genau das beobachten wir bei pleXtec in Projekten quer durch den deutschsprachigen Mittelstand.

Dieser Artikel erzählt, warum Platform Engineering 2026 für Sie wichtig wird, was es konkret bedeutet, wo der Unterschied zu klassischem DevOps liegt – und vor allem: wie ein realistischer Einstieg aussieht, der nicht in der ersten Quartalsplanung schon stirbt. Wir folgen dabei der Geschichte eines fiktiven, aber sehr typischen Maschinenbau-Unternehmens.

Das Szenario: ein Mittelständler stolpert in seine Plattform-Krise

Die HollerMetall AG ist ein westfälischer Maschinenbauer mit 480 Mitarbeitenden, davon 38 in der hauseigenen IT. Das Unternehmen baut Sonderanlagen für die Lebensmittelindustrie und hat in den vergangenen Jahren viel in eigene Software investiert: ein internes Konfigurations-Tool für Vertrieb und Konstruktion, ein Kundenportal mit Service-Tickets und Maschinendokumentation, eine IoT-Plattform, die Telemetriedaten der ausgelieferten Anlagen sammelt, und drei kleinere Microservices, die zwischen ERP, MES und PLM vermitteln.

Ende 2024 hatte HollerMetall acht Entwickler in zwei Teams. Heute, im Frühjahr 2026, sind es 19 Entwickler in vier Teams plus eine zweiköpfige Operations-Truppe, die sich offiziell um Kubernetes, CI/CD und Cloud-Infrastruktur kümmert. Inoffiziell um alles, was sonst niemand will.

CTO Felix Bredemann hat in der letzten Vorstandssitzung eine Folie gezeigt, die die Gemüter erhitzt hat:

  • Bis zum ersten Deployment eines neuen Service: 27 Tage (Median über die letzten sechs Onboardings).
  • Anteil "infrastruktur-bedingter" Tickets im Entwicklungs-Backlog: 34 Prozent.
  • Anzahl unterschiedlicher Logging-Stacks im Haus: fünf.
  • Anzahl Wege, ein Secret in eine Pipeline zu bekommen: vier, davon drei dokumentiert.
  • Geplanter Rollout der neuen KI-Funktionen im Kundenportal: verschoben, weil das Team die Inferenz-Komponente nicht in den bestehenden Cluster bekommt, ohne den IoT-Dienst zu stören.

Bredemann hat keinen Wutausbruch gehalten. Er hat ruhig die Folie weggeblendet und einen Satz gesagt, den er aus einem Vortrag der KubeCon mitgebracht hatte: "Wir haben kein Talent-Problem, wir haben ein Plattform-Problem." Eine Woche später lag bei pleXtec eine Anfrage auf dem Tisch.

Was Platform Engineering wirklich ist (und was nicht)

Bevor wir HollerMetalls Reise weitererzählen: ein paar Begriffe, die in den Medien verwischt werden.

DevOps ist eine Kultur. Sie verschiebt Verantwortung in die Entwicklungsteams: Wer baut, der betreibt. Idealerweise. Realistisch endet das in Mittelstands-IT oft so, dass jedes Team seine eigene Pipeline baut, seine eigene Logging-Strategie wählt und am Ende vier Teams vier sehr ähnliche Probleme vier Mal lösen.

Platform Engineering ist die strukturelle Antwort darauf. Ein dediziertes Team baut eine Internal Developer Platform (IDP) – also eine eigene, organisationsspezifische Schicht oberhalb von Cloud-Anbieter, Kubernetes, CI-Tool und Co. Diese Schicht stellt den Entwicklungsteams Selbstbedienungs-Mechanismen bereit: einen Knopf, der eine neue Microservice-Vorlage produziert; ein YAML-Snippet, das Logging korrekt verdrahtet; einen Pull-Request-Bot, der einen Service in ein Backstage-Catalog einträgt.

Das, was diese IDP an Wegen anbietet, nennt man Golden Paths. Eine Golden Path ist die opinionated, vorab abgesegnete Route durch eine ansonsten komplexe Aufgabe. Beispiel: "Erzeuge einen neuen REST-Service in unserem Standard-Stack." Das, was bei HollerMetall heute 27 Tage dauert, soll am Ende ein idpctl create service sein, das in unter 30 Minuten ein einsatzfähiges Skelett liefert: Repository, Pipeline, Helm-Chart, Monitoring-Dashboard, Eintrag im Service-Katalog, Standard-IAM-Policies. Drei Klicks für die Standardfälle, weiterhin volle Freiheit für die echten Sonderfälle.

Der entscheidende Punkt: Platform Engineering ist kein Rebranding der alten Operations-Abteilung. Das alte Ops liefert Tickets ("wir richten Ihren Cluster ein"), das neue Plattform-Team liefert Produkte ("hier ist unsere Plattform v3.4, mit Changelog und SLA"). Es ist eine Disziplin mit eigenem Selbstverständnis: Die internen Entwicklungsteams sind Kunden, das eigene Werkzeug ist das Produkt, und der Erfolg misst sich an Adoption und Lead Time, nicht an erledigten Tickets.

HollerMetall macht Inventur

Bevor irgendjemand bei HollerMetall ein Backstage installiert oder einen Crossplane-Provider schreibt, gibt es einen zweiwöchigen Discovery-Sprint. Drei Personen aus den Entwicklungsteams, die beiden Operations-Kollegen, ein Architekt von außen. Ergebnis: eine Service-Topographie und ein Pain-Point-Backlog.

Die Topographie zeigt 14 produktive Services in vier Repositories und sechs verschiedenen Namespaces. Davon nutzen sechs Services denselben CI/CD-Workflow (kopiert vom ersten produktiven Service aus dem Jahr 2022, anschließend in jedem Team leicht verändert), vier nutzen Varianten davon, vier nutzen etwas vollständig Eigenes. Drei Sprachen sind im Einsatz: Java/Spring (Hauptlinie), TypeScript/Node (Frontends, Edge-Workloads), Python (Datenpipeline, ML-Vorhaben). Das IoT-System läuft auf einer abgespaltenen Cluster-Variante, weil es vor zwei Jahren niemand "in den Hauptcluster reingequetscht" bekommen hat.

Das Pain-Point-Backlog umfasst 73 Einträge, geclustert in fünf Themen:

  1. Onboarding neuer Services – langsam, undokumentiert, einer kennt den Weg, der ist gerade in Elternzeit.
  2. Secrets-Management – vier Wege, zwei davon mit Klartext-YAMLs in Repos, die theoretisch privat sind.
  3. Monitoring/Alerting – fünf verschiedene Stacks, kein einheitliches Dashboard für die Geschäftsführung.
  4. Infrastruktur-Bereitstellung – Terraform existiert, wird aber nur von zwei Personen wirklich verstanden.
  5. Compliance-Nachweise – jedes Audit ist ein Ad-hoc-Ausgrabungsprojekt.

Bredemann verteilt diese Liste an seine Teams und stellt eine Frage: "Welche drei Punkte würden Ihnen den meisten Schmerz nehmen, wenn ein Plattform-Team sie löst?" Die Mehrheit antwortet: Onboarding, Secrets, Monitoring. Die Reihenfolge der ersten Quartalsroadmap steht.

Der erste Golden Path: ein neuer Service in 30 Minuten

Im April 2026 startet HollerMetall ein dreiköpfiges Plattform-Team. Ein erfahrener Senior aus der bisherigen Operations-Truppe, ein Backend-Entwickler, der schon immer "die langweiligen Dinge" mochte, ein externer Berater von pleXtec für sechs Monate als Sparrings-Partner. Das Team hat ein klares Mandat: Bis Ende Juni soll der erste Golden Path live sein – und ein neues Pilotteam soll ihn wirklich nutzen, nicht nur in einem Workshop bestaunen.

Der Path heißt intern "standard-rest-service-v1" und ist im Kern eine Sammlung aus drei Bausteinen:

1. Eine Service-Vorlage in Backstage, die folgenden Output produziert:

$ idpctl create service
? Name des neuen Service: kunden-faktura
? Sprache: java-spring (1) | typescript-node (2) | python-fastapi (3)
> 1
? Datenklasse: oeffentlich | intern | vertraulich
> vertraulich
? Verantwortliches Team: team-erp
> team-erp

→ GitHub-Repository angelegt: hollermetall/svc-kunden-faktura
→ CI/CD-Pipeline angelegt (Standard-Workflow v1.4)
→ Helm-Chart erzeugt mit Standard-Werten
→ Backstage-Eintrag erstellt
→ Monitoring-Dashboard provisioniert
→ Standard-IAM-Policies angewendet
→ Pull-Request fuer ArgoCD-App-of-Apps erstellt
Service-Skelett bereit. Time-to-first-deployment: ~30 Minuten.

2. Eine Standard-CI-Pipeline als wiederverwendbares GitHub-Action-Workflow. Sie enthält Build, Test, Container-Scan (Trivy), SBOM-Erzeugung (Syft), Signing (Cosign), Push in die interne Registry, Deployment via ArgoCD. Die Pipeline ist versioniert und liegt im Plattform-Repository. Ein Service kann eine ältere Version nutzen, bekommt aber ab Version v1.6 einen Banner-Hinweis, dass auf v2 upgegradet werden sollte. Das Plattform-Team hat eine Deprecation-Policy: Versionen sind 12 Monate supported, dann werden sie entfernt.

3. Ein Konventions-Helm-Chart, das die Bedürfnisse von 90 Prozent aller Standard-Services abdeckt: zwei Replicas, Liveness/Readiness, OpenTelemetry-Instrumentierung, Standard-Ingress mit pleXtecs internem Cert-Manager, Sidecar für die Secret-Injection aus HashiCorp Vault. Wer Sonderfälle hat – etwa ein StatefulSet für die IoT-Pipeline – bekommt einen anderen Path: "stateful-service-v1". Ohne Sonderfall keine Sonderbehandlung; aber Sonderfälle bleiben möglich.

Wo der Pilot weh tut

Der erste Pilot ist Teamerp, das den neuen kunden-faktura-Service baut. Im ersten Sprint sieht alles gut aus: Service-Skelett in 22 Minuten, erstes Deployment in der Test-Umgebung am dritten Tag, Pull-Request gegen Produktion am Ende der zweiten Woche. Bredemann ist begeistert. Dann kommt die Realität.

Im dritten Sprint stellt das Team fest, dass das Standard-Helm-Chart keine ConfigMap für die Geschäftslogik-Konfiguration unterstützt – jedenfalls nicht so, wie sie es brauchen. Der Path ist zu eng. Sie öffnen einen Ticket beim Plattform-Team. Das Plattform-Team sagt: "Diese Konfigurationsstruktur ist ein Anti-Pattern, wir empfehlen einen ConfigMap-Wrapper." Teamerp sagt: "Wir brauchen das so, weil unser Geschäftsprozess so funktioniert." Es entsteht der erste echte Konflikt zwischen Plattform-Team und Konsumentenfachteam.

Hier zeigt sich die wichtigste Reife-Frage einer Plattform: Wie verhält sich das Plattform-Team, wenn der Path nicht passt? Drei mögliche Reaktionen:

  1. "Sorry, der Path ist verbindlich." – tot. Die Teams umgehen die Plattform und das Vertrauen ist weg.
  2. "Klar, machen wir alles für Sie." – tot. Die Plattform wird zu Custom-Consulting für jedes Team und skaliert nicht mehr.
  3. "Hier ist die Erweiterungs-Schnittstelle, hier sind unsere Empfehlungen, hier dokumentieren wir Ihren Use Case in unserem Catalog." – lebendig.

Die richtige Antwort ist immer Variante 3. Eine Plattform ist ein Produkt – und Produkte haben SDKs, Plug-Points, Customization-Hooks. HollerMetalls Plattform-Team beschließt nach drei Tagen Diskussion, einen extra-config-Block in das Standard-Chart einzubauen, der genau diesen Use Case sauber löst. Aufgenommen in die Roadmap, freigegeben für Version v1.6 des Charts. Teamerp setzt seine Lieferung fort, mit einer Workaround-Bibliothek bis das v1.6-Chart verfügbar ist.

Was sich nach sechs Monaten messen lässt

Im Oktober 2026 zieht HollerMetall Bilanz. Die Zahlen aus Bredemanns Folie sind nicht mehr alle dramatisch, aber sie haben sich bewegt:

  • Time-to-first-deployment für neue Standard-Services: von 27 Tagen auf 4 Tage (Median).
  • Anteil "infrastruktur-bedingter" Tickets im Entwicklungs-Backlog: von 34 % auf 18 %.
  • Anzahl Logging-Stacks: von fünf auf zwei (Standard plus IoT-Sonderfall).
  • Anzahl Wege, ein Secret in eine Pipeline zu bekommen: von vier auf einen, plus klar dokumentierte Migrationspfade für die alten Services.
  • Adoption Rate des Golden Path: 4 von 5 neuen Services ab Q3 2026 wurden über die Plattform aufgesetzt.

Die ehrliche Zahl, die fast nie in Marketing-Folien steht: Die Plattform hat Geld gekostet. Drei Vollzeitstellen, externe Beratung, Lizenzen für Backstage-Erweiterungen, ein neues Vault-Cluster. Bredemann rechnet vor: Etwa 480.000 Euro Investition im ersten Jahr. Demgegenüber 11 Entwickler-Wochen, die nicht mehr in Onboarding-Reibung versickert sind, plus die Tatsache, dass die KI-Funktionen im Kundenportal vier Wochen früher live gingen als im verschobenen Plan, plus eine messbare Reduktion der Pager-Aktivierungen. Auf 36 Monate gerechnet ist die Plattform deutlich positiv – aber im ersten Jahr ist sie eine Wette, die der Vorstand mittragen muss.

Sechs Lehren, die für jeden Mittelständler gelten

HollerMetall ist erfunden, aber das Muster ist es nicht. Sechs Beobachtungen aus realen Plattform-Projekten:

Erstens: Anfangen, bevor es weh tut, ist schwer – anfangen, wenn es bereits sichtbar weh tut, ist richtig teuer. Ein guter Auslöser für ein Plattform-Programm ist nicht "wir haben Probleme", sondern "wir bekommen das nächste Wachstum nur noch unter Schmerzen abgebildet". Wer wartet, bis die Entwickler-Frustrationsrate spürbar steigt, riskiert Abgänge.

Zweitens: Plattform ist Produkt. Das Plattform-Team braucht Produktmanagement-Disziplin: Roadmap, Release-Notes, Adoption-Metriken, Kunden-Feedback. Eine Plattform ohne Product Owner wird zur Sammlung netter Skripte, die niemand wartet.

Drittens: Golden Path schlägt Vorgabe. Verbindliche Standards stoßen auf Widerstand. Der bessere Weg, der dasselbe leistet, gewinnt – vorausgesetzt, er ist tatsächlich besser. Wenn die Plattform den Entwickler-Alltag spürbar einfacher macht, übernimmt sich Adoption von selbst.

Viertens: Sonderfälle sind erlaubt – aber teuer. Ein Path ist eine Abkürzung. Wer ihn verlässt, übernimmt mehr Verantwortung. Das ist ein faires Geschäft, das jedes Team versteht. Schwierig wird es nur, wenn die Plattform jeden Sonderfall in den Standard zwängt – oder umgekehrt jeden Sonderwunsch sofort erfüllt.

Fünftens: KI verstärkt, was da ist. KI-Coding-Assistenten wie Copilot, Cursor oder Claude Code beschleunigen Teams mit gut strukturierter Plattform um Faktoren. Bei Teams ohne Plattform produzieren sie schneller mehr Code mit denselben strukturellen Problemen. Wer 2026 in KI-Strategie investiert, sollte parallel in seine Plattform investieren – sonst verpufft der Effekt.

Sechstens: Compliance ist ein Plattform-Feature. Wer NIS2, DORA oder EU AI Act ernst nimmt, muss Nachweise auf Knopfdruck liefern können – Build-Provenance, SBOMs, Patch-Status, Zugriffsprotokolle. All das gehört in die Plattform, nicht in jeden einzelnen Service. Wir haben das im pleXtec-Beitrag zur Compliance-Software ausführlicher beschrieben.

Wie ein realistischer Einstieg aussieht

Drei Schritte, in dieser Reihenfolge, mit klaren Zeit-Ankern:

Phase 1 – Schmerz inventarisieren (4–6 Wochen). Discovery-Sprint mit Vertretern aus Entwicklung und Operations. Ziel: Service-Topographie, Pain-Point-Backlog, drei Themen mit höchstem ROI. Output: Ein zehnseitiges Dokument, das Sie der Geschäftsführung vorlegen können – inklusive Investitionsschätzung.

Phase 2 – ersten Golden Path bauen und ausrollen (3–6 Monate). Plattform-Team gründen (mindestens zwei, besser drei Personen). Erstes Pilotteam auswählen (idealerweise eines, das zeitnah einen neuen Service braucht). Standard-Pfad implementieren, Pilot durchführen, Feedback einarbeiten. Erfolgsmaßstab: Time-to-first-deployment für Standard-Services um mindestens 50 Prozent reduziert.

Phase 3 – verbreitern und vertiefen (6–18 Monate). Weitere Paths bauen (Stateful Services, Daten-Jobs, KI-Inferenz, Frontend-Apps). Bestehende Services schrittweise migrieren – nicht mit Big Bang, sondern bei jeder größeren Änderung mitziehen. Self-Service-Portal aufbauen. Compliance-Nachweise automatisieren.

Wichtig: Phase 1 ist mit Bordmitteln machbar. Phase 2 und 3 profitieren stark von externer Erfahrung – nicht weil das interne Team es nicht könnte, sondern weil ein paar erprobte Muster den Lernweg um Monate abkürzen. Das ist die Stelle, an der wir bei pleXtec typischerweise einsteigen, mit unserem Angebot rund um Softwareentwicklung und Projektmanagement für IT-Programme dieser Größenordnung.

Der Ausblick: Plattform als Wettbewerbsvorteil

2026 wird das Jahr, in dem sich der Mittelstand in zwei Lager teilt: Die einen behandeln Plattform als Strategie, die anderen behandeln sie als Optionalfunktion. Der DORA-Report 2025 hat eines deutlich gemacht: Organisationen mit reifer Plattform haben bei jedem KI-Hebel einen mehrfachen Vorteil. Sie liefern schneller, fühlen weniger Reibung, halten Compliance ein, ohne dass jeder Entwickler zum Auditor mutiert. Sie bauen Software wie ein Produkt – und ihre Entwickler wollen bleiben.

Die Konkurrenz, die das nicht tut, hat 2027 nicht weniger Talent. Sie hat nur mehr Frust pro Person und weniger Output pro Quartal. In einem Markt, in dem qualifizierte Entwickler weiterhin knapp sind und KI-Werkzeuge vorhandene Strukturen verstärken statt sie zu reparieren, ist Platform Engineering keine technische Spielerei. Es ist eine Geschäftsentscheidung – mit allen Implikationen, die das Wort "Geschäftsentscheidung" in einem Mittelstandsvorstand auslöst.

Felix Bredemann hat seine HollerMetall-Plattform übrigens nicht "Internal Developer Platform" genannt. Er hat sie "Werkbank" getauft. Mit der Begründung, dass jede gute Werkbank das Werkzeug griffbereit hält, den Arbeitsplatz nicht verstopft und so robust ist, dass man sie morgen genauso vorfindet wie gestern. Wir finden, das ist eine sehr deutsche und sehr passende Metapher.

Fazit

Platform Engineering ist nicht das nächste Buzzword aus dem Cloud-Native-Universum. Es ist die strukturelle Antwort auf eine Reihe von Problemen, die jeder Mittelständler kennt, der mehr als zwei Entwicklerteams hat: doppelte Arbeit, inkonsistente Stacks, langsames Onboarding, Compliance-Schmerzen. Die Lösung – eine interne Entwicklerplattform mit klaren Golden Paths – ist kein Projekt, das man "mal eben macht". Sie ist eine mehrjährige Investition, die sich nach 18 bis 36 Monaten klar rechnet, wenn man sie richtig aufstellt. Und sie ist 2026 die wichtigste Voraussetzung dafür, dass KI-Werkzeuge in Ihrer Softwareentwicklung tatsächlich Geschwindigkeit bringen, statt nur Chaos zu beschleunigen. Wer das Programm jetzt aufsetzt, hat bis Ende 2027 einen messbaren Vorsprung – wer wartet, wird ihn aufholen müssen, wenn die Wettbewerber bereits drei Iterationen weiter sind.

Wenn Sie über einen Plattform-Einstieg nachdenken oder schon mittendrin stecken und Sparring suchen, melden Sie sich gern: Wir hören uns Ihre Topographie an, geben eine ehrliche Einschätzung zur Reife und skizzieren einen realistischen Phasenplan – ohne Folien, mit Kreidestiften vor einem Whiteboard.