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 hängen 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 die Datenübergabe zwischen den einzelnen Systemen, Teams und Verantwortungsbereichen von Menschen durchgeführt wird. Dies ist langsam, fehleranfällig und schwer nachvollziehbar. Die Aufgabe der Architektur ist nicht, modern zu erscheinen, 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 laufen die Hauptgeschäftsfunktionen in einem System. Zum Beispiel verwaltet dieselbe Anwendung Bestellungen, Kunden, Bestandsinformationen, Berechtigungen und die Vorbereitung der Rechnungsstellung. Datenbank, Geschäftsregeln und 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 besonders gute Entscheidung sein. Die Regeln sind an einem Ort, der Betrieb ist einfacher, es gibt weniger systemübergreifende Fehlerquellen, und mehrere Schritte eines Prozesses können in einer Transaktion behandelt 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 Funktionalität 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. Wegen einer Entwicklungsfreigabe muss die gesamte Anwendung installiert werden. 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 sofortige Aufspaltung.

Wie funktioniert die ereignisgesteuerte Architektur?

Bei der ereignisgesteuerten Arbeitsweise sendet ein Geschäftsvorfall ein Signal an die anderen betroffenen Systeme. Solche Ereignisse können beispielsweise „Bestellung aufgegeben“, „Ware eingetroffen“, „Fertigungsoperation abgeschlossen“ oder „Rechnung bezahlt“ sein. 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 notwendig, dass der Webshop alle Detailregeln kennt.

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

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 sind die meisten gut funktionierenden Umgebungen hybrid.

Ein zentrales Verwaltungs- oder Produktionssystem kann monolithisch bleiben, während es definierte 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 die plötzliche Auflösung eines gesamten Systems. Wenn das Unternehmen derzeit ein zuverlässiges, aber schwer zu integrierendes System hat, muss zuerst geklärt werden, welche Geschäftsvorfälle von Bedeutung sind. Nicht technisch verstandene Datenänderungen, sondern echte Geschäftszustände: das Fertigungslos ist fertiggestellt, das Paket wurde dem Kurier übergeben, eine Genehmigungsfrist ist abgelaufen, es gab eine Abweichung im Bestand.

Wann ist es gerechtfertigt, den Monolithen beizubehalten?

Der Monolith spricht dafür, wenn die Prozesse eng miteinander verbunden sind, die Änderungen selten sind und das Geschäft keine Notwendigkeit für mehrere, eigenständig wachsende Systeme hat. Bei einer internen Verwaltungsanwendung, die von wenigen, klar definierten Rollen genutzt wird, ist die geringere Betriebslast oft mehr wert 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 die Ereignisverarbeitung reicht es nicht aus, einen Nachrichtenvermittler einzuführen. Es braucht Überwachung, Protokollierung, Berechtigungsverwaltung, Wiederholungsstrategie, Fehlertoleranz und klare Verantwortlichkeiten. Wenn eine Verarbeitung fehlschlägt, muss bekannt sein, wer benachrichtigt wird, wie die Daten korrigiert werden und was mit den abhängigen Prozessen passiert.

Der Monolith ist nicht gut, weil wir ihn einfach nennen, sondern weil seine Grenzen klar sind. Die Funktionen, Daten und Verantwortlichkeiten vermischen sich nicht unkontrolliert.

Wann bringt die ereignisgesteuerte Arbeitsweise geschäftlichen Nutzen?

Der ereignisgesteuerte Ansatz ist stark, wenn es im Unternehmen viele Übergaben und wiederholte 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 Führungsdatenplattform 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 stattgefunden hat, 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 aus dem Gedächtnis versuchen, die Geschichte zusammenzusetzen.

Die versteckten Kosten: Komplexität und Verantwortung

Die ereignisgesteuerte Architektur ist keine kostenlose Flexibilität. Ein System kann 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 müssen im Voraus geplant werden.

Zum Beispiel reicht es nicht aus zu sagen, dass bei der Aufgabe einer Bestellung der Bestand 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.

Mit welchen Fragen sollte man beginnen?

Vor der Auswahl der Architektur ist es sinnvoll, einen konkreten Prozess vom auslösenden Ereignis bis zum Abschluss zu verfolgen. Wer erfasst die Daten? Wo wird dieselbe Information erneut erzeugt? Welcher Schritt erfordert E-Mail, Telefon oder eine separate Tabelle? Wer kann sagen, warum ein Fall gestoppt wurde? Und welche Regel kennt nur ein erfahrener Mitarbeiter?

Wenn die Antworten darauf hindeuten, 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 steigende Integrationsanforderungen auftreten, 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 Fertigungsaufgabe oder einer Rechnung nicht im Kopf der Menschen, sondern in einem überprüfbaren Prozess existiert. Wenn dies geklärt werden kann, wird die technologische Entscheidung keine Glaubensfrage mehr sein, sondern eine gezielte geschäftliche Entwicklung.