10 Jahre nach Goetsch: Was das O'Reilly-Microservices-Buch über Commerce 2026 falsch und richtig vorhergesagt hat

Oktober 2016. Kelly Goetsch, damals bei commercetools, veröffentlicht bei O'Reilly ein schmales eBook: Microservices for Modern Commerce. 76 Seiten, gesponsert von commercetools, mit einem Vorwort von Jean-Jacques van Oosten, dem damaligen Chief Digital Officer der Rewe Group. Die Kernthese: Microservices werden den Commerce-Stack dauerhaft verändern, Backend-Monolithen sterben, APIs werden die neue Infrastruktur.

Zehn Jahre später ist diese These Konsens. Headless, MACH, Composable, der gesamte Kategoriebegriff, mit dem wir heute arbeiten, ist direkt aus dieser Gedankenwelt gewachsen. Und genau deshalb lohnt es sich jetzt, das Buch als Decade-Retrospective zu lesen: Welche Prognosen haben sich als richtig erwiesen? Welche wurden von der Realität überholt? Und welche Lücke hat Goetsch damals zu klein beschrieben, eine Lücke, die heute der eigentliche Differenzierungs-Engpass ist?

Was Goetsch richtig gesehen hat

1. Conway's Law ist der entscheidende Faktor, nicht die Technologie

Goetsch zitiert auf Seite 3 Mel Conways berühmten Satz von 1968: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." Und er nennt Microservices direkt "Hacking Conway's Law."

Das war 2016 eine mutige These in einem Feld, das technische Architekturfragen meistens technisch beantwortet hat. Heute ist die Erkenntnis unbestreitbar: Composable-Projekte scheitern in der Praxis nicht an den Tools, sondern an Org-Silos. Frontend-Team hier, Backend-Team dort, Content-Team irgendwo dazwischen, und der Composable-Stack ist schnell wieder ein Monolith, nur einer mit deutlich mehr Moving Parts.

Wenn du heute ein Replatforming planst und deine Teams noch nach horizontalen Schichten strukturiert sind (Dev-Team, Ops-Team, Content-Team), dann wirst du die technische Flexibilität von Composable-Architekturen nicht ausschöpfen. Die Org-Struktur entscheidet. Immer noch.

2. Inner vs. Outer Complexity, der Shift ist real

Eines der schärfsten Konzepte im Buch ist die Unterscheidung zwischen Inner Architecture und Outer Architecture. Goetsch schreibt: "Fundamentally, microservices shift complexity outward, trading external complexity for inner simplicity." Jeder einzelne Microservice wird einfacher. Das Netz zwischen ihnen, Service Discovery, Eventing, API-Gateways, Container Orchestration, wird deutlich komplexer.

Dieser Shift ist 2026 vollständig angekommen. Kubernetes ist Standardwerkzeug. Event-Streaming via Kafka ist eine eigene Disziplin. API-Gateway-Konfigurationen füllen eigene Repositories. Die Inner-Simplicity hat sich realisiert. Aber die Outer-Complexity hat ein eigenes Gewicht bekommen, das viele Teams 2016 unterschätzt haben.

3. Omnichannel braucht eine einzige Source of Truth pro Funktion

Goetsch beschreibt True Omnichannel als: ein einziges System pro Business-Capability (Pricing, Inventory, Promotions), und darüber hinaus "UIs being more or less disposable." Das Backend-Argument hat sich vollständig bestätigt. Kein ernstzunehmender E-Commerce-Stack betreibt heute noch ein einziges monolithisches System, das Pricing, Inventory und Promotions gleichzeitig verwaltet.

Shopware, commercetools, SFCC in Headless-Konfiguration, Algolia für Search, Stripe für Payments, die Disaggregation des Backends ist gelebte Realität. Der Markt hat Goetsch hier absolut recht gegeben.

Was Goetsch falsch, oder zu klein, gesehen hat

4. "Disposable UIs" war der teuerste Irrtum des Jahrzehnts

Hier wird es interessant. Goetsch schreibt 2016, dass bei echtem Omnichannel die UIs "more or less disposable" seien. Man baue einmal saubere Backend-APIs, und neue User Interfaces, ob für Apple Watch, für Kiosk, für Chatbots, entstünden dann in wenigen Tagen.

Diese Annahme hat sich als falsch herausgestellt. Nicht in der Theorie, aber in der Praxis.

