MACH-Architektur sechs Jahre später — Bilanz der Composable-Versprechen

Im Juni 2020 haben Contentful, Commercetools, EPAM und Valtech die MACH Alliance ins Leben gerufen — als Industrieverband und als architektonisches Manifest zugleich. Die vier Buchstaben sollten eine Antwort auf die Schwächen monolithischer Suite-Plattformen wie Adobe Experience Manager, Sitecore oder Salesforce Commerce Cloud sein: Microservices statt Suite, API-first statt UI-gekoppelt, Cloud-native statt On-Premise-Legacy, Headless statt Frontend-Backend-Verschmelzung. Sechs Jahre später, im Mai 2026, ist die Allianz auf rund 90 Mitglieder gewachsen, die Konferenz-Zirkulation hat eine eigene Ökonomie entwickelt, das Vokabular ist in jeden Enterprise-Architecture-Pitch eingewandert.

Es ist Zeit für eine nüchterne Inventur. Was hat MACH als Architektur-Paradigma in der DACH-Mittelstandspraxis verändert? An welchen Stellen sind die Versprechen eingelöst, an welchen Stellen sind sie an der Realität zerschellt? Und was ist 2026 die ehrliche Antwort auf die Frage, ob ein Unternehmen seine Web-Stack-Architektur an den vier MACH-Prinzipien ausrichten sollte?

Die kurze Antwort vorneweg: MACH hat als Vokabular gewonnen, als architektonische Wirklichkeit ist es im DACH-Mittelstand selten reine Realität. Was in der Praxis dominiert, sind hybride Stacks — mit MACH-Elementen, aber nicht durchgehend MACH-konform. Diese Hybridität ist nicht Schwäche, sondern Resultat einer abgewogenen Architektur-Entscheidung, die TCO, Team-Skill und Time-to-Value im Blick behält.

Die vier Prinzipien — und ihre individuellen Bilanzen

Zur Bilanz gehört die Trennung der vier Prinzipien voneinander. Sie sind nicht gleichwertig in ihrer Reife, nicht gleich erfolgreich in der Adoption, nicht gleich risikobehaftet in der Umsetzung.

Microservices

Das Microservices-Prinzip ist das am ehesten kritisch zu betrachtende. Die Idee ist klar: statt eines monolithischen CMS-Anwendungs-Servers viele kleine, voneinander unabhängige Services für distincte Funktionsbereiche — Content-Service, Commerce-Service, Search-Service, Personalization-Service, Auth-Service. Jeder Service hat eine eigene Datenbank, eine eigene API, einen eigenen Deployment-Lifecycle, ein eigenes Team.

In der Praxis ist das Microservices-Versprechen das, an dem sich die meisten DACH-Mittelstandsprojekte verheben. Die operative Komplexität — Service-Discovery, Distributed-Tracing, Versions-Kompatibilität zwischen Services, Datenkonsistenz über Service-Grenzen, Deployment-Orchestrierung — übersteigt häufig die Team-Kapazität eines mittelständischen Unternehmens. Was als „Microservices” gestartet ist, landet typischerweise als „Macroservices” oder „Modular Monolith” — wenige, eher größere Services, die strukturelle Trennung von Concerns respektieren, ohne den vollen operativen Overhead echter Microservices-Architekturen mitzubringen.

Diese Beobachtung deckt sich mit der internationalen Diskussion. Die Branche hat in den vergangenen drei Jahren das pendelartige Zurückschwingen zu „Monolith first, Microservices when needed” erlebt — ein Pattern, das gemeinhin mit Sam Newmans Microservices-Buch und Martin Fowlers entsprechenden Notizen verbunden ist. Im DACH-Mittelstand ist die pragmatische Linie heute: Beginne mit einem gut strukturierten Monolithen oder mit wenigen großen Services, zerschneide die Architektur erst dann weiter, wenn klare operative oder skalierungsbezogene Gründe vorliegen.

API-first

Das API-first-Prinzip ist das am klarsten gewonnene. Was 2020 noch als Manifest-Forderung formuliert war, ist 2026 schlichtweg professioneller Standard. Wer 2026 ein CMS, ein Commerce-System, ein Search-System oder ein DAM ausschreibt, erwartet als Grundausstattung saubere REST- oder GraphQL-APIs. Systeme ohne ernsthafte API-Schicht werden in Ausschreibungen schlicht nicht mehr berücksichtigt.

