Monolithische oder ereignisgesteuerte Architektur?

In einem Webshop geht eine Bestellung ein, dann kopiert jemand die Daten in das Verwaltungssystem. Das Lager erhält eine separate Benachrichtigung, und die Rechnungsstellung beginnt erst, wenn ein Kollege den Bestand überprüft hat. In solchen Fällen ist die Frage nicht theoretisch: Monolith oder ereignisgesteuerte Architektur würde wirklich helfen? Bevor wir jedoch eine technologische Antwort geben, ist es sinnvoll zu verstehen, wo die Informationen stecken bleiben und welcher manuelle Schritt noch einen echten geschäftlichen Zweck erfüllt.

Bei vielen wachsenden Unternehmen ist nicht das System selbst das Problem. Das Problem ist, dass Menschen den Datentransfer zwischen den einzelnen Systemen, Teams und Verantwortungsbereichen durchführen. Dies ist langsam, fehleranfällig und schwer nachvollziehbar. Die Aufgabe der Architektur ist es nicht, modern zu wirken, sondern sicherzustellen, dass der Geschäftsprozess auch dann vorhersehbar funktioniert, wenn die Bestellmenge steigt, das Produktsortiment erweitert wird oder sich die Organisation ändert.

Was bedeutet Monolith in der Praxis?

In einer monolithischen Anwendung arbeiten die Hauptgeschäftsfunktionen in einem System. Zum Beispiel verwaltet dieselbe Anwendung Bestellungen, Kunden, Bestandsinformationen, Berechtigungen und die Rechnungsstellungsvorbereitung. Die Datenbank, die Geschäftsregeln und die Benutzeroberfläche sind typischerweise eng miteinander verbunden.

Dies ist kein Fehler und kein Synonym für einen veralteten Ansatz. Ein gut gestalteter Monolith kann für viele Unternehmen eine sehr gute Entscheidung sein. Die Regeln befinden sich an einem Ort, der Betrieb ist einfacher, es gibt weniger systemübergreifende Fehlerquellen, und ein Prozess mit mehreren Schritten kann in einer Transaktion abgewickelt werden. Wenn bei der Erfassung einer Bestellung gleichzeitig Bestand reserviert, Kreditrahmen überprüft und die Erfüllungsaufgabe erstellt werden muss, kann der Monolith eine klare Funktionsweise bieten.

Das Problem beginnt, wenn das System nicht mehr eindeutig getrennte Geschäftsbereiche bedient, sondern alle neuen Anforderungen an denselben Ort gelangen. Eine kleine Änderung in der Rechnungsstellung kann unerwartet den Lagerprozess beeinflussen. Eine Entwicklungsfreigabe erfordert die Installation der gesamten Anwendung. Wenn mehrere Teams an derselben Codebasis arbeiten, kann die Koordination allein die Änderung verlangsamen.

Dies ist jedoch auch eine Frage des Designs und der Organisation. Nicht jeder große Monolith ist unhandlich, und nicht jedes kleinere System verdient sofort eine Aufspaltung.

Wie funktioniert die ereignisgesteuerte Architektur?

Bei der ereignisgesteuerten Arbeitsweise sendet ein Geschäftsvorfall ein Signal an die anderen betroffenen Systeme. Ein solches Ereignis kann beispielsweise sein: „Bestellung aufgegeben“, „Ware eingetroffen“, „Produktionsvorgang abgeschlossen“ oder „Rechnung bezahlt“. Das System, das das Ereignis erzeugt, führt nicht unbedingt alle nachfolgenden Aufgaben aus. Stattdessen veröffentlicht es, was passiert ist, und die anderen Systeme reagieren in ihrem eigenen Verantwortungsbereich darauf.

Nehmen wir ein einfaches Beispiel. Der Webshop erfasst, dass eine neue Bestellung eingegangen ist. Das Bestandsverwaltungssystem reserviert die Ware, das Logistiksystem erstellt die Kommissionieraufgabe, die Kundenkommunikationslösung sendet eine Bestätigung, und das Reporting aktualisiert die täglichen Verkaufsdaten. Es ist nicht erforderlich, dass der Webshop alle Detailregeln kennt.

