Mit dem Baukastenprinzip zu einer skalierbaren und massgeschneiderten Software-Architektur

von Cuno Sieber am

Wie sich Unternehmen mit Composable Commerce für die Zukunft wappnen

Wenn Ihre Softwarearchitektur träge, zu komplex und zu wenig skalierbar erscheint, und mit den Business-Anforderungen kaum noch mithalten kann, ist es Zeit für einen Wechsel.

Nur: Welche sind sinnvolle und zukunftsfähige Lösungen? Was steckt hinter den gängigen Buzzwords? Wie setzt man die einzelnen Bausteine zu einer funktionierenden Gesamtarchitektur zusammen?

Im ersten Teil unserer Blogreihe möchten wir einige Grundlagen erklären.

Bei der Recherche nach modernen Technologien und Software stösst man sehr schnell auf die Begriffe “headless”, “Microservices”, “Cloud”, “SaaS”- oder auch “Composable Commerce”. Es handelt sich hierbei um Eigenschaften und Bestandteile von Systemarchitekturen, die sich in den letzten Jahren am Markt etablieren konnten. Sie sind eine Reaktion auf die früher sehr verbreiteten monolithischen Anwendungen. 

Die “All-in-one-Lösungen” waren nicht umsonst so beliebt: Anwender können verschiedene Daten innerhalb eines Tools verwalten, müssen sich nicht an unterschiedliche Eingabe-Benutzeroberflächen gewöhnen und oft sind die Resultate eines Prozessschrittes direkt in einem anderen sichtbar. Entwicklern macht die einheitliche Codebasis das Leben leichter. Gerade das initiale Aufsetzen solcher Systeme ist verhältnismässig einfach. 

Darin liegt aber auch schon der grosse Schwachpunkt. Ein massiver Block Software, der allen Ansprüchen gerecht werden soll, wird schnell komplex und durch die vielen Abhängigkeiten unflexibel. Das macht es schwierig, schnell auf neue Bedürfnisse zu reagieren oder neue Technologien einzubeziehen. Es ist oft nicht möglich, nur bestimmte Teile der Anwendung zu skalieren, ohne dass dies Auswirkungen auf andere Bereiche hat. Gleichzeitig gerät das gesamte System unter Druck, wenn ein einzelner Teil an seine Grenzen kommt, wie beispielsweise bei Spitzenbelastungen in Onlineshops an einem Black Friday.

Dem kann eine modulare, aus Einzelkomponenten bestehende Architektur entgegenwirken. Voraussetzung hierfür sind eine skalierbare Infrastruktur, (headless) Services, APIs und durchdachte Architekturen, die ich nun näher erklären möchte. Danach kommen wir zur Anwendung im Commerce-Bereich, dem sogenannten Composable Commerce.

Headless

“Headless” bezeichnet eine Softwarearchitektur, bei der das Frontend (der Kopf, englisch Head = das, was der Benutzer sehen kann) entkoppelt ist vom Backend (dem Teil der Software, der die eigentliche Anwendungslogik enthält).

Ein Beispiel: Eine eCommerce Plattform hält die Daten zu Produkten, Verfügbarkeiten, Preisen und Kunden in Backend Systemen. Als Ausgabekanal gibt es jedoch zwei verschiedene Applikationen, welche auf dieselbe Datenbasis zugreifen: eine Webshop Applikation die im Browser läuft und eine native Mobile Applikation. Beide werden separat von der headless eCommerce-Plattform entwickelt und können völlig unterschiedlich aussehen. Die Prozesse dahinter teilen sie sich jedoch.

Der Vorteil besteht darin, dass die Backend-Applikation in verschiedenen Anwendungsfällen zum Einsatz kommen kann und die entwickelte Logik somit wiederverwendbar wird. Wie die Anwendungsfälle konkret aussehen, spielt dabei keine Rolle und kann gänzlich unterschiedlich ausfallen, deshalb hört man in dem Kontext auch öfter den Begriff “multi experience”.

Microservices

Eine Microservice-Architektur ist eine Softwarearchitektur, die auf dem Konzept von einzelnen, unabhängigen Diensten (sogenannte "Microservices") basiert, die jeweils eine spezifische Funktion erfüllen. Jeder Microservice wird als eigenständige Anwendung entwickelt und kommuniziert mit anderen Microservices über eine API (Schnittstelle).

