Contact
Evolutionary Architecture • 11 Minuten Lesedauer

Wie implementiert man MACH Technologie im Unternehmen? Transformation von einer monolithischen Software-Architektur zu einer modernen MACH-Architektur

Jörg Oberdieck | 08-06-2022

Dies ist der zweite Artikel unserer Artikelserie über die MACH Architektur. Im ersten Teil wurde erklärt, was MACH ist und warum die Kundenbedürfnisse eine MACH Architektur notwendig machen. In diesem Teil zeigen wir Ihnen, für welche Unternehmen sich MACH am besten eignet, wie ein mögliches Vorgehen bei der Transformation von einer monolithischen Software-Architektur zu einer MACH-Architektur aussehen könnte und welche Unternehmen bereits erfolgreich auf eine MACH-Architektur umgestellt haben.

Wann macht MACH Sinn?

Unternehmen, die gerade erst am Anfang der Digitalisierung Ihrer Vertriebskanäle stehen, ein einfaches Geschäftsmodell mit ein oder zwei Eigenmarken besitzen, sowie wenig technisches Knowhow aufweisen und zum ersten Mal E-Commerce ausprobieren wollen, ist eine zentrale Out-of-the-Box-Lösung wahrscheinlich die bessere Lösung.

Für digital reifere Unternehmen, die:

  • komplexe Anforderungen an digitale Kanäle haben
  • komplexes Geschäftsmodell, Großunternehmen, wachstumsstarke Marken aufweisen
  • hohen technischer Reifegrad besitzen
  • Bedarf an modernen und flexiblen Anwendungen haben

würde ein Wechsel zur MACH-Architektur einen enormen Sprung nach vorne bedeuten.

Im Folgenden sehen Sie eine übersichtliche Gegenüberstellung vom Monolithen und MACH in Anlehnung an Amplience:

202205_SQLI_DE_infographic_mach_blog-07

Mögliches Vorgehen bei der Transformation von einer monolithischer Software-Architektur zu einer MACH -Architektur

Letztendlich kommt es bei der Transformation einer monolithischen Software-Architektur hin zu einer MACH Architektur immer auf den Einzelfall an.

Abb.: Traditionelle monolithische IT-Infrastruktur im E-Commerce

I. Mit dem „Head“ starten

Als sinnvoll hat sich aber herausgestellt, zunächst das Frontend auf Headless umzustellen und sich im Anschluss den nachfolgenden Bereichen zu widmen. Viele Commerce Frameworks wie z.B. commercetools oder SAP Commerce bieten hier eine Vielfalt an API’s an, die vom Frontend genutzt und implementiert werden können und somit einen schnellen Start ermöglichen.

Ist noch kein passendes CMS System vorhanden, ist auch hier eine vorausschauende Planung sinnvoll und es sollte geprüft werden, ob in Zukunft weitere Komponenten wie z.B. eine Digitale Engagement Plattform oder auch eine Customer Data Plattform aufgebaut werden sollen. Will man hier ebenfalls Best-of-Breed, oder macht es Sinn, ein CMS zu wählen, dass vielleicht aus dem gleichen Haus kommt und somit einfach in eine Customer Data Plattform oder Digital Experience Plattform integriert?


II. „Häufig“ verändernde Daten über API´s austauschen

Wurde das Frontend auf Headless umgestellt, so gilt es zu prüfen, welche weiteren Applikationen via API‘s angebunden werden sollen bzw. müssen. Es empfiehlt sich hier, sich zunächst auf „häufig“ verändernde Daten wie z.B. Preis oder Bestandsdaten im ERP-System zu konzentrieren und „weniger häufig“ veränderte Daten, wie Produktbilder oder -titel, im Nachgang zu betrachten.

Im Allgemeinem sollte man immer den Business Impact der einzelnen Applikationen definieren und zunächst das System, mit dem höchsten Impact auf API-basierte Kommunikation umzustellen.


III. Entwicklung in der Cloud und Aufbau von Mircoservices

Neue (Micro-)Services sollten auf einer Cloud-Architektur entwickelt und zur Verfügung gestellt werden, um sie einfacher von anderen Bereichen nutzen zu können. Die Umstellung von Commerce-Backend-Services auf modernen und flexiblen Mircoservices, macht bei sich schnell ändernden Kundenanforderungen oder bei der übergreifenden Nutzung der Services Sinn, wie z.B. ein Loyalty-System, welches über mehreren Channels wie z.B. POS, Online-Shop oder App benutzt wird.

Durch die Nutzung von APIs und ggf. neuen Microservices auf einer Cloud-Architektur ergeben sich viele Vorteile für das Unternehmen und letztendlich auch für den Kunden bzw. die Customer Experience.

Zum einen die losgelöste Weiterentwicklung des Frontends und der nachgelagerten Services, die Parallelisierung durch mehrere Teams, aber auch die Vereinfachung der Services und vereinfachte Skalierbarkeit neuer Services.

Alles zusammen führt zu einer schnelleren Reaktionsfähigkeit auf Marktanforderungen und somit auch zu schnelleren Roll-outs neuer Funktionen.

