Auf Veränderungen – ob positiv oder negativ – schnell zu reagieren, ist ein Business-Value, der für Unternehmen erfolgsentscheidend ist.

In der Praxis tun sich Unternehmen damit regelmäßig schwer. Nahezu alle Gegebenheiten auf den heutigen Marktplätzen der Welt wechseln so dynamisch, dass es anstrengt, Schritt zu halten.
Ein Hinderungsgrund sind über die Zeit historisch gewachsene Information-Strukturen und -Architekturen im Unternehmen.

Der Monolith

Diese monolithischen Software-Systeme und Architekturen sind eng verzahnte Gesamtstrukturen und neigen dazu sich zunehmend zu "verhärten", wenn sich die Applikation weiterentwickelt. Dies macht es schwierig, einzelne Services zu isolieren, um diese zu verändern oder neue Funktionen mit neuem Business-Wert zu komponieren. Durch diese enge Verzahnung haben Veränderungen stets direkte und indirekte Auswirkungen auf den gesamten Monolithen.

Neueste Software-Technologien, sowie der Einsatz von Cloud-Services und -Architekturen bieten nun eine weitaus flexiblere Gestaltung, was für Unternehmen langfristig von existentieller Bedeutung sein kann.

Das Wesen von Composable Business bzw. Composable Commerce ist ein komplett gegensätzlicher und granularer Ansatz ("Botton-Up" statt "Top-Down"). Wenn sämtliche Prozesse im Unternehmen diesem Ansatz folgen, wird vom Composable Enterprise Modell gesprochen - aber dazu später.

Dieser Artikel beleuchtet das große Bild hinter diesem neuen Ansatz und liefert gleichzeitig Anregungen, um:

  • eigene monolithische Strukturen (in Technik und Organisationsform) zu erkennen.

  • monolithisch Strukturen Stück für Stück aufzulösen

  • seine IT für die Zukunft mit neuen Ansätzen nachhaltiger, effizienter und zukunftsfähiger zu gestalten

Die große Vision hinter Composable Business ist, dass sich die IT mit Leichtigkeit neu orchestrieren und optimieren lässt.

Zunächst benötigt der Kopf etwas „Composable Thinking“.

Status Quo: Brick by Brick building further Monoliths?

Erkenne, dass du deinen Monolithen baust:

Das traditionelle Modell einer typischen Unternehmensplattform ist eng gekoppelt und als nahezu untrennbare Einheit verwoben. Systeme stehen in Abhängigkeit zueinander und bilden das „Große Ganze“. Selbst ein "Best of Breed" von "kleineren Monolithen" verbessert daran nichts. Für Composable Business ist es wichtig, den Monolith mittelfristig aufzulösen und Lösungen granularer zu gestalten. Neue IT-Projekte in Richtung „Composable“ sind die Zukunft.

Monolith against Business

Ein Monolith besteht aus Abhängigkeiten, die sich durch sämtliche Architektur-Schichten ziehen. Ein Best of Breed-Ansatz ist schwer zu realisieren.

Dieser Aufbau erschwert insgesamt die Wartbarkeit, die Reaktionsgeschwindigkeit des Unternehmens und senkt den ROI. „Moving the whole Monolith“ bei allen Änderungen an diesem Konstrukt ist nicht zukunftsfähig.

Monolith against Customer

Einzelne Kunden-Kanäle sind schwer umzusetzen und die Customer Journey und die Customer Experience leidet durchgehend. Kunden-Insights und Einwilligungsmanagement sind kanalübergreifend schwer zu realisieren. Im Gegensatz steht das Composable Thinking als neue Denkweise. Es sind grundsätzlichen Design-Prinzipien, die auf dem Weg zum Composable Business einzuhalten sind. Daher ist es empfehlenswert, dass jedes neue IT-Projekt diesen Prinzipien folgt.

Vorteile durch Composable Thinking

1. Geschwindigkeit durch Erfahrung

Risikovermeidung, lange Projektzeiten und Projektstabilität ist die althergebrachte Denklogik. Heutzutage nutzen Unternehmen besser das Risiko und Erfahrungen in kurzen, flexiblen Projekten und erhalten so modulare IT-Produkte für eine Composable Enterprise Architektur.

2. Agilität durch Modularität