Die Idee hinter einer Microservice-Architektur ist es, die Komplexität einer grossen Anwendung zu reduzieren, indem sie in kleinere, spezialisierte Dienste aufgeteilt wird. Jeder Microservice ist eigenständig und kann in einer beliebigen Programmiersprache oder Technologie entwickelt werden. Wichtig ist, dass er mittels Schnittstelle kommunizieren kann. Teams können dadurch unabhängig voneinander arbeiten, was die Geschwindigkeit der Entwicklung und die Qualität der Anwendung erhöhen kann.

Die Microservice-Architektur ist flexibler und skalierbarer als monolithische Anwendungen. Wenn eine Anwendung wächst, können neue Microservices hinzugefügt werden, um zusätzliche Funktionalitäten bereitzustellen. Jeder Microservice kann unabhängig vom nächsten skaliert werden, um mit der jeweiligen Last umzugehen, die er verarbeitet.

Composable Commerce - Shop nach dem Baukastenprinzip

Vor dem Hintergrund dieser Entwicklungen ist es nur konsequent, dass sich auch im eCommerce etwas tut. Gerade Shopsysteme müssen verschiedene Business-Logiken abbilden. Sie bündeln komplexe Informationen und interagieren in der Regel mit weiteren Umsystemen. Kein Wunder, halten “Headless & Co." auch in dieser Welt Einzug. Im eCommerce etabliert sich mittlerweile der Begriff “Composable Commerce”.

Composable Commerce beschreibt eine modulare, auf (Micro)Services basierende Architektur, die Unternehmen die Möglichkeit gibt, verschiedene Funktionen miteinander zu kombinieren, um eine massgeschneiderte eCommerce-Lösung zu erstellen. Die Services werden anhand ihrer Geschäftsfähigkeiten gebündelt. Deshalb spricht man hier auch von “Packed Business Capabilities”, kurz PBCs.

Beispiele für PBCs im eCommerce-Umfeld sind:
  • Commerce
  • Inhalte und Assets (CMS / DAM)
  • Customer Identity and Access Management (CIAM)
  • Analytics
  • Payment Provider
  • Product Recommendations / Personalisierung
  • Suche
Man integriert also jene Dienste, welche man braucht und die den eigenen Anforderungen am besten entsprechen.

Ein Beispiel einer solchen Composable Commerce-Landschaft könnte so aussehen:
composable ecommerce pbc

MACH mir einen Shop daraus

Wie kommen die verschiedenen Elemente nun zusammen? In der Abbildung oben steckt bereits ein bewährter Architektur-Ansatz, der die beschriebenen Elemente miteinander verbindet: MACH. In dieser Kombination können die Technologien ihr Potenzial entfalten und bilden daher die ideale Grundlage für Composable Commerce.

M (Microservices): Einzelne Anwendungen bzw. Services zum Bereitstellen von Business Funktionalität, welche unabhängig entwickelt, deployed und gewartet werden können.

A (API): Die gesamte Funktionalität ist mittels API (Schnittstelle) zugänglich. Services kommunizieren untereinander über die bereitgestellten APIs.

C (Cloud): Typischerweise werden die Lösungen nicht mehr selbst gehostet, sondern als SaaS Modell in der Cloud betrieben. Dadurch werden Wartungsaufwand, Skalierung und automatische Updates ausgelagert.

H (Headless): Frontend wird vom Backend entkoppelt gebaut und ist somit kanalunabhängig und nicht an spezielle Technologien gebunden.

