Composable Enterprise, Composabel Applications, Packaged Business Capability und Low Code – das neue Heilversprechen?
In den letzten Wochen begegnet mir diese Begriffe immer häufiger und sie Erfahren zunehmende Beachtung. Die Definition nach Gartner lautet ungefähr so
Composable Business / Composable Enterprise
beschreibt ein Unternehmensprinzip in dem ein Unternehmen, aus austauschbaren Bausteinen besteht. Die modulare Einrichtung ermöglicht es einem Unternehmen, sich je nach Bedarf neu zu organisieren und auszurichten, abhängig von externen (oder internen) Faktoren, wie z. B. einer Verschiebung der Kundenwerte oder plötzlichen Veränderungen in der Lieferkette oder bei den Materialien. Dabei gelten vier grundlegenden Prinzipien des „Composable Business“:
- Mehr Tempo durch Entdeckung
- Größere Agilität durch Modularität
- Bessere Führung durch Orchestrierung
- Belastbarkeit durch Autonomie
Im Zentrum steht also die Idee ein Unternehmen aus ganzheitlicher Perspektive agiler und resilienter zu machen. Das erfordert eine grundlegende Veränderung auf allen Architekturebenen eines Unternehmens. Also der Leistungs-, Prozess-, Organisations- und Informationsarchitektur. Typische genannte Bausteine des Composable Business sind:
- Composable Thinking. subsumiert die Denkweise, das alles kombinierbar ist und verhindert, dass Kreativität verloren geht.
- Composable Business Architecture stellt sicher, dass ein Unternehmen flexibel und belastbar aufgebaut ist. Es geht um Struktur und die Ausrichtung nach dem jeweiligen Zweck. Dafür ist eine modulare Architektur aller Komponenten des Unternehmens notwendig. Dies geschieht durch flexibles paketieren von Fähigkeiten (Packaged Business Capabilities). Geeignet Designed dann können diese unabhängig von anderen entwickelt, verändert oder ausgetauscht werden und mit anderen Komponenten immer neu kombiniert werden. Die Modularität bezieht sich insbesondere auch auf IT-Systeme und digitale Services.
- Composable Technologies
sind die Tools für heute und morgen. Sie sind die Stücke und Teile und das, was sie alle miteinander verbindet. Die vier Prinzipien sind Ziele des Produktdesigns, die die Merkmale der Technologie bestimmen und das Konzept der Composability unterstützen.
Bei der Umsetzung des Composable Enterprise entsteht die besondere Problemstellung dass die über lange Jahre eingeführte großen IT-System Monolithen ERP, PLM …. keineswegs bereits sind für dies Veränderung und das insbesondere auch eine Umstrukturierung oder Restrukturierung von juristischen Unternehmenseinheiten zu einem massiven IT-Problem geworden ist.
Als Antwort darauf steht die Idee der Composabel Applications und Packaged Business Capability. Die Idee ist es dabei abgeschlossene Einheiten zu bilden die bestimmte Business Anforderungen erfüllen.
Dafür werden gerne MACH-Architekturen als Technologische Konzepte genannt. MACH bedeutet dabei.
- Microservices (M) einzelne Teile von Geschäftsfunktionen, die unabhängig voneinander entwickelt, eingesetzt und verwaltet werden.
- API-first (A): Alle Funktionen werden über eine API bereitgestellt, so dass zwei oder mehr Anwendungen oder Dienste miteinander verbunden werden können.
- Cloud-native (C) Über SaaS-Modelle (software as a service) können Funktionen von externen Anbietern on-demand gebucht und genutzt werden – diese werden ebenfalls in einer Cloud betrieben. Dank der oben beschriebenen APIs funktioniert das problemlos.
- Headless (H) Das Headless-Konzept Systeme kein fest gekoppelten Front- und Backends haben. Headless-Systeme haben nur ein Backend
- Event-driven Architecture Die Event-driven Architecture (EDA) ist eine sehr lockere Art der Verbindung zwischen digitalen Systemen und Services.
Die dabei oft entstehende und etwas naive Denkweise ist das nun solche MACH-Architektur folgenden Plattformen bzw. Low Code Plattformen genutzt werden könnten und dann -so die Denkweise- ja von den Fachabteilungen selbst umgesetzt werden
Das alles ist wichtig und richtig und wir werden in weiteren Blog Artikeln detailliert darauf eingehen.
Wie so oft wirken die typischen blinden Flecken der vorrangig prozessorientierte Sichtweise. Diese werden dann wie so häufig Falten in die Gesichter der Digitalisierungsarchitekten werfen.
- Informationen haben eine Semantik!
- Daten fließen durch Unternehmen.
Eines der wesentlichen Probleme an denen Unternehmen heute leiden ist das die Informationssemnatiken in den unterschiedlichen Systemen nicht richtig zusammenpassen, dass wir die kaufmännische und die technologische Sicht noch nicht vereint haben.
Wenn nun jeder mit Low Code seine Applikationen baut und seine Datenmodelle bastelt wie es ihm gefällt dann passiert genau das was wie schon lange haben. Gebastelte Datenmodelle die Festsitzen, die man nicht mehr los bekommt und die nicht zusammenpassen. Der Unterschied ist dann nur das sie in flexiblen Architekturen überall in der Cloud verteilt sitzen.
Nun können vielleicht Knowledge Graphen oder Semantische Architekturen diese Semantiken zu verbinden oder zu überführen (da schemalos und flexibler).
Dennoch muss sich jemand einfach mal die Arbeit machen die Semantiken der unterschiedlichen Businessanwendungen zu vereinen.
Wenn das nicht vorher geschieht wird der Ansatz die Situation in Unternehmen eher verschlimmern als verbessern.
Zum Thema habe ich schon 2011 einen Artikel geschrieben
