Was digitale Führungskräfte über den Unterschied zwischen MACH und Composable wissen müssen

Die digitale Landschaft von heute ist schnelllebig, und wenn Unternehmen wettbewerbsfähig bleiben wollen, müssen sie digital agil bleiben. Das bedeutet, dass sie flexible Lösungen für den digitalen Handel einsetzen müssen, die es ihnen ermöglichen, das Kundenerlebnis kontinuierlich zu verbessern, indem sie neue Funktionen einführen, neue Dienste hinzufügen und sicherstellen, dass die Bedürfnisse und Erwartungen der Kunden über eine Vielzahl von Kanälen und Geräten erfüllt werden. 
In Bezug auf die Softwarearchitektur, die zur Verwirklichung dieser Ziele eingesetzt wird, tauchen häufig zwei Begriffe auf, die miteinander verwechselt werden: Composable und MACH (Microservices, API-First, Cloud native, Headless).

Zwar sind alle MACH-Lösungen Composable, aber nicht alle Composable-Lösungen erfüllen die notwendigen Merkmale von MACH. Diejenigen, die dies nicht tun, lassen sich viele Vorteile entgehen.

Leider kommt es auch vor, dass Technologieanbieter und -partner ihre Dienste 'MACH-waschen', d. h. die MACH-Terminologie übernehmen, obwohl der angebotene Dienst bei näherer Betrachtung unzureichend ist. Dies kann schwerwiegende Auswirkungen auf das Geschäft haben, da einige sehr wertvolle Vorteile entgehen, die nur dann zur Verfügung stehen, wenn die wahren Grundsätze der MACH befolgt werden.

Glücklicherweise gibt es einige nützliche Warnhinweise, auf die man achten kann und die digitalen Führungskräften die Informationen liefern, die sie benötigen, um eine fundierte Entscheidung bei der Investition in eine Composable Architektur zu treffen. Werfen wir einen Blick darauf, doch zunächst einige weitere Informationen zu Composable und MACH.

Neue Möglichkeiten bei der Umstellung auf Composable

Der Begriff "Composable" wurde erstmals 2014 von Gartner geprägt und bezog sich auf einen neuen Trend, bei dem die digitale Architektur auf einem modularen 'Baustein'-Ansatz beruhen könnte. Dies ermöglicht es Unternehmen, die besten Dienste und Funktionen auszuwählen und in eine maßgeschneiderte Lösung zu integrieren, anstatt sich mit den Einschränkungen einer 'monolithischen' Plattform auseinanderzusetzen.

Mit einer Composable Architektur ist es möglich, die Interaktionen zwischen modularen Diensten zu orchestrieren und zu verwalten, sie leicht zu identifizieren und wiederzuverwenden und sie auf verschiedene Weise zu kombinieren, um unterschiedliche Anwendungen oder Dienste zu erstellen. Entscheidend ist, dass die Dienste in einer Composable-Umgebung unabhängig voneinander funktionieren, so dass sie ausgetauscht, aktualisiert oder ersetzt werden können, ohne dass kostspielige Ausfallzeiten entstehen.
Der Composable-Ansatz hat an Popularität gewonnen, weil er erkannt hat, dass keine einzelne digitale Plattform alle individuellen Anforderungen eines Unternehmens erfüllen kann. Stattdessen wird die Verwendung spezialisierter, unabhängiger Module gefördert, wie z. B. ein Warenkorb, ein Produktkatalog oder eine Kasse, die kombiniert und orchestriert werden können, um maßgeschneiderte Kundenerlebnisse zu schaffen.

Composable legt den Schwerpunkt auf die Verwendung von APIs, um diese Komponenten nahtlos zu verbinden und zu integrieren und sicherzustellen, dass Unternehmen die besten Lösungen auf dem Markt nutzen können, ohne ihre Flexibilität und Agilität zu verlieren. Auf diese Weise hat die Composable Architektur die Landschaft des digitalen Handels verändert und eine Welt voller neuer Möglichkeiten eröffnet.

Die MACH Architektur ist ein neuerer Ansatz für den Aufbau von Softwaresystemen, der alles tut, was Composable tut, aber noch mehr bietet. MACH ist eher eine Philosophie oder ein übergeordneter Satz von Prinzipien, die, wenn sie angenommen werden, die perfekte Umgebung für digitale Flexibilität, Skalierbarkeit und Wachstum schaffen. Die vier Hauptprinzipien von MACH sind: Microservices, API-First, Cloud-native, and Headless. Alle vier Merkmale müssen vorhanden sein, damit eine Lösung wirklich MACH ist. Die folgenden Beispiele stellen Szenarien dar, bei denen dies nicht unbedingt der Fall ist, auch wenn sie noch 'composable' sind. 

On-Premise-Bereitstellung

