Plattform­strategien neu denken: Warum der Produktansatz überzeugen kann.

Ein Plattformteam schafft kein Projekt, sondern ein dauerhaftes, wertstiftendes Produkt, das Engineering-Teams befähigt und Innovation beschleunigt. Der Schlüssel zum Erfolg liegt darin, diese Perspektive in der Organisation zu verankern – mit einem klaren Nutzenversprechen, echter Nutzerzentrierung und dem richtigen Setup in Governance, Kommunikation und Ressourcen. 

Damit dieser Wandel gelingt, braucht es aber mehr als gute Technik: Es braucht klare Incentives für die interne Akzeptanz, strategisches Alignment und eine durchdachte Produktstrategie.

Florian Stelzer (FST) ist ein erfahrener Principal Architect bei Innovation Process Technology mit einem klaren Fokus auf Cloud-Automation, sichere Cloud-Foundations und Container-Plattformen für Enterprise-Kund:innen. Mit seiner tiefen Expertise in Infrastructure as Code, Cloud-native Technologien und DevOps-Praktiken hilft er Unternehmen, ihre digitale Transformation sicher, skalierbar und effizient umzusetzen.

Er steht für eine resiliente Architektur, automatisierte Deployments und eine ganzheitliche Sicht auf moderne Plattformen – stets mit einem hohen Anspruch an Sicherheit und Effizienz. Florian verbindet technische Exzellenz mit einem starken Verständnis für die organisatorischen Herausforderungen, die mit Platform Engineering einhergehen.

Patrick Hofmann (PHO) ist erst seit Kurzem Teil von ipt. Zuvor war er bis September 2024 als Leiter der Abteilung Enterprise & Shared IT Services und StV. CIO bei PostFinance tätig und verantwortete mit seinen Teams unter anderem die gesamte IT-Infrastruktur sowie den Aufbau einer modernen CI/CD-Pipeline.

Bereits ab 2017 entwickelte und betrieb sein Team eine Private Cloud, die wann immer möglich auf Open-Source-Technologien und Infrastructure-as-Code-Prinzipien basierte. Ab 2020 definierte er gemeinsam mit Platform Architekten und Product Ownern in diesem Bereich das Zielbild für die unternehmensweite CI/CD-Strategie («Delivery Pipeline») und setzte diese in der bestehenden On-Premises-Private-Cloud mithilfe von Cloud-Native-Ansätzen, GitOps und DevOps-Praktiken erfolgreich um.

Was ist der grösste Unterschied zwischen einem Projekt- und einem Produktansatz bei Plattformen?

PHO: Aus meiner Sicht liegt der zentrale Unterschied zwischen Projekt- und Produktansatz im Zeithorizont und der Ausrichtung. Während Projekte auf ein klar definiertes Endziel hinarbeiten, erfordert ein Produktansatz eine kontinuierliche Weiterentwicklung:

• Der Fokus liegt dabei auf langfristigem Mehrwert und nachhaltiger Zufriedenheit der Nutzer:innen – nicht nur auf dem Abschluss eines Vorhabens.
• Zudem müssen beim Produktansatz die Kompetenzen der Mitarbeitenden stärker berücksichtigt werden. Die Umstellung von klassischen Entwicklungsmodellen auf agile Methoden und CI/CD-Praktiken erfordert gezielten Kompetenzaufbau. Diese Lernzeit muss bewusst eingeplant und durch das Management ermöglicht werden.
• Ein Produkt ist nicht abgeschlossen, wenn das initiale Projekt beendet ist – im Gegenteil: Erst dann beginnt seine eigentliche Lebensphase. Mit wachsender Nutzer:innenzahl und zunehmenden Anforderungen entwickelt es sich weiter und muss aktiv gepflegt werden.

FST: Ich stimme Patrick zu. Insbesondere der klar abgesteckte Rahmen unterscheidet sich deutlich zwischen Projekt- und Produktansatz. Ich möchte zusätzlich die Perspektive der Stakeholder hervorheben: Beim Produktansatz stehen die Bedürfnisse der Nutzer:innen im Zentrum. Sie beeinflussen entscheidend, in welche Richtung sich die Plattform weiterentwickelt, denn letztlich soll sie ihren Alltag erleichtern. 

Im Gegensatz dazu werden im Projektansatz die Anforderungen häufig von den Auftraggeber:innen definiert – also von Personen, die selbst nicht zwingend zu den eigentlichen Nutzer:innen gehören.

