Digitale Transformation

Composable Enterprise: Modulare IT-Architektur für den Mittelstand

Monolithische Systeme weichen modularen Bausteinen. Wie MACH-Prinzipien und Packaged Business Capabilities die IT-Landschaft des Mittelstands transformieren.

CIO-Wissen Redaktion· 2026-03-28 ·5 Min.

Die IT-Architektur der meisten Mittelständler ist historisch gewachsen: Ein ERP-System als monolithischer Kern, darum herum spezialisierte Anwendungen, verbunden durch Punkt-zu-Punkt-Integrationen und manuelle Datenübertragungen. Diese Architektur hat jahrelang funktioniert — doch sie wird zum Engpass, wenn Geschäftsmodelle sich schneller ändern müssen als die IT liefern kann. Gartner hat dafür den Begriff "Composable Enterprise" geprägt: ein Unternehmen, dessen IT-Architektur aus austauschbaren, kombinierbaren Bausteinen besteht, die sich so flexibel zusammenstellen lassen wie Legosteine.[1]

Die Idee ist nicht neu — serviceorientierte Architekturen (SOA) verfolgten in den 2000er-Jahren ein ähnliches Ziel. Doch die technologischen Voraussetzungen haben sich grundlegend verändert: Cloud-native Infrastrukturen, Container-Orchestrierung mit Kubernetes, API-Management-Plattformen und Event-Streaming-Systeme wie Apache Kafka machen die modulare Vision erstmals praktikabel. Laut Gartner werden bis 2027 mehr als 60 Prozent der neuen Geschäftsanwendungen auf einer Composable-Architektur basieren — gegenüber weniger als 20 Prozent im Jahr 2023.[1]

MACH: Die vier Säulen der Composable-Architektur

Die MACH Alliance, ein Zusammenschluss von Technologieanbietern wie Commercetools, Contentful und Algolia, hat vier Architekturprinzipien definiert, die das Fundament einer Composable-Architektur bilden:[2]

Microservices: Geschäftslogik wird in kleine, unabhängig deploybare Services aufgeteilt. Jeder Service hat eine klar definierte Aufgabe — etwa Preisberechnung, Lagerverwaltung oder Kundenauthentifizierung. Teams können Services unabhängig entwickeln, testen und aktualisieren, ohne das Gesamtsystem zu gefährden.

API-first: Jede Funktionalität wird über eine wohldefinierte API exponiert. APIs sind nicht nachträgliche Schnittstellen, sondern das primäre Designartefakt. Dieser Ansatz ermöglicht die flexible Kombination interner und externer Services und bildet die Grundlage für die API-Economy.

Cloud-native: Anwendungen werden für die Cloud entwickelt, nicht nachträglich dorthin migriert. Das bedeutet: Container-basierte Deployments, automatische Skalierung, Infrastructure as Code und Nutzung von Managed Services anstelle selbstverwalteter Infrastruktur.

Headless: Frontend und Backend sind strikt getrennt. Geschäftslogik und Datenhaltung wissen nichts über die Darstellungsschicht. Ob Website, mobile App, Chatbot oder IoT-Device — das Frontend konsumiert die gleichen APIs, ohne dass das Backend angepasst werden muss.

Monolith vs. Composable: Ein Architekturvergleich

Monolithische Architektur

  • Einzelnes, eng gekoppeltes System
  • Änderungen erfordern Gesamtdeployment
  • Skalierung nur als Ganzes möglich
  • Vendor Lock-in durch proprietäre Plattform
  • Lange Release-Zyklen (Wochen bis Monate)
  • Einheitlicher Technologie-Stack erzwungen
  • Hohe Einstiegshürde für neue Funktionen

Composable-Architektur

  • Lose gekoppelte, unabhängige Services
  • Änderungen pro Service isoliert deploybar
  • Granulare Skalierung nach Bedarf
  • Best-of-Breed-Auswahl pro Komponente
  • Kontinuierliche Deployments (täglich bis stündlich)
  • Technologiefreiheit pro Service
  • Neue Funktionen als zusätzlicher Baustein

Composable Business ist nicht nur eine Technologiestrategie — es ist ein Organisationsprinzip. Unternehmen, die ihre Geschäftsfähigkeiten modular denken, können schneller auf Marktveränderungen reagieren als solche, die an monolithischen Strukturen festhalten. — Gartner, "The Future of Business Is Composable" (2024)

Packaged Business Capabilities: Der strategische Baustein

