Suite oder Composable ist keine Technikfrage – es ist eine Aussage über deine Organisation und ihren Zeithorizont.
Ein CTO, Donnerstagabend, leerer Schreibtisch bis auf zwei Architekturdokumente. Das eine kommt von einem Suite-Anbieter: eine Plattform, ein Vertrag, ein Ansprechpartner. Das andere von einem Beratungshaus: modulare Architektur, lose gekoppelte Services, maximale Flexibilität. Beide Dokumente sind schlüssig. Beide Verkäufer waren überzeugend. Und trotzdem wird er heute Nacht schlecht schlafen, weil beide Versprechen einen Preis haben, der nirgendwo auf den Folien steht.
Die Suite verspricht Geschwindigkeit durch Integration. Alles spricht miteinander, weil alles von einem Hersteller kommt. Das CMS kennt die Personalisierungsengine, der Commerce-Layer kennt die Analytics, und wenn etwas nicht funktioniert, gibt es eine Telefonnummer. Für Unternehmen, die digitale Produkte bauen wollen, ohne vorher eine Plattformabteilung aufzubauen, ist das ein ernstes Argument.
Composable verspricht Freiheit durch Entkopplung. Jede Komponente einzeln austauschbar, jede Schicht unabhängig skalierbar, keine Abhängigkeit von der Roadmap eines einzelnen Anbieters. Für Unternehmen, die schneller innovieren wollen, als ein Suite-Anbieter Releases plant, ist auch das ein ernstes Argument.
Beide Versprechen stimmen. Und beide lügen.
Die Suite lügt, wenn sie suggeriert, dass Integration gleich Passgenauigkeit bedeutet. Dass ein System, nur weil es alles kann, auch alles gut kann. Die Composable-Seite lügt, wenn sie suggeriert, dass Flexibilität gleich Geschwindigkeit bedeutet. Dass lose Kopplung automatisch zu besseren Ergebnissen führt. Dass Freiheit kostenlos ist.
Die Wahrheit ist unbequemer: Die Entscheidung zwischen Suite und Composable ist keine technische Entscheidung. Sie ist eine Aussage über deine Organisation, ihre Fähigkeiten, ihre Engpässe und ihren Zeithorizont. Peter Drucker hat die einzige Frage formuliert, die dabei zählt: Nicht was technisch überlegen ist, sondern was du tatsächlich umsetzen kannst.
Die Analysten bestätigen das mit Daten. Forresters aktuelle CMS-Bewertung zeigt, dass Referenzkunden keine klare Präferenz mehr haben – weder für reine Composable-Lösungen noch für klassische Template-Systeme. Die Verteilung ist ausgeglichen. Was Unternehmen bevorzugen, hängt nicht von der Architektur ab, sondern von ihrem Betriebsmodell. Es gibt keinen automatischen Sieger.
„Die besten Composable-Projekte, die wir sehen, starten nicht mit Technologie. Sie starten mit der Frage, welche Entscheidung das Business morgen schneller treffen will." – Wiebke Wefer, Head of Composable bei Triplesense Reply
Carla leitet den Einkauf eines mittelständischen Industrieunternehmens mit 2.000 Mitarbeitern. Vor ihr liegt ein Fünfjahresvertrag für eine Digital-Experience-Plattform eines der großen Anbieter. Das Paket enthält Content Management, Personalisierung, Analytics, Commerce-Funktionen. Ein Anbieter, ein Vertrag, ein Support-Portal. Carla mag das. Ihre IT-Abteilung hat acht Leute, davon zwei Entwickler.
Für Unternehmen wie Carlas ist die Suite kein fauler Kompromiss, sondern eine rationale Entscheidung. Die Integrationskosten fallen weg, weil die Integration bereits stattgefunden hat – im Produkt selbst. Die Verantwortlichkeit ist klar: Wenn etwas nicht funktioniert, gibt es einen Ansprechpartner. Kein Zeigen auf den jeweils anderen Anbieter, kein Debugging an den Schnittstellen zwischen System A und System B. Für regulierte Branchen – Pharma, Finanz, öffentlicher Sektor – kommt hinzu, dass ein geschlossenes System leichter zu auditieren ist als ein Netzwerk aus zwölf einzelnen Services.
Aber reif heißt auch: langsam.
Der Preis der Suite wird sichtbar, wenn sich Anforderungen ändern. Wenn das Marketing-Team einen neuen Kanal bespielen will, den die Plattform noch nicht unterstützt. Wenn die Suche nicht gut genug ist, aber die integrierte Suchfunktion nicht gegen eine bessere Alternative ausgetauscht werden kann, ohne das gesamte System zu destabilisieren. Wenn die Roadmap des Anbieters nicht zur eigenen Geschäftsstrategie passt und man trotzdem daran gebunden ist. Der Fünfjahresvertrag, der Carla Sicherheit gibt, ist auch ein Fünfjahresversprechen an eine Zukunft, die niemand kennt.
Und dann die Zahl, über die niemand gerne spricht: Unternehmen nutzen im Durchschnitt nur 20 bis 30 Prozent der Funktionen, die sie in einer Suite eingekauft haben. Der Rest ist bezahlte Optionalität, die nie eingelöst wird. Kein Implementierungsfehler. Das Geschäftsmodell. Suiten verkaufen Umfang, nicht Passung.
Forrester bestätigt das Muster: Suiten sind „best fit for large enterprises" – für Organisationen mit etablierten Operating Models, die Skalierung brauchen, nicht Experimente. Das ist Carlas Welt. Für ihr Unternehmen – acht IT-Leute, klarer Scope, überschaubare Kanalanforderungen – kann das der richtige Weg sein. Die Suite funktioniert, wenn die Organisation nicht die Fähigkeit oder den Willen hat, ihre eigene digitale Infrastruktur zu orchestrieren. Keine Schwäche. Eine ehrliche Selbsteinschätzung.
Martin ist Dev Lead bei einem digitalen Handelsunternehmen. Sein Team hat vor achtzehn Monaten die Migration von einer monolithischen Plattform hin zu einer modularen Architektur begonnen. Headless CMS, entkoppelter Commerce-Layer, spezialisierte Such-Engine, eigene Personalisierungslogik. Auf dem Papier: technologische Freiheit, unabhängige Deployments, keine Abhängigkeit von einem einzigen Anbieter. In der Realität: Martin hat in den letzten sechs Monaten drei Entwickler verloren, weil sie keine Features mehr bauen, sondern nur noch Integrationen pflegen.
Composable bedeutet, dass jede Komponente des digitalen Stacks einzeln gewählt, einzeln betrieben und einzeln ausgetauscht werden kann. Ein spezialisiertes CMS für Content, ein spezialisiertes System für Commerce, ein spezialisiertes Tool für Suche. Jede Komponente kommuniziert über APIs. Die Theorie ist überzeugend: Wenn sich die Anforderungen an die Suche ändern, tauschst du die Such-Komponente aus, ohne den Rest des Systems anzufassen. Wenn ein Anbieter stagniert, wechselst du ihn, ohne Migration, ohne Replatforming, ohne Fünfjahresverträge.
Die Daten stützen den Trend, und er beschleunigt sich. Das Marktsegment für Headless-CMS-Lösungen wächst mit über 22 Prozent jährlich und soll sich bis 2035 versiebenfachen. Gartner hat Composability zur zwingenden Voraussetzung für die Aufnahme in seinen DXP-Quadranten erhoben – kein Nice-to-have mehr, sondern Pflicht.
Die Ergebnisse können beeindruckend sein, wenn die Organisation sie tragen kann. Virgin Media O2 zeigt das am deutlichsten: Nach der Fusion zweier Telekommunikationsunternehmen baute ein composable Ansatz die neue Website in 24 Stunden auf, eliminierte sechsstellige Overhead-Kosten durch wiederverwendbare Content-Blöcke und spart seither im Millionenbereich jährlich. Ein europäischer Kontext, eine nachvollziehbare Business-Situation, ein klarer Auftrag. Das ist eine Herstellerreferenz, keine unabhängig auditierte Studie. Aber sie zeigt, was in Organisationen mit starkem Engineering und klarem Auftrag möglich ist.
Aber die Frage ist nicht, ob Composable funktioniert. Die Frage ist, für wen.
Was in der Composable-Erzählung fehlt, ist der organisatorische Preis. Jede API ist eine Schnittstelle, die jemand verantworten muss. Jede Komponente braucht Monitoring, Versionierung, Sicherheits-Updates. Jede Austauschbarkeit setzt voraus, dass jemand die Abstraktionsschicht dazwischen sauber gebaut hat. Kritiker warnen seit Jahren vor dem „Meer aus APIs" und dem Operational Overload, der entsteht, wenn die Freiheit der Architektur die Fähigkeit der Organisation übersteigt. Selbst Befürworter modularer Ansätze sagen es offen: „Composability ist kein Allheilmittel – es ist eine Wahl."
Martin weiß das inzwischen. Sein Team verbringt geschätzt ein Drittel seiner Zeit nicht mit Produktentwicklung, sondern mit der Verwaltung technischer Schulden, die aus der Architektur selbst entstehen. Die Lizenzkosten sind tatsächlich niedriger als bei der Suite. Aber die Teamkosten sind drastisch höher. Nicht weil die Technologie schlecht wäre, sondern weil seine Organisation – 15 Entwickler, kein dediziertes Platform-Engineering-Team – für den Betrieb einer vollständig entkoppelten Architektur nicht ausgelegt ist.
„Composable ist kein Upgrade – es ist ein anderes Betriebsmodell. Wer das unterschätzt, tauscht Vendor Lock-in gegen Self-Made Lock-in." – Wiebke Wefer, Head of Composable bei Triplesense Reply
Die Debatte zwischen Suite und Composable wird geführt, als gäbe es nur zwei Türen. In der Praxis stehen die meisten Unternehmen in einem Flur mit Dutzenden von Türen, Durchgängen und Kompromissen. Die klügsten von ihnen haben aufgehört, sich für eine Seite zu entscheiden.
Die Konvergenz ist nicht mehr nur sichtbar, sie ist Marktstandard. Suite-Anbieter haben ihre Plattformen so weit geöffnet, dass die alte Trennlinie technisch kaum noch existiert. Das größte DXP-System am Markt dokumentiert sich inzwischen selbst als Headless-CMS mit GraphQL-API. Was vor drei Jahren noch ein Architekturstreit war, ist heute ein Konfigurationsparameter. Gleichzeitig bewegt sich die Composable-Seite in die Gegenrichtung. Was als lose Sammlung von Spezialtools begann, wird zunehmend in vorkonfigurierten Bündeln angeboten – mit gemeinsamer Administrationsoberfläche, abgestimmtem Onboarding, reduzierten Integrationspunkten. Der Markt nennt das „Pragmatic Composability". Der Begriff trifft es.
Es gibt Unternehmen, die einen Suite-Kern betreiben und einzelne Schichten gezielt durch spezialisierte Komponenten ersetzen – die Suche, die Personalisierung, das Asset Management. Sie kaufen sich die Stabilität und den Support der Suite, ohne auf Flexibilität dort zu verzichten, wo sie strategisch wichtig ist. Andere starten composable und merken unterwegs, dass bestimmte Integrationen so eng gekoppelt sind, dass sie de facto eine Suite nachbauen – nur ohne den Support.
Und dann die Warnsignale aus der anderen Richtung. Segment, ein Unternehmen, das für seine Microservice-Architektur bekannt war, ging den umgekehrten Weg: 140 Microservices zurück in einen Monolithen. Die Entwickler verbrachten den Großteil ihrer Zeit mit Deployment-Synchronisation statt mit Features. Diese Beispiele sind kein Argument gegen Composable. Sie sind ein Argument gegen Dogmatismus.
Die relevante Entscheidung ist selten „Suite oder Composable". Sie lautet: Welche Schichten meiner digitalen Infrastruktur brauchen Stabilität, und welche brauchen Beweglichkeit? Wo ist ein Wechsel wahrscheinlich, und wo wäre er ein Risiko? Die Antwort sieht für jedes Unternehmen anders aus und verändert sich über die Zeit.
Es gibt einen Grund, warum die Suite-vs.-Composable-Debatte nicht aufhört. Beide Seiten haben Recht. Die Debatte dreht sich im Kreis, weil sie die falsche Frage stellt. Sie fragt: Was ist besser? Statt: Was passt zu uns?
„Die ehrlichste Frage, die wir Kunden stellen, ist nicht: Suite oder Composable? Sondern: Was kann euer Team am Montag danach tatsächlich betreiben?" – Wiebke Wefer, Head of Composable bei Triplesense Reply
Vier Fragen bilden den Entscheidungsrahmen. Keine davon ist technisch.
Wie viel Kontrolle brauchen wir wirklich? Kontrolle über den Stack klingt gut. Aber Kontrolle, die niemand ausübt, ist keine Kontrolle, sondern Risiko. Wenn dein Team die Architektur nicht versteht, die es betreibt, hast du keine Kontrolle gewonnen. Du hast sie abgegeben – nur eben an den Zufall statt an einen Anbieter. Die Suite gibt Kontrolle ab, aber an einen benennbaren Ort. Composable verteilt Kontrolle und damit auch die Verantwortung.
Welche Innovationsgeschwindigkeit ist realistisch? Nicht die gewünschte. Die realistische. Ein Unternehmen, das heute zwei Releases pro Quartal schafft, wird nicht durch eine neue Architektur plötzlich wöchentlich deployen. Die Architektur ermöglicht Geschwindigkeit, aber die Organisation muss sie tragen können. Die Barrieren sind bekannt: 29 Prozent der Unternehmen nennen internen IT-Widerstand als größtes Hindernis bei Architekturveränderungen, 26 Prozent fehlendes Change Management. Keine technischen Probleme.
Wer trägt die Verantwortung für die Integration? In einer Suite ist die Antwort klar: der Anbieter. In einer composable Architektur: du. Und „du" bedeutet konkret ein Team, das Kapazität, Kompetenz und Mandat hat, die Schnittstellen zwischen allen Komponenten dauerhaft zu verantworten. Wenn dieses Team nicht existiert, existiert auch kein composable Stack – nur eine Sammlung von Tools, die niemand zusammenhält.
Auf welchen Zeithorizont optimieren wir? Die Suite optimiert auf die nächsten 18 bis 36 Monate. Schnelle Implementierung, planbare Kosten, geringes Risiko. Composable optimiert auf drei bis fünf Jahre und darüber hinaus – vorausgesetzt, die Organisation investiert in die Fähigkeit, die Architektur weiterzuentwickeln. Die Frage ist nicht, welcher Horizont besser ist. Sondern welcher ehrlich ist.
Aus den Daten lässt sich ein Muster ableiten: Je stärker Umsatz und Kundenerlebnis an produktnahe Innovation gekoppelt sind – Retail, E-Commerce, Telekommunikation, digitale Produktplattformen – desto wahrscheinlicher zahlt sich der Composable-Weg aus. Je stärker Betrieb, Regulierung und konzernweite Standardisierung den Alltag bestimmen, desto tragfähiger ist die Suite oder ein hybrider Ansatz. Kein Gesetz. Aber ein besserer Kompass als jede Analystengrafik.
Diese vier Fragen ergeben kein Rezept. Sie ergeben einen Spiegel. Was er zeigt, ist selten das, was auf den Architekturfolien steht. Er zeigt die Organisation, wie sie tatsächlich ist, nicht wie sie sich in zwei Jahren gerne sehen würde. Und genau aus dieser Bestandsaufnahme entsteht die einzige Architekturentscheidung, die hält: nicht die technisch überlegene, sondern die organisatorisch tragbare.
Suite oder Composable – das war die Frage. Die ehrliche Antwort: Es war nie die richtige Frage. Die richtige Frage ist, ob dein Content als Infrastruktur funktioniert oder als Deko auf einer Plattform klebt, die du nicht kontrollierst. Architektur ist nur das Gehäuse. Was drin läuft, entscheidet.
Wir wissen, dass du bis hierhin gescrollt hast, ohne alles zu lesen. Ist okay. Wir haben den Entscheidungsrahmen trotzdem nicht ans Ende gestellt, damit du ihn findest – sondern damit du ihn brauchst, wenn du oben nochmal anfängst.
Im nächsten Teil rechnen wir das ehrlich durch: Die Ökonomie der Architektur. Mit Zahlen, die in keinem Angebot stehen.