Dies ist besonders vorteilhaft, wenn mehrere Systeme mit unterschiedlichen Lebenszyklen auf dieselbe geschäftliche Veränderung reagieren müssen. Produktion, Lager, Transportplanung, Kundenservice und Finanzen arbeiten nicht unbedingt mit derselben Geschwindigkeit oder in derselben Anwendung. Ereignisse können helfen, dass Informationen nicht per E-Mail, Tabelle oder Telefon weitergegeben werden.

Die ereignisgesteuerte Architektur bedeutet jedoch nicht, dass alles sofort und unter allen Umständen aktualisiert wird. Bei einigen Prozessen ist es akzeptabel, dass der Bestellstatus erst nach einigen Sekunden in der Lageransicht erscheint. In anderen Fällen, wie bei der Bestandsreservierung oder der Zahlungsfreigabe, sind strengere Regeln erforderlich. Die beiden Situationen sollten nicht gleich behandelt werden.

Monolith oder ereignisgesteuerte Architektur: keine echte Ja-Nein-Frage

Die beiden Ansätze werden oft als falsche Wahl behandelt. Als ob ein Unternehmen entweder eine einzige große Anwendung oder viele, durch Ereignisse verbundene Dienste haben könnte. In Wirklichkeit ist die Mehrheit der gut funktionierenden Umgebungen hybrid.

Ein zentrales Verwaltungs- oder Produktionssystem kann monolithisch bleiben, während es bestimmte Geschäftsvorfälle an andere Systeme weitergibt. So funktionieren die Basisprozesse an einem Ort auf kontrollierte Weise, aber der Webshop, die Transportverbindung, die Kundenbenachrichtigung oder die Datenplattform werden nicht zur Geisel der internen Logik des zentralen Systems.

Dies ist in der Regel ein sichererer Entwicklungsweg als eine plötzliche Aufspaltung eines gesamten Systems. Wenn das Unternehmen derzeit ein zuverlässiges, aber schwer integrierbares System hat, muss zunächst geklärt werden, welche Geschäftsvorfälle wichtig sind. Nicht technisch bedingte Datenänderungen, sondern echte Geschäftszustände: die Produktionseinheit ist fertiggestellt, das Paket wurde an den Kurier übergeben, eine Genehmigungsfrist ist abgelaufen, es gab eine Abweichung im Bestand.

Wann ist es gerechtfertigt, den Monolithen beizubehalten?

Der Monolith ist sinnvoll, wenn die Prozesse eng miteinander verbunden sind, Änderungen selten sind und das Geschäft keine mehreren, eigenständig entwickelnden Systeme benötigt. Bei einer internen Verwaltungsanwendung, die von wenigen, gut definierten Rollen genutzt wird, ist die geringere Betriebslast oft wertvoller als das Versprechen der technologischen Trennung.

Es kann auch gerechtfertigt sein, wenn die Organisation nicht die Kapazität hat, komplexe Integrationen zu betreiben. Für das Ereignismanagement reicht es nicht aus, einen Nachrichtenvermittler einzuführen. Es braucht Überwachung, Protokollierung, Berechtigungsmanagement, Wiederholungsstrategien, Fehlertoleranz und klare Verantwortlichkeiten. Wenn eine Verarbeitung fehlschlägt, muss bekannt sein, wer benachrichtigt wird, wie die Daten korrigiert werden und was mit den anhängigen Prozessen geschieht.

Der Monolith ist nicht gut, weil er einfach genannt wird, sondern weil seine Grenzen klar sind. Die Funktionen, Daten und Verantwortlichkeiten vermischen sich nicht unkontrolliert.

Wann bringt die ereignisgesteuerte Arbeitsweise geschäftlichen Wert?

Der ereignisgesteuerte Ansatz ist stark, wenn es im Unternehmen viele Übergaben und wiederkehrende Koordination gibt. Ein typisches Zeichen ist, wenn mehrere Teams über dieselbe Änderung Bescheid wissen müssen, dies aber heute manuell gelöst wird. Zum Beispiel sendet der Einkauf eine separate E-Mail an das Lager, das Lager führt eine separate Tabelle, und der Vertrieb erfährt erst später, dass eine Bestellung nicht erfüllt werden kann.