Modularisierung und "Schnittstellen-Verträge" (Design by Contract) hilft bei der agilen Entwicklung von einzelnen Komponenten, ohne dass andere Komponenten in Mitleidenschaft gezogen werden. Die Abhängigkeiten in der Umsetzung von Veränderungen sinken und die Agilität steigt.

3. Bessere Führung durch Orchestrierung

Top-Down Design der eingesetzten Technologien und gemeinsamer Paradigmen ermöglicht bessere Integration, Kontrolle und macht komplexe Strukturen handhabbar und sicherer.

4. Resilienz durch Autonomie

Aufbau von in sich gekapselten, autonomen Business-Objekten, die zwar untereinander kommunizieren, jedoch autark und unabhängig laufen. Zusätzliche Automatisierungen senken Fehlerquoten bei der Administration und halten autonom instand.

Dies gilt sowohl für die Technik als auch für Menschen und Organisationen.

„Composable Technology“ und „Composable Architecture“

Diese neuen Denkweisen und Prinzipien verlangen nach passender Technologie, um diese “Denke” Wirklichkeit werden zu lassen. Viele Softwarehersteller haben dies bereits erkannt und unterstützen in neueren Versionen z.B. einen API-First-Ansatz und Headless-Unterstützung.

Mit den passenden Tools, offenen Ökosystemen, Low-Code-Plattformen, Cloud native und Event-Driven-Architecture lassen sich Composable-Architekturen aufbauen. Populär ist die sogenannte MACH-Architektur geworden, die das Zusammenspiel der nötigen Voraussetzungen prinzipiell zusammenfasst.

MACH-Architektur als Plattform für Composable Business/Commerce

MACH-Architekturen sind digitale Ökosysteme, die in Hinblick auf Automation, Modularität und Skalierbarkeit entwickelt werden. Diese Architekturen sind die Kerntechnologie von Composable Enterprise Betriebsmodellen.

M.A.C.H. ist ein Akronym und steht für eine moderne Software- und Plattform-Architektur, die sich aus Mikrodiensten, dem API-first Prinzip, Cloudnative sowie Headless Frontend-Technologien für Commerce und CMS oder Application-User-Interfaces zusammensetzt.

Das Besondere an dieser Architektur ist, dass Prinzipien bestehen, wie z.B. die konsequente Trennung von eingesetzten Frontend und Backend durch APIs (Application Programming Interface, Programmierschnittstellen) und deren Daten.

Eingesetzte Technologien entsprechen dem API-first Gedanken und lassen sich komplett über Schnittstellen ohne User Interface steuern. Cloudnative Technologien sind die Basis für die Zusammenführung in der Cloud oder Multiclouds für die automatisierte Orchestrierung von Applikationen, Datenressourcen und Prozessen. Die Schnittstellen zum jeweiligen Benutzer sind vom Backend losgelöste, auf den Benutzer und seine Bedürfnisse zugeschnittene Frontends, die speziell für die jeweiligen Anforderungen konzipiert und gestaltet werden.
Um Geschäftsvorgänge zu steuern oder Applikationen zu bedienen, bieten sich zwar durchaus die Frontends der Softwarehersteller (Backoffices für Administratoren) an, mit entsprechender Frontendtechnologie lassen sich jedoch auch individuelle Cockpits oder Dashboards erstellen.

Zur Veranschaulichung: Innerhalb einer MACH-Architektur kommt E-Commerce mit all seinen Funktionen, Front- und Backend, Daten, Designs, Inhalten, Produkten und Prozessen, die Ihre Capabilities ausmachen, nicht mehr als ein einziges monolithisch geschmiedetes und konfiguriertes Stück Software daher. Denn dieses lässt sich auf Dauer schlecht verwalten und prozessual sowie funktional erweitern.

Ein Shop innerhalb einer MACH-Architektur besteht somit aus in sich geschlossenen Anwendungen/Mikrodiensten und Self Contained Systems, die losgelöst von abhängigen Strukturen und Prozessen fungieren. Es ist möglich, die gesamte Präsentation im Frontend für User beliebig zu variieren und kanalspezifisch zu erweitert. Der Auf- und Ausbau mit MAM/DAM und PIM ist viel unabhängiger von Technologierestriktionen, was sich äußerst positiv auf die Gesamtperformance des Unternehmens auswirkt.