Das zentrale Konzept der Composable-Architektur sind Packaged Business Capabilities (PBCs). Anders als technische Microservices beschreiben PBCs fachliche Geschäftsfähigkeiten, die als eigenständige Softwareeinheiten bereitgestellt werden.[1]

Ein PBC für "Rechnungsstellung" umfasst beispielsweise nicht nur die technische API zum Erstellen einer Rechnung, sondern auch die zugehörige Geschäftslogik (Steuerberechnung, Rabattregeln, Compliance-Prüfungen), Datenhaltung und ein eigenes Frontend-Widget. PBCs können intern entwickelt oder von spezialisierten Anbietern bezogen werden — die API-Economy macht beides möglich.

ThoughtWorks hat PBCs in ihrem Technology Radar als Architekturansatz identifiziert, der besonders für mittelständische Unternehmen relevant ist:[3] Sie ermöglichen es, Best-of-Breed-Lösungen für einzelne Geschäftsfähigkeiten einzusetzen, ohne die Gesamtarchitektur zu kompromittieren. Wenn ein PBC nicht mehr den Anforderungen genügt, wird er durch einen besseren ersetzt — ohne Auswirkung auf die übrigen Komponenten.

Für die Orchestrierung dieser Bausteine setzen führende Unternehmen auf Event-Driven Architecture (EDA): Anstatt Services synchron über APIs zu koppeln, kommunizieren PBCs asynchron über Events. Ein Event "Bestellung aufgegeben" löst parallel Prozesse in Lagerverwaltung, Rechnungsstellung und Kundenkommunikation aus — ohne dass diese Services voneinander wissen müssen.

Handlungsempfehlungen für CIOs

  • Starten Sie mit einer Capability Map: Bevor Sie Technologieentscheidungen treffen, kartieren Sie Ihre Geschäftsfähigkeiten. Welche Capabilities sind differenzierend (selbst entwickeln), welche sind Commodity (zukaufen)?
  • API-first als Architekturprinzip verankern: Jede neue Anwendung, jeder neue Service muss eine API exponieren. Definieren Sie API-Design-Standards und etablieren Sie ein API-Gateway als zentralen Zugangspunkt.
  • Vermeiden Sie den zweiten Monolithen: Die größte Gefahr bei Microservices ist, dass aus vielen kleinen Services ein verteilter Monolith wird. Investieren Sie in klare Service-Boundaries, Event-basierte Kommunikation und ein solides Domain-Driven Design.
  • Pragmatisch starten, nicht dogmatisch: Sie müssen nicht alles sofort auf Microservices umstellen. Beginnen Sie mit einem neuen Geschäftsbereich oder einem klar abgrenzbaren Modul. Die MACH-Prinzipien lassen sich schrittweise einführen.
  • Investieren Sie in Developer Experience: Composable-Architekturen erfordern leistungsfähige CI/CD-Pipelines, Observability-Tools und eine Self-Service-Plattform für Entwicklungsteams. Ohne diese Grundlagen wird die Komplexität zum Bumerang.
  • Evaluieren Sie die Organisationsstruktur: Conway's Law gilt — Ihre Architektur wird Ihre Teamstruktur spiegeln. Organisieren Sie Teams um Geschäftsfähigkeiten, nicht um technische Schichten.

Quellen und Referenzen

  1. Gartner: "The Future of Business Is Composable — And the Technology Must Be Too", Gartner Research Note, 2024. https://www.gartner.com/en/articles/composable-business
  2. MACH Alliance: "MACH Technology Principles", MACH Alliance Whitepaper, 2024. https://machalliance.org/mach-technology
  3. ThoughtWorks: "Technology Radar Vol. 30 — Packaged Business Capabilities", ThoughtWorks, 2024. https://www.thoughtworks.com/radar
  4. Forrester Research: "The Composable Enterprise: A Forrester Framework", Forrester Report, 2024. https://www.forrester.com/report/composable-enterprise
  5. Martin Fowler: "Microservices — A Definition of this Architectural Style", martinfowler.com, 2014. https://martinfowler.com/articles/microservices.html
  6. Gartner: "API Strategy and Management Best Practices", Gartner Research, 2024. https://www.gartner.com/en/documents/api-strategy
  7. Confluent: "Event-Driven Architecture: A Practical Guide", Confluent White Paper, 2024. https://www.confluent.io/resources
  8. Bitkom: "Composable Architecture im deutschen Mittelstand", Bitkom Leitfaden, 2024. https://www.bitkom.org/Presse