Die Konsequenz ist die Verbreitung des BFF-Patterns (Backend-for-Frontend). Statt einer einzigen API-Schicht direkt zwischen Backend-Services und Frontend liegt eine zwischengelagerte Aggregations-Schicht, die die service-spezifischen APIs zu frontend-passenden Antworten verdichtet. Das BFF ist heute in DACH-Mittelstandsprojekten so präsent, dass die meisten Architektur-Diagramme ihn ohne weitere Begründung enthalten:

// BFF-Layer: aggregiert Strapi-Content, Algolia-Suche und Commerce-API
import { Hono } from 'hono';

const app = new Hono();

app.get('/api/product/:slug', async (c) => {
  const slug = c.req.param('slug');
  const [content, inventory, related] = await Promise.all([
    strapiClient.documents('api::product.product').findOne({ filters: { slug } }),
    commerceApi.getInventory(slug),
    algoliaIndex.search('', { filters: `related:${slug}`, hitsPerPage: 4 }),
  ]);
  return c.json({ content, inventory, related });
});

Das Muster ist 2026 so verbreitet, dass es kaum mehr als „Architektur-Entscheidung” wahrgenommen wird. Es ist die Standardform der Service-Komposition für ernstzunehmende Web-Stacks. In dem Sinne hat MACH gewonnen — und in dem Sinne ist auch klar, dass „API-first” weniger eine MACH-spezifische Errungenschaft ist als die normale Reife der Web-Plattform-Industrie.

Cloud-native

Das Cloud-native-Prinzip ist das, dessen Adoption am stärksten von der jeweiligen Risiko- und Compliance-Lage abhängt. Im DACH-Raum trifft Cloud-Architektur auf eine Compliance-Kultur, die in den vergangenen Jahren zwei gegenläufige Bewegungen gesehen hat: Einerseits ist die Cloud-Akzeptanz im Mittelstand deutlich gewachsen, Hyperscaler-Angebote (AWS, Azure, GCP) sind nicht mehr Tabu. Andererseits sind die DSGVO-Risikobetrachtungen, die Schrems-II-Diskussion und die Cybersicherheitsstrategien der Bundesregierung in der Praxis aufmerksamer geworden, was zu einem nicht zu unterschätzenden Anteil von Souveränitäts-Cloud-Lösungen geführt hat — Hetzner, IONOS, OVHcloud, STACKIT.

Cloud-native im engeren Sinne — Kubernetes als Deployment-Schicht, Container als Standard-Verpackung, Infrastructure-as-Code als Konfigurations-Sprache, Stateless-Services mit externalisiertem State — ist im DACH-Mittelstand 2026 verbreitet, aber selten radikal umgesetzt. Die Hyperscaler-managed-Services (RDS, S3, Cloud Storage, CloudFront, Cloudflare Workers) werden in Verbindung mit eigenen Container-Workloads orchestriert. Pure-Kubernetes-On-Premise-Setups sind selten; pure-Serverless-Setups (AWS Lambda, Cloud Functions, Cloudflare Workers) sind in der Wachstumsphase, dominieren aber nicht.

Die ehrliche Bilanz: Cloud-native als architektonisches Prinzip ist nicht der Bruch, den MACH 2020 versprochen hat, sondern ein graduelles Maß, das in unterschiedlichen Schattierungen umgesetzt wird. Die Frage „sind wir cloud-native?” beantwortet sich in der Praxis selten mit einem klaren Ja oder Nein.

Headless

Das Headless-Prinzip ist das, dessen Reife am unterschiedlichsten ausfällt. Im Content-Bereich ist Headless als Architektur-Muster fest etabliert — die Trennung zwischen Content-Backend (Strapi, Sanity, Contentful, Storyblok, Hygraph) und Frontend (Next.js, Nuxt, Astro, SvelteKit) ist 2026 in jedem dritten DACH-Mittelstandsprojekt mindestens diskutiert, in jedem fünften produktiv umgesetzt.

Im Commerce-Bereich ist die Adoption gemischter. Commercetools, BigCommerce mit ihrer Composable-Stack-Variante, Shopify mit Hydrogen — alle Anbieter haben Headless-Pfade, die Adoption im DACH-Mittelstand ist real, bleibt aber hinter den Erwartungen zurück. Der typische DACH-Commerce-Mittelständler nutzt 2026 Shopware, Spryker oder ein integriertes Shopsystem mit klassischer Frontend-Integration; reine Headless-Commerce-Stacks sind im Enterprise-Segment präsent, im Mittelstand selten.