Es ist auch dort nützlich, wo neue verbundene Systeme erwartet werden. Ein Unternehmen nutzt heute nur einen Webshop und ein ERP, kann aber im nächsten Jahr ein Kundenportal, automatisierten Etikettendruck, Transportintegration oder eine Management-Datenplattform einführen. Wenn die grundlegenden Geschäftsvorfälle gut definiert sind, können die neuen Fähigkeiten mit geringem Risiko hinzugefügt werden.

Der wichtigste Vorteil ist jedoch nicht die technologische Flexibilität. Sondern dass sichtbar wird, was in einem Prozess passiert ist. Eine gut gestaltete Ereigniskette ermöglicht es, nachzuvollziehen, wann die Bestellung eingegangen ist, wann die Bestandsreservierung erfolgt ist, warum die Erfüllung gestoppt wurde und in welchem System eine Abweichung aufgetreten ist. Dies bietet eine bessere Entscheidungsgrundlage für das Management und entlastet die Mitarbeiter, die heute versuchen, die Geschichte aus dem Gedächtnis zusammenzusetzen.

Die versteckten Kosten: Komplexität und Verantwortung

Die ereignisgesteuerte Architektur ist keine kostenlose Flexibilität. Ein System kann sich verzögern, ein Ereignis kann zweimal eintreffen, der Empfänger kann vorübergehend nicht erreichbar sein, oder eine Geschäftsregel kann während des Prozesses geändert werden. Diese Dinge müssen im Voraus geplant werden.

Zum Beispiel reicht es nicht aus zu sagen, dass der Bestand bei der Bestellung reduziert werden soll. Es muss festgelegt werden, was passiert, wenn die Zahlung abgelehnt wird, wenn die Bestellung geändert wird, wenn das Lager weniger Ware findet oder wenn dasselbe Ereignis aufgrund eines technischen Fehlers zweimal verarbeitet wird. Solche Fragen sind tatsächlich Fragen der Geschäftskontrolle. Die Technologie kann sie nur dann richtig handhaben, wenn der Prozessverantwortliche und die Regeln klar sind.

Deshalb ist es gefährlich, nur auf Basis von Entwicklungstrends zu entscheiden. In einem zu früh aufgespaltenen System wird die frühere interne Komplexität einfach auf die Verbindungen zwischen den Systemen übertragen. Der Fehler liegt dann nicht mehr innerhalb einer Anwendung, sondern zwischen zwei oder drei Teams, Datenquellen und Verantwortungsgrenzen.

Welche Fragen sollte man sich stellen?

Vor der Auswahl der Architektur sollte man einen konkreten Prozess vom auslösenden Ereignis bis zum Abschluss verfolgen. Wer erfasst die Daten? Wo wird dieselbe Information erneut erzeugt? Für welchen Schritt sind E-Mail, Telefon oder separate Tabellen erforderlich? Wer kann sagen, warum ein Fall gestoppt wurde? Und welche Regel kennt nur ein erfahrener Mitarbeiter?

Wenn die Antworten darauf hinweisen, dass es wenige Systeme und stark miteinander verbundene Prozesse gibt, könnte ein geordneter Monolith die richtige Grundlage sein. Wenn viele separate Systeme, häufige Übergaben und ein wachsender Integrationsbedarf zu erkennen sind, könnte die Verbindung entlang von Ereignissen gerechtfertigt sein. Dazwischen gibt es viele Übergangslösungen, die schrittweise eingeführt werden können.

Eine gute Architektur ist nicht wertvoll, weil sie aus vielen Diensten besteht. Sondern weil der Weg einer Bestellung, einer Produktionsaufgabe oder einer Rechnung nicht in den Köpfen der Menschen, sondern in einem überprüfbaren Prozess existiert. Wenn dies geklärt ist, wird die technologische Entscheidung keine Glaubensfrage mehr sein, sondern eine gezielte geschäftliche Entwicklung.