Welche Nutzer:innen müssen im Zentrum eines Plattformprodukts stehen und wie holen wir sie frühzeitig ins Boot?

PHO: Unbestritten stehen die internen Entwickler:innen im Mittelpunkt. Es ist entscheidend, sie von Beginn an einzubeziehen – ihre Bedürfnisse zu verstehen und sie aktiv in den Entwicklungsprozess zu integrieren. Regelmässiges Feedback und eine kontinuierliche Weiterentwicklung der Plattform auf dieser Basis sind Schlüsselfaktoren für den Erfolg.

Zudem sollte das sogenannte «Not-invented-here-Syndrom» berücksichtigt werden: Viele Teams verfügen über eingespielte Prozesse, die durch neue Plattformlösungen infrage gestellt werden könnten. Hier sind Sensibilität und ein offener Austausch gefragt, um die notwendige Akzeptanz zu schaffen.

Besonders hohe Akzeptanz und schnelle Adoption neuer Plattformkomponenten wurden immer dann erreicht, wenn Nutzer:innen selbst zu Botschafter:innen wurden – etwa durch Erfahrungsberichte an internen Veranstaltungen, bei denen sie ihre konkreten Erfolge mit der Plattform geteilt haben.

FST: Patrick hat bereits zentrale Erfolgsfaktoren genannt, die entscheidend sind, damit eine Plattform erfolgreich angenommen wird. Ich möchte den Blick auf die Zielgruppen noch etwas erweitern: Im Kontext von Platform Engineering denken wir oft zuerst an Internal Developer Platforms, bei denen interne Entwickler:innen im Fokus stehen – und das ist auch vollkommen richtig. 

Der Plattformgedanke lässt sich jedoch weiter fassen. Plattformprodukte können ebenso für externe Zielgruppen relevant sein, wie etwa Partnerunternehmen, externe Softwarelieferanten oder Community-Entwickler:innen. Auch diese Gruppen sollten frühzeitig einbezogen werden – durch transparente Kommunikation, offene Schnittstellen und kollaborative Formate wie Entwickler-Events oder Feedback-Sessions. 

Ein konkretes Beispiel in diesem Kontext könnte eine API-Plattform für mehrere Partnerunternehmen sein.

Was braucht es organisatorisch, damit ein Platform-Team gut funktionieren kann?

PHO: Organisatorisch bedarf es klar definierte Zuständigkeiten und eines engagierten Produktteams mit ausreichenden Ressourcen:

• Eine Kultur der Zusammenarbeit und des kontinuierlichen Lernens.
• Ebenso wichtig ist die Freiheit des Teams, Entscheidungen zu treffen und Innovationen voranzutreiben.
• Auch die Zeit, die die Mitarbeitenden benötigen, um sich neue Tools und Arbeitsweisen anzueignen, sollte nicht unterschätzt werden. Diese Zeit muss von der Führungsebene bereitgestellt und unterstützt werden, damit sich die Teams optimal entwickeln können.

FST: Ich stimme auch hier Patrick zu. Ganz zentral sehe ich zwei Punkte: 

1. Das Mindset in der Organisation, insbesondere auf der Führungsebene, dass das Plattform-Team nach einem Produktansatz entwickelt und nicht nach einem Projektansatz.
2. Die Schnittstelle zwischen dem Plattform-Team und den Anwender:innen ist ein kritischer Erfolgsfaktor. Es ist absolut entscheidend, dass die richtigen Anforderungen von den späteren Nutzer:innen aufgenommen werden und eine gute Beziehung zu ihnen gepflegt wird. Nur dann steigt auch die Akzeptanz, das Produkt und den damit einhergehenden etwaigen Aufwand für Migrationen in Kauf zu nehmen.

Wie schaffen wir intern Akzeptanz und Commitment für eine Plattform als Produkt – insbesondere bei den Stakeholdern mit anderen Prioritäten?

PHO: Die klare Kommunikation des Mehrwerts der Plattform und wie sie die Arbeit der Entwickler:innen erleichtert, ist von grosser Bedeutung. Man kann zwar versuchen, ein Produkt durch Vorgaben und im schlimmsten Fall sogar durch Sanktionen bei Nichtbenutzung durchzusetzen, aber dies ist oft nicht von Erfolg gekrönt. 

Es muss eine intrinsische Motivation für die Nutzung der Plattform vorliegen. Diese wird erreicht, indem man echte Herausforderungen der Nutzer:innen durch den Einsatz des Produkts lösen kann.