Die Bilanz: Headless im Content hat als Pattern gewonnen, Headless im Commerce ist in der Konsolidierungsphase. Was 2020 als geschlossenes Prinzip auftrat, ist 2026 zwei sehr unterschiedliche Realitäten.

TCO als Reality-Check

Die größte ungemütliche Wahrheit der MACH-Diskussion ist die Total-Cost-of-Ownership-Frage. MACH-Stacks sind in der Anschaffung selten günstig (Lizenzkosten der SaaS-Bausteine summieren sich), in der Implementierung anspruchsvoll (Integrations-Code zwischen Services ist nicht null), in der Wartung komplex (jeder Service hat seinen Update-Lifecycle, seine Breaking-Changes, seine Versions-Politik).

Eine seriöse TCO-Betrachtung für einen MACH-Stack im DACH-Mittelstand 2026 umfasst typischerweise:

Lizenzkosten der SaaS-Bausteine: Content (Contentful/Storyblok/Sanity Tier), Commerce (Commercetools/BigCommerce Tier), Search (Algolia/Coveo Tier), Personalization (Optimizely/Dynamic-Yield Tier), DAM (Cloudinary/Bynder Tier), Auth (Auth0/Okta Tier). Selbst in moderaten Konfigurationen liegt die Summe schnell im sechsstelligen Bereich pro Jahr.

Implementierungs-Kosten: Die Integration der Bausteine zu einem konsistenten Frontend-Erlebnis. Hier liegt der größere Posten — die Service-zu-Service-Choreografie, das BFF, das Frontend-Framework, die Identity-Föderation. Erfahrungsgemäß braucht ein vollständiger Greenfield-MACH-Stack zwischen drei und sechs Personenjahre, je nach Komplexität.

Betriebskosten: Das BFF, die Frontend-Hosting-Schicht (Vercel, Netlify, eigene Container-Plattform), das Monitoring, das Logging, der On-Call-Aufwand. Die Skalierung der Betriebskosten ist nicht-trivial: Mehr Services bedeuten mehr operative Oberfläche.

Vendor-Risiko: Jeder SaaS-Baustein bringt eine Vendor-Abhängigkeit mit, deren Pricing-Politik nicht in der Hand des Kunden liegt. Die Diskussion um Contentful-Preiserhöhungen 2024 und 2025 hat in der DACH-Community Spuren hinterlassen — Vendor-Switch-Optionen sind 2026 in seriösen MACH-Architekturen ein expliziter Architektur-Punkt.

Gegen die TCO-Rechnung eines reinen MACH-Stacks steht die TCO-Rechnung eines konsolidierten Systems — TYPO3 13.4 mit integrierter Suche und Standard-Plugin-Ökosystem; Drupal 11 mit Commerce-Module; ein klassisches Sitecore- oder AEM-Setup mit integrierter Personalization. Die konsolidierte Suite kostet typischerweise mehr in der Lizenz, weniger in der Integration, weniger in der laufenden Wartung. Für viele DACH-Mittelständler ist die Suite-Bilanz wirtschaftlich attraktiver — auch wenn sie architektonisch weniger reizvoll wirkt.

Migrations-Wege und der Strangler-Fig-Pattern

Wer 2026 von einer bestehenden Suite-Architektur auf eine MACH- oder MACH-ähnliche Architektur migrieren will, hat das gut dokumentierte Strangler-Fig-Pattern nach Martin Fowler als Werkzeug. Die Idee: Statt der Big-Bang-Ablösung wird der bestehende Monolith schrittweise „erwürgt” — neue Funktionalität entsteht außerhalb des Monolithen, alte Funktionalität wird stückweise migriert, der Monolith schrumpft, bis er irgendwann ersatzlos abgeschaltet werden kann.

Im konkreten DACH-Mittelstandsprojekt sieht das typischerweise so aus: Das bestehende Suite-CMS (etwa ein älteres TYPO3 6.x, ein älteres Drupal 7, ein älteres Sitecore 9) bleibt in Betrieb. Vor das System wird eine Proxy- oder Edge-Schicht gesetzt, die einzelne URL-Pfade auf neue, headless betriebene Services umleitet. Die neue Architektur wächst Pfad für Pfad, das alte System wird Pfad für Pfad kleiner.

