Nachrichten aus dem Versandhandel
Bild: Hannes Edinger / Pixabay
Wie MACH-Software zum Business-Turbo wird
07.10.2022 - Jedes Unternehmen ist Software - irgendwie. Schlanke Prozesse, eine kluge IT-Architektur und agil geplante Anwendungen sind deswegen nicht nur ein Schlüssel zum Digitalisierungserfolg, sondern ein Turbo für das ganze Unternehmen.
von Dominik Grollmann
Spätestens wenn es um Entwicklung, Marketing und Vertrieb geht, kommt heute kein Business-Modell mehr ohne digitale Komponente aus. Digitalisierung wird deswegen gerade mit enormer Geschwindigkeit zu einem Schlüsselelement jeder Geschäftsstrategie. Agile Entwicklung - Stichworte: Scrum und Kaban - soll dabei für die notwendige Beweglichkeit sorgen. Doch so wirksam diese Ansätze im Projektmanagement sind, so wenig greifen sie in die IT-Architektur ein. Doch mit MACH gibt es ein Entwicklungskonzept, das nicht nur die Entwickler, sondern die ganze IT-Infrastruktur beweglicher machen soll.
MACH statt Monolith
Monolithische Software-Architektur ist die klassische Bauweise in der IT. Alle Funktionen werden in eine Applikation gepackt. Gerade wenn die Anwendungen über die Jahre aber einen gewissen Umfang erreicht haben, zeigen sich die Nachteile dieser Vorgehensweise:
- Das gesamte Projekt ist auf eine Programmiersprache und Entwicklungsumgebung festgelegt.
- Die Anwendung wird über die Jahre unübersichtlich, lange Einarbeitungszeiten sind nötig.
- Verteiltes Arbeiten wird zu einer komplexen Management-Aufgabe mit fehleranfälligen Abstimmungsprozessen.
- Je älter das Produkt wird, desto schwieriger wird es, MitarbeiterInnen mit den entsprechenden Fähigkeiten zu finden.
- Nach jeder Änderung muss die gesamte Software kompiliert, getestet und veröffentlicht werden. Alleine dieser Aufwand verhindert schnelle Änderungen. Zudem entstehen beim Update oft Ausfallzeiten.
- Die Anwendung lässt sich nur schwer skalieren. Die Performance lässt sich auf die Schnelle manchmal nur steigern, indem die Anwendung mehrfach geklont und auf verschiedene Server ausgelagert wird.
- Neue, fortschrittlichere Software-Konzepte lassen sich nicht in die bestehende Anwendung integrieren - zumindest ist es kaum praktikabel, weil sie zu sehr in die Grundlagen eingreifen würden.
Im Laufe nur weniger Jahre entsteht so eine typische Legacy-Software, die von der folgenden Entwicklergeneration verflucht wird. Aber schlimmer noch - sie bremst auch den gesamten Betrieb:
- Neue Entwickler brauchen lange Anlernzeiten, um den unübersichtlichen Code und die gewachsenen Abhängigkeiten zu verstehen.
- Große Teams müssen geführt werden. Dies führt zu einem hohen, oft ineffizienten und fehlerbehafteten Abstimmungsbedarf.
- Die Software ist schwerfällig und kann kaum skalieren. Oft liegt die einzige Lösung zur Performance-Steigerung darin, die Anwendung mehrfach zu klonen und die Last auf mehrere Server zu verteilen (Load-Balancing).
- Die Wartbarkeit des Systems leidet, da sich ein Update immer auf die komplette Anwendung bezieht.
- Wartungsarbeiten sind häufig mit Ausfallzeiten verbunden.
Mehr Geschwindigkeit mit MACH
Unter dem Namen MACH ist ein Konzept populär geworden, das mit den genannten Nachteilen radikal aufräumt. Es handelt sich um eine Software-Architektur, die als wesentliche Bausteine auf Microservices, API, Cloud und Headless setzt - das Kunstwort "MACH" setzt sich aus den Anfangsbuchstaben dieser Begriffe zusammen.
Das wesentlichste Merkmal dieses Konzepts bilden dabei Microservices und APIs. Die gesamte Anwendung wird in ihre einzelnen Funktionen zerlegt. Das Backend eines Shopsystems besteht beispielsweise aus einem Product Information Management (PIM), einer Suche, einem Warenkorb, einem Ordermanagement und einem Payment-Service. Diese Funktionen werden nun nicht als Ganzes in einen langen Quellcode gegossen, sondern jeweils als eigenständige, separat lauffähige Applikationen umgesetzt.
Der Warenkorb ist in diesem Beispiel eine eigenständige App, die nichts anderes kann, als in einer Datenbank die von jedem Nutzer bzw. jeder Nutzerin ausgewählten Artikel zu verwalten, im ERPSystem zu reservieren und auf Anfrage eine Liste der von einer Userin oder einem User gewählten Artikel auszugeben. Genauso verhält es sich mit den weiteren Funktionen. Das Gesamtsystem entsteht erst aus der Verknüpfung aller Einzelanwendungen, die über APIs miteinander kommunizieren und verwoben werden.
Diese Architektur ist zugleich dafür prädestiniert, um die Anwendung (oder Teile davon) in die Cloud auszulagern. Genau genommen bilden die Microservices ohnehin ihre eigene Cloud - egal ob sie On-Premise oder remote gehostet sind. Weil sowieso alles Cloud ist, können einzelne Teile der Gesamtanwendung auch leicht remote gehostet werden oder von ganz anderen Systemen - etwa Unternehmenssoftware - beigesteuert werden. Der angefragte Service muss lediglich in der Lage sein, entsprechend der Schnittstellenbeschreibung mit dem Gesamtsystem zu kommunizieren.
Auf diese Weise lassen sich leicht Webservices oder bestehende Unternehmenssoftware einbinden. Das erwähnte Shopsystem kann beispielsweise die Daten aus einem bestehenden PIM und CRM verwenden, ohne diese erst importieren zu müssen. Die Zahlungsabwicklung kann an einen externen Payment Service Provider (PSP) übergeben werden, während die Bestellungen direkt ins ERP geschrieben werden. Für eine MACHAnwendung macht es keinen substantiellen Unterschied, ob sie mit einem "eigenen" Microservice oder einer remote gehosteten 3rd-Party-Software kommuniziert. Je mehr Software in einem Unternehmen MACH-fähig ist (also die APIs beherrscht) bzw. selbst auf MACHArchitektur basiert, desto leichter fällt die Integration.
Als letztes Prinzip wird MACH Headless umgesetzt. Bedeutet: Die Mircroservices stellen die Gesamtfunktionalität bereit, nutzbar wird sie aber erst durch ein wiederum eigenständiges Frontend. Das hat gleich zwei Vorteile: Einerseits erlaubt die Trennung von Front- und Backend dynamische und zugleich schlanke Benutzeroberflächen (weil die Services serverseitig ausgeführt werden).
Zum anderen lässt sich das Backend über die verschiedensten Kanäle ansprechen: Egal ob Web-Shop, mobile App, POSTerminal, Sprachassistent oder In-Car-Integration - alle Anwendungen greifen auf dasselbe Hintergrundsystem zurück. Alle Funktionen stehen auf diese Weise überall in Echtzeit zur Verfügung und es gibt keinerlei Doubletten, gespiegelte Datensätze oder Synchronisationsaufwand.
Enorme Erleichterungen in der Entwicklung
Ist eine MACH-Anwendung gut geplant, kann die Entwicklung enorm profitieren. Gut geplant heißt in diesem Fall, dass die einzelnen Microservices optimalerweise einen Geschäftsprozess abbilden und so dimensioniert sind, dass sie von einem kleinen Entwicklerteam in rund einem Monat komplett neu geschrieben werden können.
Auf diese Weise bleibt die Einarbeitungszeit kurz und der zu bearbeitende Code übersichtlich. Es gibt keine versteckten Abhängigkeiten oder Code-Wildwuchs in ungepflegten Bibliotheken. Dadurch sinkt der Kommunikationsaufwand im Team enorm, die Entwicklungszeiten sind extrem kurz und das Testing deutlich vereinfacht. Die Eigenständigkeit und Unabhängigkeit der einzelnen Microservices ist so hoch, dass sogar problemlos die Programmiersprache gewechselt werden kann.
Aber das ist noch nicht alles. Weitere Vorzüge sind:
- Microservices benötigen aufgrund ihrer geringen Größe keine schwergewichtigen Frameworks.
- Sie lassen sich völlig unabhängig voneinander entwickeln, testen und live schalten. Dadurch wird Continuous Delivery möglich.
- Die Architektur unterstützt die Arbeit in unabhängigen Teams, die sich flexibel auslagern lassen.
- Der geringe Entwicklungsaufwand erleichtert Experimente - sei es eine neue Sprache, ein neues Framework oder eine neue Funktion.
- Unbrauchbare Lösungen lassen sich jederzeit mit vertretbarem Aufwand durch eine Neuentwicklung ablösen, ohne dass der Betrieb leidet.
- Die Skalierbarkeit des Gesamtsystems gewinnt deutlich, da sich jeder Service unabhängig von anderen Services skalieren lässt.
- Die grundlegende Architektur der Software kann nicht unter Nachlässigkeiten und Workarounds leiden, da sie durch die APIs definiert ist. Die Schnittstellen dienen zugleich der Qualitätssicherung.
- Microservices kommen der agilen Entwicklung entgegen. Überschaubare Teams, überschaubare Aufgaben und überschaubarer Aufwand minimieren Reibungsverluste.
Dadurch werden doch wieder abschließende Ende-zu-Ende-Tests nötig und es bedarf einer nicht immer ganz trivialen Versions-Verwaltung der Einzelmodule. Außerdem muss gut überlegt werden, auf welche Daten zentral zugegriffen werden muss (was das Konzept der eigenständigen Microservices aufweicht) und welche repliziert werden können.
Hoher strategischer Nutzen
Auch wenn das Microservice-Konzept nicht frei von Nachteilen ist und in der Praxis einige Einschränkung erfährt, zeigt sich doch, dass schon aus Entwicklersicht die Vorzüge überwiegen. Das Unternehmen wird insgesamt schneller, die Software flexibler und anpassungsfähiger. Dies ist schon für sich genommen ein strategischer Vorteil.
Noch gewichtiger wird dieser Aspekt aber durch den technologischen Wandel, der sich ringsherum vollzieht. Immer mehr Geräte und Anwendungen sind vernetzt und müssen auf Services zugreifen und Geschäftsprozesse auslösen. Sie alle benötigen einen möglichst niederschwelligen Zugang zu Services und Ressourcen, wenn sie nahtlos angebunden werden sollen. Einige Beispiele:
- Distributed Computing. Eine Microservice-Architektur ermöglicht es, selbst Dienste für andere anzubieten oder auf Drittdienstleistungen zuzugreifen. So kann etwa eine Fahrplanabfrage oder eine Recommendation-Engine per externem Microservice angeboten oder eingebunden werden, als wäre sie Bestandteil der eigenen Applikation.
- Smart Devices. Auf API-Ebene lassen sich Informationen aus einer Vielzahl von Quellen entnehmen. So können IoT-Geräte in die Applikation eingebunden werden und eine Bestellung beispielsweise durch den Druck auf einen physischen Knopf auslösen. Sensoren aus vernetzten Maschinen, Smarthome-Geräten, Connected Cars oder Wearables können problemlos eingewoben werden.
- Headless-Service. Umgekehrt wird auch die Informationsbereitstellung und -aufbereitung getrennt. Ein Shopsystem kann den Lieferstatus beispielsweise über Microservice und API direkt beim Logistikdienstleister abrufen und an eine Smartwatch-Applikation ausliefern. So kann die Anfahrt des Lieferdienstes sogar kontinuierlich aktualisiert werden, ohne dass jede Mal ein Visit ausgelöst werden muss. Der Microservice stellt nur die Daten für das Frontend bereit, die Aufbereitung übernimmt die Applikation.
- Agenten-Schnittstelle. Auf dieselbe Weise lassen sich Schnittstellen schaffen, auf die Software-Agenten zugreifen können - sei es für eine Reiseplanung, das Kinoprogramm oder um die Bestellung einer Tintenpatrone zu platzieren. Der Austausch mittels API erfolgt dabei deutlich schneller und schlanker, als wenn ein Webinhalt geparst werden soll.
- Prozesslogik. Da mit Microservices ein Geschäftsvorgang optimalerweise ohnehin schon in seine einzelnen Prozessschritte zerlegt ist, können sehr einfach neue Geschäftsmodelle modelliert werden. Wenn ein Shopbetreiber beispielsweise ein Abo-Modell ausprobieren möchte, muss er die bestehenden Microservices nur neu gruppieren und nur sehr wenige (Aboverwaltung) neu programmieren. Auf diese Weise kann sehr flexibel auf neue Geschäftsvorfälle reagiert werden.
Im Frontend, weil die Gerätevielfalt der KundInnen drastisch zunimmt. Die Fähigkeit von Microservices, Daten headless bereitzustellen, erleichtert die Integration neuer Plattformen erheblich. Auf der Backend-Seite zählt dagegen die Flexibilität bei der Verknüpfung und Umgestaltung von Anwendungen zu den großen Vorzügen.
In jedem Fall bilden Microservices jedoch auch eine neue Herausforderung für das Change-Management des Unternehmens. Denn nicht nur Entwicklungsabteilungen müssen komplett umdenken - ein Wandel in der Prozesslogik erfasst fast immer auch Teile der Unternehmensstruktur. Und das stößt fast immer auf erhebliche Widerstände.
