Ist Composable Commerce das neue Legacy? Wenn moderne Architekturen zur Altlast werden
In der IT-Welt gilt ein System als „Legacy“, wenn es veraltet, schwer wartbar und mit modernen Anforderungen nur noch bedingt kompatibel ist. Diese Definition trifft oft auf monolithische Systeme wie SAP Hybris oder IBM WebSphere zu – Plattformen, die über Jahre gewachsen sind, aber heute durch ihre Komplexität und Starrheit ausbremsen.
Doch was, wenn das eigentliche Problem nicht das Alter, sondern die Architektur ist?
In Zeiten von Cloud, Microservices und API-First denken viele Unternehmen, sie hätten das Thema Legacy hinter sich gelassen – schließlich setzen sie auf moderne, sogenannte „Composable“ Commerce-Architekturen. Doch genau hier liegt der Denkfehler: Auch eine modulare Lösung kann zum Ballast werden, wenn sie sich über Jahre mit Individualentwicklungen und schwer zu pflegenden Integrationen aufbläht.
Legacy ist kein Zustand vergangener Technologien. Legacy ist ein Zustand mangelnder Anpassungsfähigkeit.
Und genau deshalb ist es an der Zeit, den Begriff neu zu denken – und die eigene Architektur kritisch zu hinterfragen.
TL;DR
Composable Commerce löst klassische Monolithen ab – doch ohne Prozessführung und bei wachsender Komplexität droht die nächste Legacy-Falle.
- Auch moderne Composable-Architekturen können durch Fragmentierung und Individualentwicklungen zum Ballast werden.
- Begriffe wie „composable regret“ und „MACH-lash“ beschreiben das böse Erwachen bei unvorbereiteter Einführung.
- Fehlende zentrale Orchestrierung macht Commerce-Prozesse schwer steuerbar und wenig anpassungsfähig.
- Prozessintelligente Architekturen mit klarer Steuerung und Low-Code-Komponenten bieten einen nachhaltigen Ausweg.
- Emporix zeigt mit seiner Orchestration Engine, wie Flexibilität und Kontrolle wieder zusammenfinden.
Die Schattenseite von Composable Commerce
Composable Commerce gilt als die Antwort auf starre Monolithen: modular, flexibel, API-first. Ein Versprechen, das sich auf dem Papier hervorragend liest. In der Praxis zeigt sich jedoch: Auch die modernste Architektur ist kein Garant für langfristige Agilität.
Was als Befreiungsschlag beginnt, endet oft in einem neuen Geflecht aus Abhängigkeiten.
Viele Unternehmen unterschätzen den Aufwand, der mit der Integration zahlreicher Best-of-Breed-Lösungen einhergeht. Jede neue Komponente bringt eigene APIs, eigene Release-Zyklen, eigene Konfigurationslogiken mit. Und irgendwann kippt das Ganze: Statt mehr Flexibilität entstehen neue Komplexitäten – und mit ihnen dieselben Symptome wie bei klassischen Legacy-Systemen.
Besonders kritisch wird es, wenn für jede Abweichung vom Standardprozesse individuelle Logik entwickelt wird. Diese Individualentwicklungen – oft als notwendige Anpassungen gerechtfertigt – sammeln sich wie technischer Staub an. Sie sind nicht dokumentiert, kaum testbar, schwer wartbar. So wächst über Monate und Jahre ein neuer „Custom Code“-Friedhof heran – genau das, was man ursprünglich vermeiden wollte.
Dieses Phänomen hat inzwischen einen Namen: „composable regret“ – das böse Erwachen, wenn man merkt, dass man die architektonische Freiheit nicht beherrscht, sondern von ihr überfordert ist. Oder wie es Gartner-Analyst Mike Lowndes formuliert: „MACH-lash“ – der schmerzhafte Rückschlag, wenn man zu früh auf MACH-Standards wie Microservices, API-first und Headless gesetzt hat, ohne die nötige Reife dafür mitzubringen.
Kurz: Auch Composable kann zur Falle werden. Nicht durch das Prinzip, sondern durch fehlende Steuerung, mangelnde Prozesskompetenz und wuchernde Individualisierungen.
Wenn Modularität zur Last wird
Modularität ist kein Selbstzweck – sie ist ein Mittel zur Flexibilisierung. Doch sobald die einzelnen Module nicht mehr sauber orchestriert, sondern individuell verknüpft werden, kehrt sich der Vorteil ins Gegenteil: aus Modularität wird Fragmentierung. Und Fragmentierung erzeugt Aufwand.
In vielen Unternehmen entstehen isolierte Prozesslogiken, die tief in Code-Silos verborgen sind. Eine Preislogik, die in einem Microservice lebt. Eine Promotion-Logik, die in einem Drittsystem liegt. Eine Rückabwicklung, die als Workaround im ERP gepflegt wird. Was zunächst wie flexible Anpassung wirkt, wird bei der ersten Änderung zur Mammutaufgabe. Denn nichts greift sauber ineinander – und jede kleine Optimierung wird zum Projekt. An dieser Stelle zeigen sich zwei entscheidende Schwächen vieler composable Systeme:
- Fehlende zentrale Steuerung: Es gibt kein übergeordnetes Prozessverständnis. Jeder Dienst tut, was er soll – aber niemand sieht das Ganze.
- Komplexität durch Individualentwicklungen: Jede notwendige Anpassung erzeugt neuen Code. Und dieser Code wächst – mit jedem Sprint, jeder Anforderung, jeder Iteration.
Die Folgen davon kennen viele, Zeit, Budget und Know-how fließen nicht in Innovation, sondern in die Aufrechterhaltung der Komplexität.
Das Paradoxe: Die Unternehmen haben technisch alles richtig gemacht. Sie haben modernisiert, auf Microservices gesetzt, APIs geschaffen. Und doch stecken sie wieder fest – in einem neuen Legacy.
Die Lösung: Prozessintelligente Architekturen
Wenn technische Modernisierung allein nicht reicht – was dann?
Die Antwort liegt nicht in noch mehr Services, APIs oder Tools. Sie liegt in einer höheren Ebene: Prozessorchestrierung. Gemeint ist eine Architektur, in der Prozesse nicht implizit im Code verborgen sind, sondern explizit modelliert, gesteuert und kontinuierlich weiterentwickelt werden können – unabhängig von den darunterliegenden Systemen.
Diese Art der Architektur ist nicht neu, aber sie ist für Commerce-Systeme bislang selten konsequent umgesetzt worden. Genau hier entsteht der Unterschied zwischen einem wirklich zukunftsfähigen Setup – und einem nur modern aussehenden Legacy-Konstrukt.
Was unterscheidet eine prozessintelligente Architektur?
- Zentrale Prozesslogik statt verteilter Workarounds.
- No-/Low-Code-Tools statt dauerhafter Individualentwicklungen.
- Sichtbare, veränderbare Abläufe statt technischer Blackboxes.
- Inkrementelle Weiterentwicklung ohne Plattformwechsel oder Downtime.
Das Ergebnis: Unternehmen gewinnen die Kontrolle über ihre Commerce-Prozesse zurück. Statt sich von Technik treiben zu lassen, treiben sie aktiv die Technik – und damit ihr Geschäft.
Ein gutes Beispiel dafür ist Emporix mit seiner Orchestration Engine (OE): Hier wird nicht nur die Funktionalität modular aufgebaut, sondern auch die Prozesslogik zentral steuerbar gemacht – visuell, nachvollziehbar, agil. So lassen sich neue Customer Journeys, Preislogiken oder Kampagnenprozesse innerhalb weniger Stunden anpassen – ganz ohne tiefgreifende Individualentwicklungen.
Fazit: Zeit für ein neues Verständnis von Legacy
Legacy ist kein technologisches Alter. Es ist ein architektonisches Problem.
Und dieses Problem tritt heute nicht nur in klassischen Monolithen auf, sondern zunehmend auch in modernen Composable-Stacks – dann, wenn sie ohne klare Prozessführung und mit wachsendem Custom Code operieren.
Die gute Nachricht: Es geht auch anders. Wer seine Commerce-Plattform nicht nur modular, sondern auch prozessintelligent denkt, gewinnt Entscheidendes:
- Agilität, um schnell auf Marktveränderungen zu reagieren.
- Kostenkontrolle, weil weniger individuelle Codepflege notwendig ist.
- Innovationstempo, weil neue Ideen direkt umgesetzt werden können.
- Und vor allem: Freiheit, weil Prozesse nicht mehr im System verborgen liegen, sondern im Zentrum der Steuerung stehen.