So sind beispielsweise die benötigten Daten des Shops sind nicht mehr verschweißt mit dem Shop-Monolithen, sondern werden beliebig aus diversen Quellen über API und Services zusammengestellt. Gleichwohl ist es möglich, dass sämtliche Shop- und Kundeninformationen von anderen Systemen genutzt werden.
Genauso losgelöst betrachtet wird die eigentliche Schnittstellen- und Systemkommunikation und ihre Gestaltung. Um Funktionen und Informationen nicht hart zu verdrahten, ist es nötig zu klären, wie, was, wann, aus welchem Grund und zu welchem Ziel vermittelt wird. Durch Einsatz eines Messaging-Systems und durch vereinheitlichte und konsequent definierte Kommunikationsverfahren entsteht die nachrichten- und ereignisgesteuerte IT-Architektur, die für heutige Digitalisierungsanforderungen unabdingbar ist.

Stellt ein Unternehmen nicht nur seinen Shop, sondern seine gesamten Geschäftsvorgänge auf MACH-Technologie ein, wird ein Business hochgradig skalierbar und kommunikativ und bleibt dabei performant und flexibel. Weil modular.
Grob skizziert sieht so das Composable Enterprise Model aus – ein wichtiger und evolutionärer Schritt bei der Digitalisierung im Unternehmen.

Wind of Change: Das Composable Enterprise Model

Im Grunde transformieren Sie – technologisch gesehen – 20 Jahre alte Prozesse und IT-Systeme in, granulare, gekapselte und wiederverwendbare Business-Fähigkeiten auf Basis einer gemeinsamen, einheitlichen Kommunikations- und Informationsarchitektur.
Das Paradigma ist: In der Vergangenheit wurden technologie- und kommunikationsbedingt monolithische Informationsarchitekturen aufgebaut, welche im Endeffekt die Geschäftsfähigkeit, die Prozesse und das Betriebsmodell der Unternehmung nachhaltig diktierten und nicht selten an den eigentlichen Zielen vorbeigingen. Daran ist jedoch niemand schuld. Zum einen war die Technologie noch nicht so fortgeschritten wie heute. Zum anderen sind Unternehmen gezwungen diese Systeme in der Art zu entwerfen, dass sie ihren eigenen, internen Kommunikationsstrukturen entsprechen. Siehe dazu Conways Law Unternehmen entwickeln also beispielsweise Webseiten, die der eigenen internen Struktur entsprechen und nicht hauptsächlich Informationsbedürfnisse der Nutzer befriedigen, für die diese Webseiten ursprünglich gedacht waren.

Mit einer Composable Enterprise Architektur entledigen Sie sich diesem Technologie-Korsett und gewinnen gleichzeitig die nötige Agilität zurück, Kundenbedarfe in den Mittelpunkt zu stellen. Durch einen unternehmensweiten Kommunikationsstandart regeln und vereinheitlichen Sie konsequent die Kommunikation von beteiligten Schnittstellen, Menschen und Systemen. Auch der Umgang mit Fehlern in einer nachrichtengesteuerten IT-Architektur und mit ihren zwischenmenschlichen Abhängigkeiten sind wichtige Bausteine für einen erfolgreichen Change

Sie definieren und beschreiben

  • all Ihre Geschäftsfähigkeiten (Schlüsselfaktoren des Erfolges: Status Quo und in Zukunft?)

  • Ihre Operations- und Geschäftsmodelle (Funktionsweise, wie sie Ihre Gewinne erwirtschaften)

  • Ihre Kommunikationsfähigkeiten und Ihr Informationsvermögen

  • und alle daraus abgeleiteten Business Objekte, Menschen und Prozesse (z.B. Account-Management, HR-Management, Ordermanagement und Procurement Prozesse, Credit Assesments, Ressourcen und Datenreferenzen, Analysen, etc.)

und setzen diese technologisch in gekapselte, wohl komponierte, wiederverwendbare Softwarekomponenten für einzelne Geschäftsvorgänge und deren User um.
Konzentrieren Sie sich bei der Beschreibung der eigenen Fähigkeiten auf Informationen und die Menschen und nicht in erster Linie auf Technologie und die ohnehin entstehenden Prozesse.

Prozesse werden beliebig wiederverwendet, skaliert, modifiziert und ausgetauscht, ohne dass sich Änderungen – wie bei monolithischen Architekturen – direkt auf angrenzende Systeme, die Kommunikation oder die gesamte Business-Architektur auswirkt.

