Composable scheitert selten an Technologie – sondern an Organisationen, die das Betriebsmodell hinter der Architektur nie gebaut haben.
Composable Architecture klingt nach dem, was sich jeder CIO wünscht: Flexibilität ohne Abhängigkeit, Geschwindigkeit ohne technische Schulden, Best-of-Breed ohne Vendor-Lock-in. Das Versprechen ist elegant. Es ist auch unvollständig.
Was in Keynotes, Vendorpräsentationen und Analystenbriefings selten Raum bekommt: Unter welchen Bedingungen wird dieses Versprechen einlösbar? Composability ist keine Eigenschaft, die man kauft. Sie ist eine Fähigkeit, die eine Organisation entwickeln muss – über Monate, oft über Jahre. Sie setzt voraus, dass Teams anders zusammenarbeiten, dass Verantwortlichkeiten anders geschnitten sind und dass Entscheidungen anders getroffen werden als in den meisten Unternehmen heute üblich.
Die Lücke zwischen der Architekturentscheidung und der organisatorischen Realität – dort sterben die meisten Composable-Projekte leise. Nicht mit einem Knall. Nicht mit einer Pressemitteilung. Sondern mit schleichend steigenden Run-Kosten, sinkender redaktioneller Produktivität und einem wachsenden Schatten-Ökosystem aus Workarounds, die niemand geplant hat.
McKinsey beziffert die Erfolgsquote digitaler Transformationen seit Jahren konsistent: 70 Prozent scheitern, die häufigsten Ursachen sind organisatorischer und führungstechnischer Natur. Bain bestätigt das Muster mit einer Studie unter mehr als 400 Führungskräften: 88 Prozent der Transformationen erreichen ihre ursprünglichen Ambitionen nicht. Der stärkste Erfolgsprädiktor ist nicht die Technologiewahl, sondern die Verfügbarkeit von Talent und organisatorischen Fähigkeiten. Wer Composable einführt, ohne diese Realität zu adressieren, investiert in eine Architektur, die niemand bedienen kann.
Eine Composable-Architektur disaggregiert Systeme in unabhängig austauschbare Komponenten. Was auf dem Whiteboard befreiend wirkt, erzeugt in der Praxis eine Menge neuer Fragen – keine davon technischer Natur. Die erste und dringlichste: Wer ist für was verantwortlich?
In einem monolithischen CMS ist die Antwort implizit gegeben. Die Suite definiert den Rahmen, die Abteilung administriert ihn, die Redaktion arbeitet darin. In einer Composable-Welt gibt es diesen Rahmen nicht mehr. Jede Komponente braucht klare Ownership – nicht im Sinne eines Namens auf einem Organigramm, sondern als Instanz, die strategisch, operativ und wirtschaftlich für Betrieb, Weiterentwicklung und Abschaltung verantwortlich ist. Klingt selbstverständlich. Ist es nicht. Die MACH Alliance hat 2025 unter 561 Senior IT Leaders in Unternehmen mit mehr als 5.000 Mitarbeitenden die größten Barrieren für den Erfolg modularer Architekturen erhoben. Die Ergebnisse sind ernüchternd vertraut: fehlender ROI-Nachweis, Widerstand gegen Veränderung, fehlendes Leadership-Sponsoring. Keine dieser Barrieren ist technisch.
Composability verlangt eine Neuordnung der Zusammenarbeit. Redaktion, Design und Entwicklung können nicht mehr in getrennten Workflows operieren, die sich erst im Deployment begegnen. Content Modeling – die Frage, wie Inhalte strukturiert, versioniert und kanalübergreifend wiederverwendbar gemacht werden – ist keine technische Detailentscheidung. Es ist eine editorische, gestalterische und architektonische Aufgabe zugleich. API-Governance, Release-Koordination, die Pflege und Dokumentation von Schnittstellen: All das erzeugt Aufwände, die in der Kostenplanung eines Composable-Projekts selten auftauchen. CMSWire hat das Phänomen treffend beschrieben: Headless-Architekturen erhöhen die organisatorische Last, weil Teams den gesamten Presentation Tier „voll besitzen" müssen – mit allem, was das an Expertise, Personal und Projektplanung bedeutet.
Und es entstehen Rollen, die in klassischen Organisationen nicht existieren: der Content Architect, der die Brücke zwischen Redaktion und Datenmodell schlägt; der Platform Engineer, der die Composable-Infrastruktur als Produkt betreibt; der DX Owner, der Developer Experience zum strategischen Faktor macht. Eine MDPI-Newsroom-Studie aus 2024 bestätigt: Entwickler müssen „fully integrated" mit Redaktionsteams arbeiten. Der erwartete Skill-Shift ist erheblich. Gleichzeitig zeigt das Reuters Institute, dass gerade einmal 9 Prozent der befragten Organisationen über Trainingsprogramme verfügen, die auf diesen Wandel vorbereiten. Die Lücke zwischen dem, was Composable verlangt, und dem, was Organisationen bereitstellen, ist keine Randnotiz. Sie ist der Kern des Problems.
Das Scheitern beginnt selten spektakulär. Es beginnt mit Abteilungsdenken – jenem Muster, in dem jede Einheit für sich optimiert, nicht für das Gesamtsystem. Die Redaktion wählt das CMS nach Usability, die Entwicklung nach Developer Experience, das Marketing nach Feature-Set, die IT nach Sicherheit und Compliance. In einer Suite kaschiert der gemeinsame Rahmen des Produkts diese Fragmentierung. In einer Composable-Architektur wird sie zum Systemrisiko.
Dazu kommt eine doppelte Kompetenzlücke, die selten offen adressiert wird. Auf Redaktionsseite fehlt häufig das technische Verständnis für Strukturierung, API-Logik und die Konsequenzen von Content-Modellierungsentscheidungen. Auf Entwicklungsseite fehlt das inhaltliche Verständnis dafür, wie redaktionelle Arbeit funktioniert, welche Workflows produktivitätskritisch sind und warum ein technisch elegantes System, das die Redaktion nicht bedienen kann, kein gutes System ist. Composable schließt diese Lücke nicht. Es vertieft sie, weil die Abstraktionsschichten zwischen den Disziplinen zunehmen.
Die gravierendste Schwachstelle ist die Governance-Lücke. In vielen Organisationen gibt es schlicht keine Instanz, die für das Zusammenspiel des Gesamtsystems verantwortlich ist. Einzelne Komponenten werden verantwortet, das Zusammenwirken nicht. Storyblok hat im „State of CMS Report 2024" ein Symptom dieses Problems quantifiziert: 47 Prozent der befragten Unternehmen betreiben zwei bis drei CMS parallel, 27 Prozent sogar vier bis fünf. Nur 19 Prozent arbeiten zentralisiert mit einem System. Das sind keine bewussten Multi-CMS-Strategien. Das sind Sedimentschichten gescheiterter Konsolidierungsbemühungen.
Der ökonomische Schaden ist real. McKinsey hat erhoben, dass Unternehmen im Schnitt nur 31 Prozent des erwarteten Umsatzhebels und 25 Prozent der erwarteten Kosteneinsparungen aus Transformationsprojekten realisieren. Das PMI beziffert verschwendete Projektinvestitionen durch schlechte Projektleistung auf 5,2 Prozent – bei schwachen „Power Skills" steigt der Waste auf 8,8 Prozent. Übersetzt in die Realität eines Composable-Programms: doppelte Kosten für redundante Systeme, sinkende redaktionelle Produktivität und ein wachsendes Shadow-IT-Ökosystem, in dem Teams sich die Werkzeuge besorgen, die ihnen das offizielle System nicht bietet. Shadow-IT ist nie Rebellion. Shadow-IT ist Feedback.
Das Bemerkenswerte am Scheitern von Composable-Projekten ist seine Stille. Kaum ein Unternehmen erklärt öffentlich, dass die modulare Architektur nicht funktioniert hat. Stattdessen passiert etwas Subtileres: Die Composable-Architektur bleibt bestehen, wird im Alltag aber wie ein Monolith betrieben. Komponenten werden nicht ausgetauscht, sondern über Jahre mitgeschleppt. Die theoretische Austauschbarkeit wird nie genutzt. Das Content-Modell erstarrt, weil niemand die Konsequenzen einer Änderung über alle Kanäle hinweg abschätzen kann. Der „Zombie-Stack" entsteht: technisch modular, operativ erstarrt, wirtschaftlich teurer als die Suite, die er ablösen sollte.
Branchenbeobachter dokumentieren zunehmend eine Gegenbewegung: „MACH-lash" oder „Headless Regret". Practitioner berichten von Rückmigrationen zu integrierten Suiten – nicht aus technischer Überzeugung, sondern wegen unkontrollierbarer Total Cost of Ownership und zusammengebrochener Workflows. In der MACH-Debatte ist zunehmend von „hidden costs" und „operational overload" die Rede, von Millionenaufwänden für Custom-Workflows, die in einer Suite out of the box verfügbar gewesen wären.
Dieser Rückschritt hat einen rationalen Business Case. Eine gut operierende, limitierte Suite, in der Teams produktiv arbeiten, ist betriebswirtschaftlich überlegen gegenüber einer gescheiterten Composable-Vision, die auf dem Papier flexibler ist, aber in der Praxis niemanden befähigt. BCG hat unter 860 Senior Executives erhoben, dass nur etwa ein Drittel der digitalen Transformationen ihren Zielwert erreicht und nachhaltige Veränderung erzeugt. Zwei Drittel enden unterhalb der Ambition – oder lösen sich still in organisatorische Indifferenz auf.
Das härteste Urteil über eine Architekturentscheidung ist nicht das Scheitern. Es ist die Irrelevanz. Wenn ein System steht, läuft, Kosten verursacht – und trotzdem niemand damit arbeitet, wie es gedacht war, dann hat nicht die Technologie versagt. Dann hat die Organisation eine Frage nicht beantwortet, die vor jeder Technologieentscheidung hätte stehen müssen: Können wir das betreiben?
Die ehrlichste Empfehlung ist keine technische. Sie lautet: Organisatorische Readiness als Vorbedingung für Architekturentscheidungen behandeln – nicht als parallelen Workstream, der „mitlaufen" soll. Bevor die Frage nach dem CMS, der API-Plattform oder dem Frontend-Framework steht, müssen andere Fragen beantwortet sein. Gibt es klare Ownership für jede Komponente – nicht nur technisch, sondern redaktionell und wirtschaftlich? Existieren die Rollen, die eine Composable-Architektur im Alltag braucht, oder werden sie erst geschaffen? Können Redaktion und Entwicklung integriert arbeiten, oder operieren sie in getrennten Welten mit getrennten Zielsystemen?
Prosci liefert den vielleicht überzeugendsten Datenpunkt für die Priorität des Organisatorischen: Bei exzellentem Change Management erreichen 88 Prozent der Projekte ihre Ziele. Bei schlechtem Change Management sind es 13 Prozent. Kein gradueller Unterschied. Ein Faktor sieben. Der wichtigste Einzelfaktor dabei ist laut Prosci „active and visible sponsorship" – sichtbare, aktive Unterstützung durch die Führungsebene. Nicht ein Steering Committee, das quartalsweise tagt. Sondern Führungskräfte, die den Wandel verkörpern, Konflikte eskalieren lassen und Entscheidungen treffen, bevor sie sich in Abstimmungsschleifen auflösen.
Change Management gehört deshalb nicht in einen separaten Beratungsauftrag, der parallel zur Implementierung läuft. Es gehört in die Architekturplanung selbst. Wer eine Composable-Architektur plant, plant gleichzeitig einen Organisationsumbau. Wer das nicht tut, plant einen Zombie-Stack.
Der dritte Hebel ist der Verzicht auf den Big Bang. Pilotprojekte, die klein genug sind, um Scheitern zu erlauben, und groß genug, um organisatorisches Lernen zu erzeugen, sind der einzige Weg, die Readiness einer Organisation empirisch zu testen – nicht auf Basis von Selbsteinschätzungen in Workshops, sondern auf Basis von realer Zusammenarbeit an einem realen Produkt. Schrittweise Einführung ist keine Verzögerung. Sie ist Investitionsschutz.
Und manchmal ist die richtige Entscheidung, Composable nicht einzuführen. Nicht weil die Technologie schlecht wäre. Sondern weil die Organisation heute nicht die ist, die diese Technologie braucht. Das ist kein Eingeständnis von Schwäche. Es ist die reifste Form von Technologiekompetenz: zu wissen, was man betreiben kann – und was nicht.
Dieser Artikel handelt vordergründig von Architekturentscheidungen. Tatsächlich handelt er von der Frage, ob Organisationen Content als Infrastruktur begreifen – oder weiterhin als Oberfläche behandeln, die am Ende des Projekts „befüllt" wird. Composable-Architekturen scheitern genau dort, wo Content als nachgelagert gilt: als etwas, das Redaktionen „reinpflegen", nachdem die eigentliche Arbeit getan ist. Die Serie „Content als Betriebssystem" untersucht, was passiert, wenn man diesen Gedanken umdreht. Wenn Content nicht das ist, was auf Infrastruktur läuft – sondern selbst Infrastruktur ist. Der nächste Artikel wird unbequemer. Falls dieser hier schon unbequem war: gut. Das war die Aufwärmübung. Falls nicht – Sie haben entweder alles im Griff, oder Sie haben nicht genau genug hingesehen. Beides lohnt sich herauszufinden.