# Edge-Router-Konfiguration: schrittweise Migration
routes:
  - pattern: '/blog/*'
    target: 'new-headless-stack'    # Astro 5 + Strapi 5
  - pattern: '/produkte/*'
    target: 'new-commerce-stack'    # Commercetools + Next.js 15
  - pattern: '/karriere/*'
    target: 'legacy-typo3'          # noch nicht migriert
  - pattern: '/*'
    target: 'legacy-typo3'          # Fallback

Die Strangler-Fig-Variante ist in der Praxis die einzige seriöse Migrationsstrategie für mittelgroße bis große Architektur-Übergänge. Big-Bang-Ablösungen scheitern in der DACH-Mittelstandspraxis regelmäßig an Budget, Zeit und politischem Rückhalt. Die schrittweise Migration ist langsamer, aber risikofreier.

Internationale Adoption — und die DACH-Eigenheiten

Im internationalen Vergleich ist die MACH-Adoption gemischt. Der US-Markt — der schon 2020 die treibende Kraft der MACH-Diskussion war — hat MACH-Stacks in größerer Breite produktiv im Enterprise-Segment. Marken wie Nike, Patagonia, Audible haben öffentlich dokumentierte Composable-Stacks, die als Referenzen in der MACH-Community zirkulieren. WordPress dominiert im US-Mittelstand weiterhin mit rund 43 Prozent globalem CMS-Marktanteil — und die WordPress-Headless-Bewegung (WPGraphQL, Faust.js) ist eine eigene Antwort auf die Composable-Diskussion, ohne sich als MACH zu verorten.

Die nordischen Märkte — Schweden, Norwegen, Dänemark, Finnland — haben eine eigene Tradition des Composable Buildings, getrieben unter anderem durch die Ibexa-Vorgängerschaft eZ Publish, die seit dem Rebrand 2020 als Ibexa DXP firmiert und mit v5 (2025) eine konsequente Headless-Architektur etabliert hat. Skandinavische Mittelständler setzen MACH-Stacks häufiger ein als ihre deutschen Pendants — was teils kulturell (höhere Tech-Adoptions-Bereitschaft), teils marktseitig (kleinere Heimatmärkte, stärkere Export-Orientierung) erklärt ist.

Im DACH-Markt bleibt die Adoption verhaltener. Der typische DACH-Mittelständler 2026 baut auf einem konsolidierten Backend (TYPO3, Drupal, Shopware, ein integriertes Shopsystem) mit modernem Frontend (Astro 5, Next.js 15, Nuxt 4) und punktuellen MACH-Bausteinen (Algolia für Suche, Cloudinary für DAM, Auth0 für Identity). Diese hybride Architektur ist nicht MACH-konform, aber sie ist die wirtschaftlich und operativ vernünftige Antwort auf die DACH-Rahmenbedingungen.

Bilanz: Was bleibt von MACH 2026

Sechs Jahre nach der Gründung der MACH Alliance lässt sich die Bilanz so ziehen: MACH hat als Vokabular gewonnen — die vier Prinzipien sind in jede ernsthafte Enterprise-Architektur-Diskussion eingewandert. MACH hat als Industriebewegung gewonnen — die Allianz hat die Composable-Idee zu einer wirtschaftlichen Realität gemacht, die Mitglieder sind in den Konzern-Pitch-Listen präsent.

MACH hat als architektonische Vollverwirklichung im DACH-Mittelstand nicht vollständig gewonnen. Die hybriden Stacks sind die Realität, nicht die Ausnahme. Das Microservices-Versprechen ist in der mittelständischen Praxis selten in seiner Reinform sinnvoll. Die TCO-Bilanz reiner MACH-Stacks ist in den meisten Mittelstands-Konstellationen nicht günstiger als die konsolidierter Suite-Architekturen.

Was bleibt, ist ein Architektur-Werkzeugkasten, aus dem im konkreten Projekt-Kontext einzelne Bausteine gewählt werden. API-first als Selbstverständlichkeit. Headless im Content-Bereich als legitime Option. Cloud-native als graduelles Maß. Microservices als Bereitstellung für die Fälle, in denen sie wirklich Mehrwert bringen.

Wer 2026 eine Web-Stack-Architektur plant, fragt nicht „MACH oder Nicht-MACH?”. Die seriöse Frage ist: Welche Bausteine brauchen wir, welche Integrationen sind tragbar, welcher Stack passt zu unserem Team-Skill und unserem TCO-Budget? Die Antwort wird selten reines MACH sein, selten reine Suite sein — und das ist das gute, abgeklärte Ergebnis sechs Jahre nach dem Manifest.