Die Power der Plattform: Vier Plattformlösungen, die Cloud Adoption wirklich voranbringen

Die Strategie steht, die Verträge sind unterschrieben, der erste Cloud-Zugang ist eingerichtet – und trotzdem kommt die Organisation nicht in die Umsetzung. Wer Cloud-Transformation vor allem als Technikthema versteht, übersieht genau die Stelle, an der es klemmt: Ein leerer Account ist noch keine produktive Plattform, und eine Strategie schafft noch keine Kompetenz.

In der sechsten Folge der zweiten Staffel unseres Platform Stories Podcasts gibt es diesmal ein Überraschungsformat: keinen Gast, sondern Jörg und Christina im direkten Austausch. Die beiden haben zusammengetragen, was ihnen in der Arbeit mit unseren Kunden immer wieder begegnet – die vier häufigsten Plattformlösungen. Zusammen ergeben sie eine Platform Journey: vier Stufen vom ersten Experiment bis zur ausgebauten Enterprise-Plattform.

Hier sind die wichtigsten Takeaways.

Warum überhaupt interne Plattformen? Souveräne Produktivität als Ziel

Der Ausgangspunkt ist Souveränität. Wer souverän bleiben will, braucht Auswahl – am besten mehrere Clouds oder zumindest die Möglichkeit, zwischen ihnen zu wechseln. Genau hier beginnt jedoch die Komplexitätsfalle: unterschiedliche Portale, andere Services, eigene Regeln je Anbieter. Entwickler beschäftigen sich dann mit zu vielen Themen, bauen dieselben Dinge immer wieder neu und verlieren Zeit.

Das Ziel, das alle vier Plattformlösungen verbindet, ist deshalb souveräne Produktivität: die Cloud so nutzen, dass das Geschäft schnell vorankommt – und gleichzeitig echte Alternativen und Auswahl behalten. Beides in Einklang zu bringen, ist die eigentliche Aufgabe interner Plattformen.

Stufe 1 – Playgrounds: Cloud zum Anfassen

Der erste Schritt klingt simpel, wird aber häufig unterschätzt. Eine neue Cloud in der Breite einzuführen bedeutet nicht, nur die ein, zwei Vorreiter-Teams mitzunehmen, die ohnehin schon vorangehen möchten – sondern alle, die Berührungspunkte mit der Cloud haben. Und das gelingt nur, wenn Berührungsängste abgebaut und der Einstieg so einfach wie möglich gemacht wird.

Wie stark ein niedrigschwelliger Zugang wirkt, hat ChatGPT eindrücklich gezeigt. Genau dieses Prinzip überträgt ein Playground auf die Cloud: schneller Self-Service statt Ticketprozess, eine vorbereitete Umgebung, in der nichts schiefgehen kann, und klare Guardrails – etwa eingeschränkte Services, Budgets und Laufzeiten.

„Show don’t tell": Wer eine neue Cloud einmal praktisch erlebt hat, hat im entscheidenden Moment die passende Lösung bereits im Kopf.

Einige weniger offensichtliche Punkte gehören von Anfang an mitgedacht: Playgrounds werden sonst schnell zu dauerhaftem Cloud-Clutter. Ownership muss klar sein, nichts Produktives darf dort dauerhaft liegen, und Ablauf heißt nicht deaktivieren, sondern sauber deprovisionieren. Bei meshcloud selbst hat übrigens genau eine solche Self-Service-Trial mit Selbstregistrierung viel bewegt – und für die Schulungsumgebungen kooperieren wir derzeit mit einem großen europäischen Cloud-Anbieter.

Stufe 2 – Landing Zones: aus dem leeren Account wird eine Foundation

Sobald aus dem Experiment ein echter Use Case wird, geht es über den Playground hinaus – und die Anforderungen ändern sich grundlegend. Ein leerer Cloud-Account reicht dann nicht mehr. Es braucht Netzwerk-Setup, Identitäten und Berechtigungen, Monitoring, Security Policies, Budgets, Tags und Ownership. Account Vending stellt den Account bereit; eine Landing Zone macht ihn betriebsfähig und integriert ihn in das Unternehmen.

Der Knackpunkt ist Standardisierung, ohne alles in dieselbe Schablone zu pressen. Eine einzige maximale Landing Zone für alles wird teuer und langsam – eine Webanwendung, eine Datenplattform, ein AI-Use-Case und eine Produktionsumgebung brauchen unterschiedliche Ausprägungen. Der Weg dahin: eine gemeinsame Baseline festlegen und variable Fähigkeiten modular ergänzen. In meshStack modellieren wir das als wiederverwendbare Building Blocks – Netzwerk, Monitoring, Backup, Security, Datenbanken oder AI-Zugänge. So entsteht Landing Zone as a Service statt eines starren Templates.