Dies bezieht sich auf die Installation und den Betrieb von Software und Erweiterungen an einem physischen Standort, in der Regel auf dem Gelände eines Unternehmens. Dies ist das genaue Gegenteil von 'Cloud nativ'. Während On-Premise also immer noch als zusammensetzbar gelten kann, wenn APIs genutzt werden, um eine Headless-Lösung auf der Grundlage einer Microservices-Architektur zu erstellen, negiert die Tatsache, dass es sich um eine On-Premise-Lösung und nicht um eine Cloud-Lösung handelt, die Einhaltung der MACH-Vorgaben. Und da sie nicht Cloud nativ ist, entgehen den Benutzern die damit verbundenen Vorteile.

Bei der Bereitstellung vor Ort fehlen die Vorteile der Verfügbarkeit, Skalierbarkeit und Kosteneffizienz, die das Outsourcing des Infrastrukturbetriebs an Public Cloud-Anbieter bietet. Die meisten Unternehmen rechtfertigen den On-Premise-Betrieb in ihren TCO-Berechnungen nicht mehr, da Upgrades sehr aufwändig sind und Wachstumschancen verpasst werden. Cloud native Lösungen sollten nicht verhandelbar sein, um eine möglichst zukunftssichere und wenig belastende Lösung zu erhalten. Eine Lösung kann zwar Elemente enthalten, die tatsächlich 'cloudbasiert' sind, aber wenn sie nicht vollständig in der Cloud entwickelt wurde und sich auf kontinuierliche Integration und Orchestrierung unter Verwendung von Container-Engines wie Docker oder Kubernetes konzentriert, dann ist sie nicht cloud nativ.

Single Tenancy-Angebote

Single Tenancy bedeutet, dass die Software, die Datenbank und die Infrastruktur einem einzigen Kunden dienen, während Multi-Tenancy mehreren Kunden die gemeinsame Nutzung von Komponenten ermöglicht. MACH-zertifizierte Anbieter bieten Multi-Tenant-Optionen an, die Kosteneinsparungen, eine einfachere Wartung und eine bessere Konnektivität auf API-Ebene ermöglichen. Anbieter, die ausschließlich Single-Tenant-Cloud-Lösungen ohne Multi-Tenant-Optionen anbieten, können jedoch durch ihre monolithischen Softwarekomponenten eingeschränkt sein, was ihre Fähigkeit zur Umwandlung in Cloud native Microservices-Architekturen behindert. Dies führt zu längeren Einrichtungszeiten, erhöhtem Wartungsaufwand und potenzieller Anbieterbindung, die einen Wechsel zu einem anderen Anbieter schwierig und teuer macht.

Versionierte APIs

In einer Composable Digital-Umgebung spielen APIs eine entscheidende Rolle bei der Verbindung verschiedener Tools und Technologien, um reibungslose Prozesse und Workflows zu gewährleisten. MACH-zertifizierte Anbieter arbeiten auf einer API-First Basis, d. h. sie stellen versionslose APIs bereit, so dass sich Entwicklungsteams bei der Erstellung neuer Funktionen oder automatisierter Prozesse auf konsistente und stabile Schnittstellen verlassen können. Auf der anderen Seite erlegen Anbieter mit versionierten APIs den internen Entwicklungsteams ihrer Kunden einen hohen Wartungsaufwand auf, was das Risiko von Konnektivitätsproblemen und Ausfallzeiten erhöht. Versionierte APIs deuten oft auf eine monolithische Architektur hin, bei der Änderungen an einem Teil der API Aktualisierungen an der gesamten Schnittstelle erfordern, was zu Fehlern, Inkonsistenzen und häufig auch zu Ausfallzeiten führt.

Monolithische Bereitstellung

Bei einem monolithischen Bereitstellungsmodell muss die gesamte Anwendung als eine große Einheit bereitgestellt werden, während bei einem modularen Bereitstellungsmodell die einzelnen Komponenten separat bereitgestellt werden können. Monolithische Bereitstellungen sind aufgrund höherer Kosten, längerer Bereitstellungszeiten, höherer Fehlerquoten und eines erheblichen betrieblichen Aufwands mit Herausforderungen verbunden. Im Gegensatz dazu unterstützen MACH-Bereitstellungen häufige Code-Releases im Laufe des Tages und ermöglichen es Unternehmen, auf veränderte Umstände zu reagieren und das Wachstum in digitalen Kanälen zu fördern. Außerdem mangelt es monolithischen Bereitstellungen an kosteneffizienter Skalierbarkeit, da Ressourcen vertikal skaliert werden müssen, um Nachfragespitzen zu bewältigen, was zu ungenutzten Ressourcen und unnötigen Kosten führt.

Um mehr über diese vier Hauptunterschiede zu erfahren, hat die MACH Allianz weitere Details zur Verfügung gestellt. Dieses gemeinnützige Branchengremium ist herstellerneutral und bietet Best-Practice-Ratschläge und Ressourcen, um die Branche bei der Umstellung von Legacy-Infrastrukturen auf Composable Ansätze zu unterstützen. Um die von Emporix angebotenen und nach den MACH-Prinzipien entwickelten Optionen für den digitalen Handel kennenzulernen, nehmen Sie hier Kontakt auf.