Jeder spricht über MACH (Microservices, API-first, Cloud-native, Headless). Wenn man den aktuellen Konferenzen und Agentur-Pitches glaubt, ist alles, was kein Composable Commerce ist, bereits tot. Die Realität, die ich aus 20 Jahren E-Commerce-Gräben kenne, sieht anders aus. MACH ist ein fantastisches Konzept – aber es ist nicht der Heilige Gral für jedes Setup. Lass uns ehrlich auf die Partitur schauen: Wann solltest du auf MACH setzen und wann bleibst du besser beim klassischen Monolithen?
Wann du MACH brauchst (Das "Ja!")
1. Du willst dich aus dem Vendor-Lock-in befreien
Bei einem Monolithen machst du dich zu 100 % abhängig von dessen Ökosystem, Pricing und Roadmap. Das Ziel von Composable Commerce ist es, diese radikale Abhängigkeit zu verringern, indem du Bausteine entkoppelst und austauschbar machst. Das erfordert natürlich jemanden, der diese neue Unabhängigkeit auch technisch steuern kann (und genau hier komme ich als Dirigent ins Spiel).
2. Du hast Spezialisten im Orchester
Wenn du intern oder extern für jedes Instrument (Marketing, Suche, PIM) richtig gute Leute hast, dann gib ihnen auch die guten, dedizierten Instrumente (Best-of-Breed). Zwing sie nicht, auf einem schwerfälligen Multi-Instrument zu spielen, das man sich wie eine One-Man-Band auf den Rücken schnallt.
3. Omnichannel ist deine Realität
Du verkaufst nicht nur über einen Webshop, sondern über Apps, Social Commerce, B2B-Portale und vielleicht IoT-Devices. Headless (die Trennung von Frontend und Backend) ist hier keine Kür, sondern Pflicht.
4. Dein Fachbereich braucht Autonomie
Wenn dein Marketing-Team für jede neue Kampagnen-Landingpage ein IT-Ticket schreiben muss, verlierst du wertvolle Time-to-Market. MACH-Ökosysteme geben dem Fachbereich die Kontrolle zurück – vorausgesetzt, die Teams können damit umgehen.
Wann du die Finger davon lassen solltest (Das "Eher nicht")
1. Dein (Fach-)Orchester ist zu klein
Es geht nicht nur um fähige IT-Entwickler. Wenn du im E-Commerce und Marketing insgesamt nur zwei Leute sitzen hast, warum solltest du sie zwingen, in drei oder vier verschiedenen Systemen gleichzeitig zu arbeiten? Das kann ein kleines Team massiv überfordern. Zudem steigt der Grad an Agenturabhängigkeit bei der Systempflege – was dann definitiv kritisch zu prüfen gilt.
2. Du kennst deine wahren Anforderungen nicht
Die meisten wissen gar nicht, was sie wirklich brauchen. Sie sehen Features, verstehen aber oft nicht das tieferliegende Bedürfnis dahinter. Diese Unschärfe ist immer gefährlich, aber in der Monolithen-Welt ist die Auswirkung nicht so dramatisch. Ein komplexes Microservice-Konstrukt zu bauen, das am wahren Bedarf vorbeigeht, ist hingegen ein extrem teurer Irrweg. Ein modernes Monolithensystem verzeiht solche Fehler eher.
3. Das Verständnis der Key-Player fehlt
Hohe Initialkosten und Budgetrisiken gibt es bei klassischen Systemen genauso wie im Composable Commerce. Der große Unterschied: Ein Shopware-Backend glaubt zumindest jeder im Projekt sofort zu verstehen. Composable Commerce ist abstrakter. Wenn das mentale Modell bei den Entscheidern fehlt, birgt diese Architektur enorme Risiken.
Fazit: Das Instrument muss zum Orchester passen
Technologie ist immer nur das Instrument. Wenn du eine Stradivari kaufst, aber niemanden im Orchester hast, der sie spielen kann, wird es furchtbar klingen. Lass dich nicht von Buzzwords in eine Architektur drängen, die dir über den Kopf wächst.
Und ein letzter Rat: Lass dich vor allem bitte nicht von oberflächlichen Gerüchten und Meinungen leiten, was die Total Cost of Ownership (TCO) betrifft. MACH ist nicht automatisch immer teurer als ein Standard-Monolith. Es muss in jedem Fall individuell und ehrlich berechnet werden.
Zusammenarbeit & Leistungen
Ich biete euch an, dass ich einen unabhängigen Status Audit mache, um euer aktuelles oder geplantes Setup objektiv zu bewerten. Und um dauerhaft die richtigen Entscheidungen zu treffen, nutzt mich als Superpower in eurem Board Advisory.