Generation 4: Die 25-Jahre-Evolution vom Monolithen zum Frontend as a Service
- 1.Generation 1: Der Monolith (2000 bis 2010)
- 2.Generation 2: Headless Commerce (2011 bis 2018)
- 3.Generation 3: Composable Frontends (2019 bis 2023)
- 4.Generation 4: Frontend as a Service (FaaS) (2023 bis 2026)
- 5.Die vier Generationen im Überblick
- 6.Was der Wechsel des Betriebsmodells für Teams wirklich bedeutet
- 7.FAQ
- 8.Nächster Schritt
Commerce-Frontends sind nicht in einem einzigen Release-Zyklus vom Monolithen zum modernen Stack gesprungen. Sie haben sich über rund 25 Jahre durch vier klar unterscheidbare Generationen entwickelt, und jede Generation existiert, weil sie das Problem der vorherigen gelöst hat. Zu wissen, in welcher Generation dein Storefront tatsächlich läuft, und nicht in welcher der Vertriebsslide des Anbieters, ist der schnellste Weg, das nächste Replatforming zu planen, ohne die Fehler des letzten zu wiederholen.
Generation 1: Der Monolith (2000 bis 2010)
Die erste Generation von Commerce-Plattformen, darunter Demandware (heute Salesforce Commerce Cloud), ATG und hybris, bündelte Backend-Logik, Templating und Rendering in einer einzigen Anwendung. Eine Änderung an der Landingpage bedeutete einen Template-Edit, einen QA-Zyklus und ein Release-Fenster, das in Wochen gemessen wurde. Marketing war vollständig von der IT-Kapazität abhängig, und jede Kampagne konkurrierte mit jedem anderen Backlog-Item um denselben Release-Slot.
Generation 2: Headless Commerce (2011 bis 2018)
Generation 2 hat das Backend von der Präsentationsschicht entkoppelt. commercetools brachte API-first-Commerce, Shopify Plus öffnete seine Storefront API, und BigCommerce folgte mit eigenen Headless-Optionen. Der Vorteil war real: Teams konnten endlich ein Best-of-Breed-Backend wählen, ohne dessen Templating-Engine zu erben. Der Haken: Irgendjemand musste das Frontend trotzdem von Grund auf bauen, meist ein dediziertes React- oder Vue-Team, und genau dieses Team wurde zum neuen Engpass. Marketing hat weiterhin Tickets eingereicht, nur bei einem anderen Backlog.
Generation 3: Composable Frontends (2019 bis 2023)
Die MACH Alliance hat den Begriff 2020 formalisiert, und eine Welle komponentenbasierter Tools folgte: Vue Storefront, Frontastic und Framework-Starter-Kits auf Basis von Next.js. Frontends wurden zu Zusammenstellungen austauschbarer Teile statt eines kompletten Custom-Builds, was die Entwicklungszeit spürbar verkürzt hat. Aber ein composable Frontend bedeutete weiterhin eine In-House-Codebase, die Engineering besaß, deployte und wartete. Einen neuen Section-Typ hinzuzufügen oder eine Hero-Komponente auszutauschen war schneller als in Generation 2, blieb aber ein Sprint-Ticket.
Generation 4: Frontend as a Service (FaaS) (2023 bis 2026)
Frontend as a Service verschiebt das Frontend von etwas, das ein Team zusammenbaut, zu etwas, das eine Plattform betreibt. Eine Frontend Management Platform (FMP) liefert Storefront, visuellen Editor und Release-Pipeline als ein einziges, EU-gehostetes Produkt. Marketing bearbeitet Sections direkt in Studio, Engineering behält die Verantwortung für Design-System und Integrationsschicht, nicht für jede einzelne Content-Änderung. Das ist das FaaS-Commerce-Modell: Composable bleibt darunter erhalten (Backend, Suche und PIM bleiben austauschbar), während die Frontend-Schicht vom Ding wechselt, das dein Team baut, zum Service, auf dem dein Team arbeitet.
Die vier Generationen im Überblick
| Generation | Ära | Frontend-Ownership | Typische Release-Kadenz | Beispiel-Stacks |
|---|---|---|---|---|
| 1. Monolith | 2000 bis 2010 | Vendor-Template-Engine | Wochen bis Monate | Demandware, ATG, hybris |
| 2. Headless | 2011 bis 2018 | In-House Custom-Build | Wochen | commercetools, Shopify Plus |
| 3. Composable | 2019 bis 2023 | In-House, aus Komponenten zusammengesetzt | Tage | Vue Storefront, Frontastic, Next.js Commerce |
| 4. Frontend as a Service | 2023 bis 2026 | Gemanagte Plattform, editiert von Marketing | Stunden | Laioutr FMP |
Was der Wechsel des Betriebsmodells für Teams wirklich bedeutet
Das ist eine Commerce-Frontend-Evolution in der Ownership genauso wie in der Technologie. In Generation 1 bis 3 lautete die Antwort auf „Wer kann das Frontend ändern?" fast immer: Engineering. In Generation 4 splittet sich diese Frage: Engineering besitzt Plattform, Integrationen und Design-System über eine composable digital experience platform, während Marketing das Tagesgeschäft am Storefront-Content übernimmt. Dieser Split wird relevanter, sobald agentische Tools ins Spiel kommen: Eine agentic frontend management platform kann Section-Änderungen vorschlagen oder unterperformende Seiten markieren, aber jemand braucht weiterhin eine governte, EU-gehostete Umgebung, um das Ergebnis ohne Deploy zu veröffentlichen. Was überhaupt als FMP zählt, erklären wir ausführlicher unter was eine Frontend Management Platform eigentlich ist. Wenn ihr noch früher in der FaaS-Recherche steht, führt unser Begleitartikel durch die FaaS-Kategorie ab der Definition.
FAQ
Was ist Frontend as a Service (FaaS)? Frontend as a Service ist die vierte Generation der Commerce-Frontend-Architektur: Storefront, visueller Editor und Release-Pipeline werden als gemanagter, EU-gehosteter Service geliefert statt als Codebase, die dein Team selbst zusammenbaut und betreibt.
Ist FaaS dasselbe wie Composable Commerce? Nein. Composable Commerce beschreibt austauschbare Backend-Services (Commerce-Engine, Suche, PIM, CMS). FaaS beschreibt, wie die Frontend-Schicht darüber betrieben wird. Ein composable Frontend kann weiterhin selbst gebaut sein, ein FaaS-Frontend wird für dich gemanagt, beide Kategorien ergänzen sich, statt zu konkurrieren.
Verlieren wir Flexibilität, wenn wir zu einem gemanagten Frontend wechseln? Nicht auf der Backend-Seite. Euer commercetools-, Shopify- oder Shopware-Backend bleibt genauso austauschbar wie in Generation 3. Was sich ändert: Euer Team pflegt keine Frontend-Infrastruktur mehr, sondern konfiguriert eine Plattform.
Wie passt FaaS zu einem bestehenden commercetools- oder Shopify-Backend? FaaS-Plattformen verbinden sich mit bestehenden composable Backends über APIs, genau wie ein Custom-Frontend aus Generation 3 das tun würde. Der Unterschied: Verbindungsschicht, Hosting und Editor sind bereits gebaut und gewartet, wodurch sich der Integrationsaufwand auf euren spezifischen Katalog und eure Checkout-Logik beschränkt statt auf den gesamten Frontend-Stack.
Wie sieht ein Replatforming zu Generation 4 in der Praxis aus? Meist beginnt es bei den Templates mit dem höchsten Traffic (Produktliste, Produktdetail, Landingpages), Section für Section migriert statt als Big-Bang-Umstellung, während das bestehende Frontend weiter Traffic bedient. Die meisten Teams lassen Backend- und Suchintegrationen während des Wechsels unverändert.
Nächster Schritt
Wenn dein Team für Section-Änderungen an einem Generation-2- oder Generation-3-Frontend noch Tickets einreicht, ist der schnellste Weg, Generation 4 in der Praxis zu sehen, die Frontend as a Service Plattform zu entdecken.