Zwei Erfahrungswerte bestätigen sich dabei immer wieder: Shared Responsibility muss früh geklärt und dokumentiert sein, damit sich niemand auf den anderen verlässt. Und Kosten und Ownership müssen vom ersten Tag an sichtbar sein – wer sie verursacht, verantwortet sie auch. Nutzer sollten dabei ihren Use Case beschreiben, nicht die passenden Infrastrukturkomponenten erraten müssen.

Stufe 3 – Internal Developer Platform: vom Zugang zur Produktivität

Nun folgt der Punkt, der viele überrascht: Selbst mit fertiger, sicherer Cloud-Umgebung ist ein Entwickler oft noch lange nicht produktiv. Eine leere Umgebung bedeutet nämlich weiterhin sehr viel Freiheit – und damit sehr viel Zusammenbau. Es fehlen noch Runtime, Repository, CI/CD, Datenbank und Secrets, Logging und Monitoring, DNS und Zertifikate, Security-Scanning sowie freigegebene AI-Dienste.

Der Wert einer Internal Developer Platform liegt nicht in den einzelnen Services, sondern darin, dass sie korrekt zusammenspielen: Datenbank bereitstellen, Zugang im Secrets-System hinterlegen, Anwendung verbinden, Monitoring aktivieren – alles integriert. Aus vielen Einzelteilen wird ein Golden Path, den der Entwickler auswählt, statt sich seinen Tech Stack jedes Mal selbst zusammenzusetzen. Ein Portal ohne ausführbare Produkte bleibt ein Katalog; eine technische Plattform ohne gute User Experience bleibt ein Expertensystem. Erst beides zusammen ergibt eine echte Entwicklerplattform.

So wird Shift Left endlich das, was es immer sein sollte: Entwickler übernehmen Verantwortung – aber die Plattform lässt sie damit nicht allein. Strategisch entsteht daraus ein erheblicher Hebel: Standards lassen sich zentral weiterentwickeln, Security und Compliance werden automatisiert mitgeliefert, neue AI-Dienste kontrolliert verfügbar gemacht, und Platform-Teams können Infrastruktur austauschen oder mehrere Clouds unterstützen, ohne dass jeder Entwickler den konkreten Provider vollständig beherrschen muss.

Stufe 4 – Multi-Cloud Brokerage: die Plattform aller Plattformen

In großen Unternehmensverbünden gibt es irgendwann nicht mehr eine gute Plattform, sondern viele – über Länder, Tochtergesellschaften und Geschäftsbereiche hinweg, oft zusätzlich verstärkt durch Zusammenschlüsse. Wer das nicht aktiv gestaltet, erhält Wildwuchs und genau die Komplexität, die eigentlich vermieden werden sollte.

Multi-Cloud Brokerage ist die Antwort darauf – die Plattform aller Plattformen. Das Bild dahinter: Teams sind Consumer und Provider zugleich. Das Netzwerkteam bietet Connectivity, das Datenbankteam nutzt Infrastruktur und bietet Managed Databases, das AI-Team kombiniert Runtime, Daten und Modelle – eine Wertschöpfungskette aus Plattformservices. Damit stellt sich die Organisation vom Kopf auf die Beine: zentrale Governance verlangt keine zentrale Produktion.

Vereinheitlicht werden nicht die Technologien, sondern die Art, wie mit ihnen gearbeitet wird: Veröffentlichung und Beschreibung von Angeboten, Zugang und Berechtigungen, Metadaten und Ownership, Policies, Kosten und Verrechnung, Lifecycle und Service Levels – nutzbar über Self-Service, API und Infrastructure as Code. Der Effekt: Vorhandene Kompetenz wird organisationsweit nutzbar, Doppelarbeit sinkt, neue (auch europäische) Provider lassen sich schneller integrieren, und Abhängigkeiten werden transparent. So entstehen Alternativen, ohne einen neuen zentralen Engpass zu schaffen.

Fazit: Vier Stufen, eine Journey

Die vier Lösungen ergänzen sich zu einem klaren Weg: Playgrounds zum Ausprobieren und Kompetenzaufbau, Landing Zones für den geordneten, sicheren Start, die Internal Developer Platform für direkt produktive Entwicklung und Multi-Cloud Brokerage, um Plattformservices organisationsweit anzubieten und zu kombinieren.

Der gemeinsame Nenner bleibt Souveränität – und die bedeutet nicht, Technologien einzuschränken. Souveränität heißt Vielfalt: Technologien absichern, ausprobieren, schnell zu produktiven Tech Stacks kombinieren und darauf kollaborieren – unabhängig davon, welche Cloudplattformen man dafür einsetzen oder vermeiden möchte. Das ist die Power der Plattform.

Am 24. September treffen wir uns in Frankfurt auf unserer Konferenz – mit weiteren Plattformlösungen und Erfahrungen von Kunden, unter anderem von der EDEKA IT. Wir freuen uns, wenn du vorbeischaust.

🎧 Hier geht’s zur vollen Folge der Platform Stories – auf YouTube und Spotify.