Integrationen per Klick: App Store statt Engineering-TicketTime-to-Market entscheidet sich selten im…
Vor-Integration ist die echte Time-to-Market-Währung
Vor-Integration ist die echte Time-to-Market-Währung
Modularisierung im Backend verkürzt die Zeit bis zum ersten Modul, nicht die Zeit bis zum ersten Umsatz. Der Grund ist Arithmetik: In einem modularen Stack wächst der Integrationsaufwand multiplikativ mit der Zahl der Module, Kanäle und Tools, nicht additiv. Genau diese Kurve entscheidet über Time to Market, und sie wird nicht im Backend flach, sondern im Frontend-Layer, wenn der bereits vor-integriert ist.
Der Markt hat die Backend-Hälfte gelöst
Seit Juli verkauft commercetools seine Plattform in einzeln buchbaren Modulen: Core Commerce mit Cart, Order, Checkout, Customer und B2B auf der einen Seite, Product Catalog mit Product Modeling, Pricing, Inventory und Search auf der anderen. Die Begründung von CEO Doug McNary ist nüchtern und richtig: Unternehmen "can no longer afford to wait years to modernize" (commercetools Press Release).
Wenn selbst der Composable-Platzhirsch sein Kernprodukt in kaufbare Scheiben schneidet, ist die Marktrichtung eindeutig: Modernisierung läuft inkrementell, nicht als Big-Bang-Replatforming. Das ist ein guter Move, und er verschiebt die Engstelle. Denn ein Modul, das keine Oberfläche hat, ist kein Feature, sondern ein API-Endpunkt.
Warum der Aufwand multiplikativ wächst
Die verbreitete Erwartung an modulare Beschaffung lautet: Ich kaufe Modul zwei, also habe ich einmal Modul-zwei-Aufwand. Additiv. In der Praxis liegt der Aufwand nicht im Modul, sondern in seinen Berührungspunkten. Ein Katalog-Modul muss nicht "angebunden" werden, sondern pro Kanal in Listing, Detail, Suche, Filter, Warenkorb-Vorschau und Checkout-Kontext auftauchen. Jeder dieser Punkte kennt Datenformate, Fehlerzustände, Caching-Regeln und Consent-Logik.
Formal ausgedrückt: Die Zahl der Integrationspunkte skaliert mit n Modulen mal m Ausspielkanälen mal k angebundenen Tools. Bei jeder Erweiterung wächst nicht ein Summand, sondern ein Faktor. Das ist der Unterschied zwischen einem Sprint und einem Quartal.
Modellrechnung (keine gemessenen Projektdaten)
Die folgende Aufstellung ist eine reine Modellrechnung zur Illustration der Wachstumsordnung. Sie beruht auf offengelegten Annahmen, nicht auf erhobenen Projektzahlen: n = gebuchte Backend-Module, m = Ausspielkanäle mit eigener Oberfläche, k = angebundene Drittsysteme wie Suche, Analytics, Consent oder Payment. Ein Integrationspunkt ist die Stelle, an der ein Modul in einem Kanal mit einem Tool zusammentrifft und eigenes Verhalten braucht.
- Start: n = 2 Module, m = 1 Kanal, k = 3 Tools. Integrationspunkte (n × m × k): 6. Additive Erwartung (n + m + k): 6.
- Zweites Modul gebucht: n = 3 Module, m = 2 Kanäle, k = 4 Tools. Integrationspunkte: 24. Additive Erwartung: 9.
- Multi-Brand-Ausbau: n = 4 Module, m = 3 Kanäle, k = 5 Tools. Integrationspunkte: 60. Additive Erwartung: 12.
Der Punkt dieser Aufstellung ist nicht die konkrete Zahl, sondern die Ordnung: Zwischen der ersten und der dritten Stufe verdoppelt sich die additive Erwartung, während die Zahl der tatsächlichen Berührungspunkte um den Faktor zehn steigt. Wer die Kurve nicht bricht, bezahlt jedes zusätzliche Modul mit einem eigenen Glue-Sprint. Wie sehr diese Rechnung inzwischen zur Führungsfrage geworden ist, haben wir in Speed-to-Market als nicht verhandelbarer Faktor beschrieben.
Wo Vor-Integration technisch ansetzt
Vor-Integration heißt nicht "wir haben einen Connector". Sie heißt, dass die Multiplikation an einer definierten Stelle abgeschnitten wird. Bei Laioutr liegt diese Stelle im Orchestr- und Connect-Layer: einer Abstraktionsschicht, die Produkt-, Bestands-, Kategorie- und Order-Daten der angebundenen Backends in ein einheitliches, frontend-konsumierbares Datenmodell normalisiert. Über 50 Backends sind darüber unterstützt (Quelle: laioutr.com/why-laioutr).
Für den commercetools-Fall bedeutet das konkret eine GraphQL-Standardanbindung: Der Layer spricht die commercetools-GraphQL-API direkt an, statt pro Modul eine eigene Client-Schicht zu bauen. Was nicht über einen Standard-Connector abgedeckt ist, geht über einen Custom-GraphQL-Fallback in dasselbe Datenmodell. Das ist der architektonisch entscheidende Punkt: Der Fallback erzeugt keinen zweiten Datenpfad, sondern mündet in denselben Contract, den die Komponenten ohnehin konsumieren.
Damit ändert sich die Arithmetik. Ein zusätzlich gebuchtes Backend-Modul trifft nicht mehr auf m mal k offene Integrationsstellen, sondern auf ein bestehendes Schema und eine Komponenten-Bibliothek, die dieses Schema bereits rendert. Der k-Faktor wird auf derselben Ebene gekappt: Über 300 Integrationen liegen im App Store vor-integriert bereit (verifiziert am 29.08.2026), von Suche über Analytics bis Payment, konfigurierbar statt implementierbar.
Die Konsequenz für die Reihenfolge im Projekt haben wir am commercetools-Beispiel ausführlicher aufgeschrieben: Was der Experience-Layer noch braucht.
Was das für Architektur-Teams heißt
Drei Konsequenzen, die sich direkt in Entscheidungen übersetzen lassen.
Erstens: Bewerte Frontend-Optionen nach Grenzkosten, nicht nach Startkosten. Die relevante Frage ist nicht, wie lange das erste Modul bis zur Oberfläche braucht, sondern wie lange das vierte braucht. Ein Eigenbau-Frontend hat oft niedrige Startkosten und konstant hohe Grenzkosten pro Modul und Kanal. Ein vor-integrierter Layer verschiebt Aufwand nach vorn und macht die Grenzkosten klein.
Zweitens: Ziehe die Abstraktionsgrenze bewusst. Wenn jede Komponente das native Schema eines Moduls kennt, ist die Kopplung im Frontend genauso hart wie vorher im Monolithen, nur verteilter. Ein einheitliches Datenmodell ist kein Komfort-Feature, sondern die Bedingung dafür, dass Backend-Module wirklich austauschbar bleiben.
Drittens: Trenne Integration von Konfiguration. Alles, was ein Marketing- oder Growth-Team ohne Deployment anschließen kann, taucht in der n-mal-m-mal-k-Rechnung gar nicht erst auf. Genau das ist der Zweck eines App-Store-Modells: Es überführt Integrationsarbeit in Konfigurationsarbeit. Details zum Datenmodell und den Composables stehen in den Developer Docs.
FAQ
Ist Vor-Integration nicht nur ein anderes Wort für Standard-Connectoren? Nein. Ein Connector löst die Verbindung zu einem System. Vor-Integration löst zusätzlich die Normalisierung auf ein gemeinsames Schema und die Frage, welche Komponenten dieses Schema bereits rendern. Ohne den zweiten Teil bleibt pro Modul und Kanal Arbeit übrig.
Verliere ich damit Zugriff auf Backend-spezifische Features? Nein. Der Custom-GraphQL-Fallback bleibt der Weg für alles, was kein Standard-Connector abdeckt. Der Unterschied ist, dass diese Spezialfälle in dasselbe Datenmodell münden statt einen zweiten Pfad aufzumachen.
Gilt die Rechnung auch bei nur einem Kanal? Bei m gleich eins fällt der Kanal-Faktor weg, die Multiplikation aus Modulen und Tools bleibt. Der Effekt ist kleiner, aber vorhanden. Er wächst, sobald eine zweite Marke, eine zweite Sprache oder ein zweiter Touchpoint dazukommt.
Muss ich mein Backend wechseln, um davon zu profitieren? Nein. Der Layer setzt auf den bestehenden Stack auf. Genau das ist der Punkt: Die Modularisierung im Backend behältst Du, die Multiplikation im Frontend gibst Du ab.
Nächste Schritte
Wenn Du gerade Module einzeln buchst und wissen willst, wie viele Integrationspunkte in Deinem Setup tatsächlich entstehen, rechnen wir das im Architektur-Gespräch gemeinsam durch: an Deinem konkreten n, m und k, nicht am Modell.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Sebastian Langer ist CTO und Co-Founder von Laioutr und verantwortet die Architektur der Frontend Management Platform.