Klar, dass solch tiefgreifenden Änderungen nicht in einem Projekt realisiert werden. Dennoch ist diese Denkweise entscheidend für den Erfolg und neue Projekte in Schlüsselbereichen als MACH-Kerndienste umzusetzen ist mittelfristig die bessere strategische Entscheidung.
Das bedeutet: Werde dir über dein Business und deinen Fähigkeiten bewusst. Forme Teams und Abteilungen, die diese Vision leben und verantworten. Dazu gehört auch die entsprechende, Technik-Affinität. Denn daran scheitern die meisten Projekte und Unternehmen.

Das Ziel ist, die gesamte Palette an Business-Prozessen, Organisationen und Beziehungen untereinander, Funktionen und Technologien als eine Reihe von wiederverwendbaren Prozess-Komponenten zu betrachten, die nach Bedarf konfiguriert werden.

Es werden keine langwierigen Umsetzungs-Projekte oder IT-Produkte als Microservices ausgeliefert, sondern komponierte Applikationen, die sich als „unternehmerische Fähigkeit“ -- den sogenannten Packaged Business Capabilities -- in eine Gesamtarchitektur einfügen.

Fazit:

Hieß es vorher: „Never Change a running System“, wird nun variiert, implementiert, erweitert und neu vernetzt. Die Kerntechnologien sind M.A.C.H., Multi-Cloud und Information as a Service in der Cloud (Cloud IaaS).

Mit einer MACH-basierten Architektur sind Unternehmen zukünftigen Herausforderungen und dem stetigen Wandel bestens gerüstet.

Damit einher geht ein umfangreiches Changemanagement und anfänglich erhöhte Kosten in der Transformationsphase. Das gehört zum Risiko, welches sich mit vertrauenswürdigen Systemintegratoren für die Beratung, Analyse und Konzeption von Architekturen sowie dem richtigen Vorgehen weiter minimiert.

Weil Unternehmen selten auf einer grünen Wiese starten, bietet sich die schrittweise Umstellung durch hybride Systemwelten für den Übergang an.
Viele Hersteller passen ihre Software bereits an, um diese Cloudnative zu gestalten. Headless und API-First sind die wichtigsten Stichworte für die neue Softwareevaluationen. Erfahrene Dienstleister und Software-Integratoren leisten wertvolle Hilfestellung, wie mit Composable Business gestartet wird.

Belohnt werden Unternehmen mit einem flexiblen, individuellen und leicht anzupassenden Ökosystem für ihr einzigartiges Business, welches modernen Handelsanforderungen entspricht.

Unser Angebot an Sie:

Durch unsere Expertise aus vielen Kundenprojekten helfen wir, Ihr Business nachhaltig auf Composable-Technologie umzustellen. communicode besitzt umfangreiche Erfahrung mit dieser Technologie und angrenzenden Aspekten, um ihren Einstieg zielführend zu gestalten und nach und nach Schlüsselbereiche Ihres Business auf eine moderne Business-Plattform-Architektur zu heben.