Was tatsächlich passiert ist: Die Disaggregation des Backends hat massiv neue Frontend-Komplexität erzeugt. Jedes neue Frontend muss jetzt API-Calls gegen Dutzende von Microservices koordinieren, Caching-Strategien pro Datentyp implementieren, Personalisierungs-Logic tragen, Performance-Budgets halten und gleichzeitig globale Rollouts über mehrere Märkte und Sprachen managen. Wer heute einen Composable-Storefront auf Basis von Next.js, commercetools und Algolia baut, schreibt erheblich mehr Frontend-Code als jede Shopware-6-Custom-Entwicklung, und hat eine deutlich höhere Betriebskomplexität.

Die "disposable UI" war in Wirklichkeit nicht disposable. Sie war nur unsichtbarer im Backend-fokussierten Diskurs von 2016.

5. Der Frontend-Layer ist heute der eigentliche Differenzierungs-Engpass

Wenn Backends standardisierbar und als SaaS zukaufbar sind, und das sind sie, das ist die MACH-These, die sich bestätigt hat, dann verschiebt sich der Wettbewerb in Richtung Frontend. Wer schneller neue Erfahrungen auf die Bahn bringt, wer Personalisierung näher am Rendering entscheidet, wer A/B-Tests ohne Backend-Deployment fährt, wer KI-gestützte Content-Compositing ohne Dev-Involvement macht, der gewinnt.

Das ist genau der Layer, den Goetsch 2016 kleingeredet hat. Und heute ist er der Engpass.

Was Goetsch mit dem API-Gateway als "Backend for your Frontend" beschrieben hat, ist 2026 in Richtung Frontend Management Platforms weiterentwickelt worden. Eine FMP übernimmt die Outer Architecture des Frontend-Layers, Routing, Komposition, Caching, Personalisierung, Deployment, analog zu dem, was Container Orchestration für den Backend-Layer getan hat.

Die Analogie ist direkt: Genauso wie du 2016 kein Microservices-Deployment ohne Container Orchestration betreiben wolltest, willst du 2026 keinen Composable-Storefront ohne Frontend-Layer-Standard betreiben.

Was das für dein Replatforming bedeutet

Wenn du heute einen Composable-Stack planst, lohnen sich drei Fragen aus der Goetsch-Retrospektive:

Frage 1: Ist deine Org-Struktur bereit für Conway's Law? Cross-functional Product-Teams pro Business-Capability sind kein Nice-to-have. Ohne sie wirst du die Flexibilität des Composable-Stacks nicht realisieren, egal welche Tools du wählst. Mehr dazu in unserem Post Conway's Law im Composable-Replatforming.

Frage 2: Hast du einen Plan für die Outer Architecture deines Frontends? Backend-Microservices haben einen Plan gebraucht (Container Orchestration, API-Gateways, Service Discovery). Dein Frontend braucht einen analogen Plan. Ohne Frontend-Layer-Standard explodiert der TCO. Mehr dazu in Headless allein reicht nicht.

Frage 3: Wer ownt den Frontend-Layer als Capability? Nicht als "das Frontend-Team", das Tickets bearbeitet, sondern als eigenständige Business-Capability mit eigenem Ownership, eigenem Roadmap-Einfluss, eigener Tool-Entscheidung. Das ist das Ownership-Prinzip, das Goetsch für Microservices beschrieben hat, auf den Frontend-Layer angewendet.

Fazit: Goetsch hatte recht, und hat eine Lücke hinterlassen

Microservices for Modern Commerce war 2016 ein wichtiges Buch. Es hat einen Diskurs ausgelöst, der zur MACH-Bewegung, zu commercetools' Wachstum, zu Shopware Headless und zu einem ganzen Ökosystem von spezialisierten Commerce-APIs geführt hat.

Die Backend-Thesen haben sich bestätigt. Conway's Law gilt immer noch. Inner vs. Outer Complexity ist ein nützliches Konzept geblieben.

Aber die "disposable UIs"-Annahme war der blinde Fleck des Buchs, und dieser blinde Fleck hat die Commerce-Welt ein Jahrzehnt lang beschäftigt. Heute ist der Frontend-Layer der Differenzierungs-Engpass, und die Antwort darauf ist nicht ein weiteres Custom-Build, sondern ein Frontend-Layer-Standard.

Bei Laioutr nennen wir das die Agentic Frontend Management Platform, entwickelt aus der Erkenntnis, dass das, was Kubernetes für Microservices getan hat, für den Frontend-Layer noch aussteht.

[Demo buchen und ansehen, wie Laioutr das löst](https://www.laioutr.com/demo)

Quelle: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.