Wer mehr über diesen Ansatz erfahren möchte, wird bei der MACH Alliance (https://machalliance.org) fündig, die den Ansatz entwickelt und zertifiziert hat.

Fazit 1 - Das Baukastenprinzip ist sinnvoll

Die Vorteile des Composable Commerce Ansatzes mit einer MACH-Architektur liegen auf der Hand: es können für einzelne Business Anforderungen die besten auf dem Markt verfügbaren Anwendungen (Best-of-Breed) miteinander kombiniert werden. Seien es Tools von einem oder mehreren Herstellern oder in einzelnen Fällen auch Eigenentwicklungen, alle Komponenten lassen sich über APIs miteinander vernetzen und sich so zu einem leistungsfähigen Gesamtsystem zusammenstellen.

Mit einem solchen Gesamtsystem kann auf kurzfristige Bedürfnisse wie Spitzenlasten unmittelbar reagiert werden (temporäre Leistungssteigerung einzelner Microservices). Auch zukünftige veränderte Marktanforderungen können so sehr schnell und zielgerichtet bedient werden (Integration neuer Komponenten, Weiterentwicklung/Erweiterung bestehender PBCs).

Fazit 2 - Es ist ein Umdenken erforderlich

Warum braucht es dennoch Zeit und auch etwas Mut, diese Entwicklungen für sich selbst zu nutzen und im eigenen Unternehmen zu etablieren?

Um ein Composable Commerce auf die Beine zu stellen, braucht es mehr als nur funktionierende Einzelteile. Ein wichtiger Erfolgsfaktor ist die Gesamtarchitektur, und darin liegt auch die erste Herausforderung. Das Thema Architektur hat sich im Vergleich zu jener von monolithischen Systemen stark verändert und daher fehlt es den Verantwortlichen oft an Erfahrung in diesem Bereich. Die Konzeption eines hoch modularen Systems ist jedoch sehr komplex und braucht einiges an Überlegungen.

Hat man diese Hürde genommen und Ideen und Konzepte ausgearbeitet, steht schon die nächste Herausforderung vor der Tür: die damit verbunden Business-Prozesse passen vermutlich nicht mehr in die neue Welt und sind ebenfalls anzupassen. Was mit nicht zu unterschätzenden Spannungen mit den betroffenen Abteilungen verbunden sein kann: die Produktmanager, die Verkaufsleute, die Servicemitarbeiter, ... alle wollen mitreden, das Beste für ihren Bereich herausholen und sich dabei keinem IT System unterwerfen.  Hier ist Change Management gefragt, um bei den betroffenen Personen Verständnis zu schaffen, was diese veränderten Rahmenbedingungen genau bedeuten. Gemeinsam kann man dann erörtern, welche Vorteile und Erleichterungen daraus entstehen und welche Umstellungen in der gewohnten Zusammenarbeit und Prozessen nötig sind. 

Wenn der Change Manager dort seine Arbeit getan hat, darf er auch schon zu seinen nächsten Klienten ziehen: diejenigen, welche die Systeme bedienen, werden inzwischen sicher auf die Barrikaden gegangen sein. CMS ohne WYSIWYG -Experience, CRM ohne integriertes Newsletter-Tool, fünf verschiedene nicht-gebrandete Systeme, um eine News zu publizieren?! Das kann Ärger geben. Wer Glück hat, findet einen netten Entwickler, der den Anwendern technische Helferlein zur Seite stellt, die ihm die Benutzung einfacher machen. Doch da steht auch schon der CTO auf der Matte und beschwert sich, dass ihm genau die fähigen Entwickler ausgehen. Wie soll er denn in Zeiten des Fachkräftemangels noch einen erfahrenen Commerce-Entwickler UND einen Data-Science-Spezialisten auftreiben?! Das wird spannend…

Die gute Nachricht ist: diese Herausforderungen sind händelbar. 
Es gibt viele Möglichkeiten, die einzelnen Schritte technisch zu unterstützen. Vor allem aber ist es wichtig, die Menschen in diesem Prozess mitzunehmen, ihre Bedürfnisse ernstzunehmen und sie zu unterstützen.

Nur so steht ein Composable Commerce letzten Endes nicht nur auf technologisch bestem Fundament, sondern wird auch aktiv genutzt und von allen wichtigen Beteiligten weiterentwickelt. Das ist der wirkliche Grundstein für eine zukunftssichere eCommerce-Lösung.

Kommende Beiträge zum Thema

Michael Schlegel-Iten wird anhand unserer Erfahrungen näher auf die Vorteile aber auch Herausforderungen von Composable Commerce aus Business-Sicht eingehen.

Auch für alle Techies folgt ein Beitrag, in dem wir mit einem Praxisbeispiel die geeigneten Technologien und unsere Learnings aufzeigen.

 

Wie gefällt Ihnen unser Blog? Schreiben Sie uns: hello@diselva.com


Wir bei diselva bringen die Erfahrung und Kompetenz mit, um Sie in einem eCommerce- oder auch anderen Projekten zielführend zu unterstützen. Wir begleiten den Weg hin zu einer modernen und zukunftsfähigen Software-Architektur, von der Konzeption über die technische Umsetzung bis hin zur Einführung des neuen Systems und bieten Hilfestellung bei der Koordination aller involvierten Stakeholder. 

 

avatar

Cuno Sieber

Software Architect & Partner

Zum Profil