Frequently Asked Questions rund um Microservices, M.A.C.H. und Composable

  • Was ist eine monolithische Architektur
    +

    Traditionell wurden in der Vergangenheit Softwaresysteme als eine gesamte Struktur und Einheit gestaltet und betrieben, um zusammenhängende Aufgaben zu bearbeiten. Funktionen und APIs zu Erweiterungsmodulen und anderen Systemen erweitern diese autonome Einheit und vergrößern die Abhängigkeiten innerhalb monolithischer Systeme.

  • Was ist ein Microservice?
    +
    Microservices sind eine Cloud Native Architekturlösung in der Softwareentwicklung. Softwarekomponenten werden logisch in Microservices aufgeteilt und können einzeln und ohne Auswirkung auf die übrige Architektur angepasst, gewechselt, skaliert oder neu entwickelt werden.
  • Was bedeutet API-First?
    +
    Um Funktionen innerhalb einer Software zu benutzen, ist üblicherweise ein grafisches UI nötig. Applikationen, die einen API-First Ansatz bieten, lassen sich jedoch vollständig über Schnittstellen ansprechen und nutzen. Diverse Headless-Frontends als eigenes Build oder als Buy-Lösung können mit diesen APIs verbunden werden, sodass Funktionen äußerst flexibel in Frontendanwendungen und weiteren Systemen genutzt werden können.
  • Was bedeutet Cloud Native?
    +
    Als Cloud Native wird Software in Form von Microservices bezeichnet, die prädestiniert für den Betrieb in der Cloud sind. Diese Anwendungen sind so gestaltet, dass sie selbst automatisiert skalieren können, ohne von Servern, deren Rechenleistung, Netzwerken oder Speicher abhängig zu sein.
  • Was bedeutet MACH-Architektur bzw. MACH-Technologie?
    +
    Das Akronym MACH steht für eine moderne Software- und Plattform-Architektur, die sich aus Mikrodiensten, dem API-first Prinzip, Cloudnative sowie Headless Frontend-Technologien für Commerce und CMS oder Application-User-Interfaces zusammensetzt. MACH-Architekturen sind digitale Ökosysteme, die in Hinblick auf Automation, Modularität und Skalierbarkeit entwickelt werden.
  • Was ist eine Headless-Architektur?
    +
    Bei einer Headless-Architektur ist die gesamte Geschäftslogik und -funktionalität von speziellen API-First-Applikationen in einer Reihe von APIs als Microservice gepackt, die von den spezialisierten Backends betrieben und verfügbar gemacht werden. Jeder Frontend-Kanal kann diese APIs nutzen, um eine für diesen Kanal gewünschte Kundenerlebnis zu bieten.
  • Was bedeutet Headless-Commerce?
    +
    Headless-Commerce ist ein E-Business-Konzept, bei dem Front- und Backendtechnologien nicht mehr als Einheit/Monolith gekoppelt sind. Unternehmen können so flexibler, schneller, nachhaltiger und langfristig kostensensitiver spezialisierte E-Commerce Lösungen agil aufbauen, diese optimieren und sich stetig verändernde Kundenanforderungen und Marktanforderungen ausrichten.
  • Was sind die Vorteile einer MACH-Architektur?
    +
    Trotz umfangreichem Change-Management und anfänglichen Mehrkosten bietet eine MACH-Architektur mittel- und langfristig einen erheblichen Wettbewerbsvorteil, da diese Technologie der Kern von Composable Enterprise Modellen ist und eine schnelle und flexible Entwicklung und Skalierung von technischen Ökosystemen ermöglicht. Laut Gardner sind damit bis 80% Einsparung gegenüber traditionellen IT-Architekturen möglich.
  • Was bedeutet Composable Commerce/Business?
    +

    Composable Commerce bedeutet, dass Unternehmen Mehrwert schaffende, vorgefertigte Lösungen und Integrationen, als vorkonfigurierte Applikationen kaufen und einfach in ihre Commerce Experience integrieren können. Die Voraussetzung dazu ist Composable Thinking, eine Composable Architecture und Composable Technologies.

  • Was ist ein Self Contained System (SCS)?
    +
    Bei einer Self Contained Systems-Architektur werden ganze Funktionen und Prozesse in mehrere kleinere Web-Anwendungen gepackt. Die Kommunikation untereinander findet optimalerweise asynchron statt und der Geschäftscode wird nicht mit anderen SCS geteilt, um die Unabhängigkeit zu gewährleisten. SCS erhalten oftmals eine eigene UI, um die Funktionen Anwendern bereitzustellen und können zudem eine eigene Service -API besitzen.
  • Was ist der Unterschied zwischen Microservices und Self Contained Systems?
    +
    Microservices können zum Beispiel untereinander kommunizieren. Bei SCS, Self Contained Systems ist dies konzeptionell nicht gewünscht. Konzeptionell werden in SCS ganze Services und Prozesse mit allen Daten und Funktionen abgebildet und kann eine eigene UI besitzen. Ein Microservice kann nur eine einzige Aufgabe haben, für die auch kein User Interface nötig ist. Ein System enthält mehr Microservice-Komponenten als SCS-Komponenten.
  • Was bedeutet Packaged Business Capabilities?
    +
    Packaged Business Capabilities (PBCs) ist ein von Gardner geprägter Begriff und beschreibt Softwarekomponenten, die eindeutig definierte Geschäftsfähigkeiten und deren Prozesse darstellen und von einem Anwender als solche nutzbar ist, um entsprechende Aufgaben auszuführen.