FST: Die intrinsische Motivation der Anwender ist entscheidend – sie trifft den Kern der Zielgruppe einer Plattform. Auf der KubeCon gab es dazu einen spannenden Beitrag: «How to sell your Platform internally?» Darin wurden unter anderem praxisnahe Tipps vorgestellt – etwa, mit Demos einen Wow-Effekt zu erzeugen oder durch externe Events die interne Sichtbarkeit zu erhöhen. 

Für weitere Stakeholder ist vor allem das Aufzeigen des Business Value entscheidend. Kann ich konkret beispielsweise mittels Metriken vorweisen, dass meine Time-To-Production massiv reduziert wurde? Damit überzeuge ich sicherlich auch die pessimistische Seite der Stakeholder.

Wo sind Stolpersteine bei der Einführung von Plattformen – sei es technologisch, organisatorisch oder kulturell? Habt ihr konkrete Beispiele aus dem Alltag in Unternehmen?

PHO: Oftmals sind die grössten Stolpersteine kultureller Natur. Widerstand gegen Veränderungen, insbesondere bei Abteilungen wie Security oder Compliance, die ihre Anforderungen automatisieren müssen, ist keine Seltenheit. Technologisch kann die Integration bestehender Systeme herausfordernd sein. 

Organisatorisch ist es entscheidend, das Team richtig aufzustellen und zu befähigen. Ein konkretes Beispiel ist die Herausforderung, wenn Teams von der Wasserfall- zur agilen Methode wechseln müssen. Dies erfordert sowohl Zeit als auch Schulungen, um sicherzustellen, dass alle Mitarbeitenden die notwendigen Fähigkeiten entwickeln.

FST: Change Management spielt zweifellos eine zentrale Rolle. Wie Patrick treffend bemerkt, bringt Veränderung im Unternehmen fast immer auch Widerstand mit sich. Ein Beispiel aus meinem Alltag: Wir hatten eine leistungsfähige und technisch ausgereifte Plattform entwickelt – die am Ende dennoch nicht eingesetzt wurde. 

Der Hauptgrund: Die Zielgruppen waren im Vorfeld nicht klar definiert. Als sich diese später herauskristallisierten, traten unterschiedliche Vorbehalte auf. Einige Nutzer:innen wünschten sich mehr Kontrolle, als die Plattform bewusst abstrahierte. Andere empfanden das geplante Betriebsmodell als unzureichend. 

Zudem fehlte es an ausreichender Unterstützung und Förderung durch die Organisation selbst. So blieb das Potenzial der Plattform ungenutzt, obwohl sie den produktiven Einsatz ohne Zweifel verdient hätte.

Wie messen wir den Erfolg einer Plattform, wenn sie kein klassisches Delivery-Ziel verfolgt?

FST: Spannende Metriken können verschiedene Dimensionen haben:

• Es gilt die Adaption (wie Onboarding Zeit oder Anzahl genutzter Features),
• den Nutzererfolg (gesparte Zeit oder Anzahl reduzierter Support Tickets)
• und die technische Effizienz (Dora Metriken wie Deployment Frequenz, etc.) zu messen.

Was müsste passieren, damit Platform Engineering wirklich als strategisches Produkt verstanden und betrieben wird?

PHO: Ein starkes Commitment des Top-Managements und die Anerkennung, dass Platform Engineering ein strategischer Erfolgsfaktor ist, sind unabdingbar. Und es darf auf keinen Fall nur der CIO sein, der dieses Commitment abgibt – die gesamte Geschäftsleitung muss dahinterstehen. Denn eine DevOps CI/CD-Plattform ermöglicht Kundennutzen für die ganze Firma, auch wenn dies oft mit einem IT-Projekt oder -Produkt verwechselt wird. 

Die Plattform muss als Investition in die Zukunft betrachtet werden, die uns einen Wettbewerbsvorteil verschafft. Eine Integration der Plattform in die Gesamtstrategie des Unternehmens ist dafür ausschlaggebend. Zudem ist es wichtig, dass alle Beteiligten die Zeit bekommen, die sie brauchen, um sich in die neuen Systeme und Methoden einzuarbeiten. Nur so kann Platform Engineering langfristig erfolgreich sein.

Das Gespräch hat Noemi Haag, ipt Marketing & Communications, geführt. Vielen Dank für die Diskussion!