Wenn Sie mehr über die zugrundeliegenden Prinzipien wie Microservices, API, Cloud Commerce, Headless Commerce und ereignisgesteuerte Architektur erfahren möchten, lesen Sie gerne auch unsere Artikelserie über evolutionary Architecture.

 

Ein Bild, das Text, Monitor, Screenshot, Bildschirm enthält.

Automatisch generierte BeschreibungAbb.: Moderne MACH-Architektur

Was bedeutet die MACH Architektur für Ihr Projekt?

  1. Das Projektmanagement ist komplexer
    a. Integration verschiedener Systeme bedeutet auch das Zusammenbringen verschiedener Stakeholder auf Kunden- und auf Dienstleisterseite…
    b. …und diese müssen auch im Projektverlauf verfügbar sein.
    c. Im Scoping bedarf es einer ausgeprägten Genauigkeit, alle Systeme und damit verbundenen Prozesse und Datenflüsse müssen berücksichtigt werden

  2. Die Abstimmung zwischen den Entwicklerteams muss passen
    a. Getrennte Entwicklungsteams sind möglich und notwendig, die technischen Abhängigkeitsmomente müssen jedoch klar definiert und berücksichtigt werden (z.B. Verbindung von Front- und Backend über Schnittstellen)

  3. Definition der benötigten Informations- und Datenflüsse
    a. Datenflüsse und -herkünfte müssen final definiert sein. Das klingt einfach und logisch, ist es in der Realität von gewachsenen Systemen aber in den meisten Fällen nicht. Redundante Datenhaltung und Insellösungen sind spätestens bei der Entwicklung einer Headless-Architektur ein No-Go.

Unternehmen, die auf MACH-Architektur umgestellt haben

Amazon, heute die größte E-Commerce-Plattform der Welt, begann als bescheidener Buchladen. Eine zweistufige All-One-Plattform passte perfekt zu diesem, damals noch kleine Unternehmen. Als Amazon jedoch zu wachsen begann, stand es vor einem dringenden Problem mit der Skalierbarkeit des Systems. Typische Engpässe wie langwierige Implementierungen, schwer zu handhabende große Datenbanken, Schwierigkeiten beim Hinzufügen neuer Funktionen und schwankender Website-Traffic verzögerten das Wachstum des Unternehmens.

Zalando stieß im Jahr 2010 an seine Grenzen. Das Unternehmen hatte sich bereits von einem bescheidenen Shop, zu einer weltweit beliebten Modemarke gewandelt. Sein derzeitiges E-Commerce-System konnte die Last nicht mehr stemmen. Die Umstellung auf Microservices gab Zalando die Möglichkeit, die Integration neuer Innovationen zu beschleunigen und A/B-Tests durchzuführen, um die beste Konversion zu erzielen.

REWE skaliert den Online-Lebensmittelmarktplatz mit einer flexiblen MACH Architektur
Im Jahr 2020 konnte REWE auf der Grundlage von MACH die Anzahl der "Click-and-Collect"-Services in nur wenigen Wochen verdoppeln, eine branchenübergreifende Fulfillment-Plattform einführen und schließlich einen bequemen Zugang zu Lebensmitteln in ganz Deutschland zu einem sehr kritischen Zeitpunkt ermöglichen.

Netflix war eines der ersten Unternehmen, das feststellte, dass eine monolithische Architektur keine optimale Lösung für eine komplexe Anwendung ist, da die Komponenten in einer monolithischen Anwendung eng miteinander verbunden sind und ein einziger Fehler zu mehrtägigen Ausfallzeiten führen kann. Im VOD-Geschäft ist das für die Nutzer ein Dealbreaker, und das Risiko war zu hoch, um es zu tragen.

Fazit

Das war der zweite Teil zu unserem Blogbeitrag zur MACH Architektur.
In diesem Teil ging es darum, wann und vor allem für wen die MACH Architektur geeignet ist.
Denn: MACH ist nicht gleich MACH.
Es bedarf einer Analyse der internen (Kunden) und externen (Mitarbeiter) Bedürfnisse, um eine adäquate Architektur zu definieren und anschließend implementieren zu können. Hier bieten wir unser langjährige SQLI Expertise an. Wir wissen, was Unternehmen vor Herausforderungen stellt und wie wir diese überwinden können. Wir betrachten immer den Einzelfall. Gerne können Sie auch noch den ersten Blogbeitrag zum Thema lesen. Hier erklären wir, was MACH Architektur ist.

Eine Transformation kann auch stufenweise erfolgen, das ist der Vorteil des modularen Ansatzes!

Haben wir Ihr Interesse geweckt?

Kontaktieren Sie mich gerne, ich unterstütze Sie mit einem MACHbarkeits-Check.

Kontaktieren Sie Jörg

Microservices

whitepaper

Wie man mit Microservices startet - In 5 Schritten zum Erfolg

Download now
Picture of Jörg Oberdieck

Jörg Oberdieck

Customer Success Manager/ Senior Business Consultant