Domänenübergreifende Workflows scheitern selten daran, dass es den Teams an Meinungen fehlt. Sie scheitern, weil Architekturentscheidungen nach Vorliebe statt nach Kriterien getroffen werden.
Das gilt besonders, wenn sich die Diskussion um API oder ereignisgesteuerte Architektur dreht. Ein Team will die Klarheit eines synchronen Request-Response-Modells. Ein anderes will die Skalierbarkeit und Entkopplung von Events. Oft haben beide recht, und genau deshalb zieht sich die Debatte hin.
Für BPM-Verantwortliche ist das keine theoretische Frage. Die Entscheidung wirkt sich darauf aus, wie zuverlässig Arbeit über Domänengrenzen hinweg fließt, wie sichtbar Prozessergebnisse bleiben und wie viel operative Reibung für Mitarbeitende und Kunden entsteht. Die eigentliche Frage ist nicht, welches Muster abstrakt betrachtet besser ist, sondern wie Sie für die jeweilige Aufgabe das richtige wählen.
Ein einfacher Abgrenzungstest kann dabei helfen.
Die meisten Integrationsdiskussionen bleiben an Vorlieben hängen, nicht an Kriterien.
APIs sind vertraut. Sie wirken kontrolliert, direkt und leicht nachvollziehbar. Events versprechen Flexibilität, Fan-out (die Verteilung an viele Empfänger) und lockerere Kopplung. In der Praxis brauchen domänenübergreifende Workflows oft beides, und trotzdem versuchen Teams, eine einzige Antwort zu erzwingen, weil das aus Architektursicht sauberer wirkt.
Das Problem: In Wirklichkeit sind Workflows nicht so sauber wie in der Theorie. Zu ihnen gehören:
- unmittelbare Geschäftsentscheidungen
- mehrere nachgelagerte Reaktionen
- betriebliche Einschränkungen
- Verantwortlichkeiten über mehrere Domänen hinweg
- unterschiedliche Erwartungen an Transparenz und Wiederherstellung
Ein besserer Entscheidungsrahmen ist deshalb situationsabhängig, nicht ideologisch.
Wenn Sie die Debatte abkürzen wollen, beginnen Sie mit diesen drei Fragen.
1. Braucht der Konsument sofort eine bestätigte Antwort?
Das ist der klarste Entscheidungspunkt.
- Ja → API
- Nein → Event
Muss ein Konsument sofort wissen, ob eine Aktion erfolgreich war, ist eine API in der Regel die richtige Wahl. Sie liefert eine direkte Antwort und einen verbindlichen Schnittstellenvertrag. Das zählt in Workflows, in denen der nächste Schritt ohne Bestätigung nicht weitergehen kann.
Beispiele:
- prüfen, ob ein Kundendatensatz aktualisiert werden kann
- einen Freigabebefehl absenden, der ein Ergebnis zurückliefern muss
- prüfen, ob eine Aufgabe zugewiesen werden kann, bevor die Arbeit weitergeht
In diesen Fällen hängt der Workflow von einer sofortigen Antwort ab. Ein Event würde Unsicherheit schaffen, wo der Prozess eine Bestätigung braucht.
Braucht der Konsument dagegen nicht sofort eine bestätigte Antwort, kann ein Event besser passen. Events sind nützlich, wenn es vor allem darauf ankommt, dass eine Änderung stattgefunden hat und andere Teile der Organisation in ihrem eigenen Tempo darauf reagieren können.
Beispiele:
- ein Prozessstatus ändert sich, und mehrere Systeme sollen davon erfahren
- ein abgeschlossener Fall löst Reporting, Benachrichtigungen und eine nachgelagerte Anreicherung aus
- eine Kundenänderung muss sich über mehrere Domänen verbreiten
Für BPM-Verantwortliche ist diese Frage so wirkungsvoll, weil sie die Architektur direkt an das Prozessverhalten bindet. Fragen Sie sich: Ist diese Interaktion ein Befehl, der eine Antwort verlangt, oder eine Änderung, die weitergegeben werden soll?
2. Wie viele nachgelagerte Systeme reagieren auf diese Änderung?
Die zweite Frage lenkt den Blick von der einzelnen Interaktion auf die größere Prozesslandschaft.
- Ein System → API
- Drei oder mehr → Events verringern doppelte Integrationen
Muss nur ein nachgelagertes System reagieren, kann eine API völlig angemessen sein. Die Abhängigkeit ist direkt, und die Integration bleibt vergleichsweise leicht verständlich.
Reagieren jedoch drei oder mehr Systeme auf dieselbe Änderung, sieht die Lage anders aus. Eigene Punkt-zu-Punkt-Integrationen für jedes dieser Systeme können Aufwand, Governance-Last und Wartungskomplexität schnell vervielfachen. Genau hier spielen Events ihre Stärke aus.
Ein ereignisgesteuerter Ansatz kann doppelte Integrationen verringern: Mehrere Konsumenten reagieren auf dasselbe Geschäftsereignis, ohne dass das auslösende System für jeden von ihnen eigene Logik braucht.
Nehmen Sie eine einfache Workflow-Änderung wie „Auftrag freigegeben“ oder „Fall abgeschlossen“. Diese eine Zustandsänderung muss womöglich Folgendes auslösen:
- einen Benachrichtigungsdienst
- ein Reporting-System
- einen Audit Trail
- einen Fulfillment-Prozess
- eine Aktualisierung der Kundenkommunikation
Wird jede dieser Reaktionen über eine eigene direkte Integration abgewickelt, wird die auslösende Domäne zur Koordinationszentrale, ob Sie das beabsichtigt haben oder nicht. Events können helfen, Domänengrenzen zu wahren und zugleich Fan-out zu unterstützen.
Für BPM-Verantwortliche treffen sich hier Architektur und Skalierbarkeit der Prozesse. Je mehr Reaktionen Sie auf eine geschäftliche Änderung erwarten, desto wertvoller wird die Weitergabe über Events.
3. Kann Ihr Team eine Event-Infrastruktur bereits betreiben?
Diese Frage überspringen viele Teams, und oft ist sie die wichtigste.
Denken Sie an Tracing, Idempotenz und Schema-Versionierung.
Fehlt das, frisst das Betriebsrisiko den Nutzen der Entkopplung auf.
Das sind die versteckten Kosten ereignisgesteuerter Architektur. Auf dem Papier bietet sie Flexibilität und lose Kopplung. In der Realität verlangt sie auch operative Disziplin. Kann Ihr Team Event-Flüsse nicht zuverlässig nachverfolgen, doppelte Verarbeitung nicht beherrschen und Schemaänderungen nicht über die Zeit steuern, können Instabilität und fehlende Transparenz die Vorteile der Entkopplung untergraben.
Das wiegt in BPM-Umgebungen besonders schwer. Dort müssen Prozessverantwortliche sicher wissen:
- was passiert ist
- wann es passiert ist
- was fehlgeschlagen ist
- wer betroffen ist
- wie die Wiederherstellung funktioniert
Umfragedaten zeigen diese Lücke deutlich. In einer Studie aus dem Jahr 2021 mit 840 Befragten, beauftragt von Solace und durchgeführt von Coleman Parkes, war ereignisgesteuerte Architektur (EDA) bei 72 % der Unternehmen breit im Einsatz, doch nur 13 % hatten die volle Reife erreicht. Die Lücke liegt in der Betriebsreife, nicht im Willen zur Einführung.
Diese Erkenntnis ist entscheidend. Die Einführung allein bedeutet nicht, dass eine Organisation bereit ist, sich bei domänenübergreifenden Workflows auf ereignisgesteuerte Muster zu verlassen. Viele Teams übernehmen das Konzept, bevor sie die Praktiken haben, die ein guter Betrieb erfordert.
Von BPM-Verantwortlichen wird oft erwartet, dass sie den Prozessfluss verbessern, Reibung verringern und für mehr Transparenz sorgen, und zwar über Systeme hinweg, die nie für ein elegantes Zusammenspiel entworfen wurden. Integrationsentscheidungen sind deshalb eine sehr praktische Frage, keine rein technische.
Die nützliche Erkenntnis daraus: Die meisten domänenübergreifenden Workflows brauchen beides.
- APIs für Befehle und verbindliche Schnittstellenverträge
- Events für Weitergabe und Fan-out
Das ist kein Kompromiss. Es ist ein treffenderes Entwurfsprinzip.
APIs einsetzen, wenn der Workflow Kontrolle braucht
APIs passen in der Regel besser, wenn Sie Folgendes brauchen:
- eine sofortige Bestätigung
- ein explizites Befehlsverhalten
- klare Verantwortlichkeit im Request-Response-Muster
- strikt geregelte Schnittstellenverträge zwischen Systemen
Im Prozess eignen sich APIs gut für Aktionen wie:
- eine Aufgabe starten
- eine Entscheidung übermitteln
- eine Prüfung anfordern
- einen Datensatz aktualisieren, wenn der Prozess das Ergebnis kennen muss
Sie fördern die Vorhersagbarkeit, die bei Workflow-Schritten mit Nutzerkontakt oder unter Zeitdruck oft unverzichtbar ist.
Events einsetzen, wenn der Workflow Reichweite braucht
Events passen in der Regel besser, wenn Sie Folgendes brauchen:
- die Weitergabe geschäftlicher Änderungen
- mehrere nachgelagerte Reaktionen
- eine lockerere Kopplung zwischen Domänen
- Erweiterbarkeit über die Zeit
Im Prozess eignen sich Events gut für Situationen wie:
- einen geschäftlichen Meilenstein bekannt machen
- mehrere Systeme über eine Zustandsänderung informieren
- künftige Konsumenten anbinden, ohne die Integration an der Quelle neu zu entwerfen
Sie fördern die Anpassungsfähigkeit, die wertvoll ist, wenn Workflows viele Teams und Systeme umspannen.
Wenn Sie in einer Prozessinitiative eine Integration bewerten, führen Sie ein kurzes Architekturreview entlang der drei Fragen durch.
Schritt 1: Den geschäftlichen Moment benennen
Benennen Sie die genaue Interaktion:
- Ist es ein Befehl?
- Ist es eine Statusänderung?
- Ist es ein Geschäftsereignis?
So bleibt die Diskussion in der Realität des Workflows verankert statt in technologischen Vorlieben.
Schritt 2: Das Abhängigkeitsmuster abbilden
Fragen Sie:
- Wer muss davon erfahren?
- Wie schnell muss das geschehen?
- Wie viele Systeme reagieren?
Daran zeigt sich, ob es Ihnen um Bestätigung oder um Weitergabe geht.
Schritt 3: Die Betriebsreife ehrlich prüfen
Fragen Sie nicht nur, ob es eine Event-Infrastruktur gibt. Fragen Sie, ob das Team sie gut betreiben kann.
Prüfen Sie praktische Fähigkeiten wie:
- Tracing über Domänengrenzen hinweg
- den Umgang mit Idempotenz
- Schema-Versionierung
- klare Zuständigkeit für den Support
- die Diagnose von Incidents
Oft wird an dieser Stelle die richtige Antwort offensichtlich.
Schritt 4: Bei Bedarf für beides entwerfen
Viele Workflow-Schritte bestehen aus einem Befehl, auf den eine Weitergabe folgt.
Zum Beispiel:
- ein Prozess sendet über eine API einen Befehl, um eine Aktion abzuschließen
- ist die Aktion erfolgreich, wird die daraus entstehende geschäftliche Änderung als Event veröffentlicht
- nachgelagerte Systeme reagieren unabhängig darauf
Dieses Muster verbindet die Kontrolle von APIs mit der Skalierbarkeit von Events, ohne ein einziges Modell zu zwingen, alles zu leisten.
Auch starke Teams können sich festfahren, wenn sie die Entscheidung zu sehr vereinfachen.
Fehler 1: APIs als „alt“ und Events als „modern“ betrachten
Diese Einordnung hilft nicht weiter. Welches Muster besser ist, hängt von den Anforderungen des Workflows ab, nicht von der Mode.
Fehler 2: Mit Events den schwierigen Gesprächen über Schnittstellenverträge ausweichen
Events schaffen Governance nicht ab, sie verlagern sie. Sind Schemas und Zuständigkeiten unklar, kehrt die Komplexität an anderer Stelle zurück.
Fehler 3: APIs für jede nachgelagerte Reaktion nutzen
Das kann doppelte Integrationen und eng gekoppeltes Prozessverhalten erzeugen, vor allem wenn viele Systeme dieselbe Information brauchen.
Fehler 4: Die Betriebsreife ignorieren
Die Umfragezahlen oben sagen es deutlich: 72 % der Unternehmen nutzten EDA, aber nur 13 % hatten die Reife erreicht. Die Lücke liegt in der Betriebsreife, nicht im Willen zur Einführung.
Diese Lücke sollte Designentscheidungen ebenso stark prägen wie konzeptionelle Architekturziele.
Es geht nicht darum, welches Muster gewinnt, sondern darum, wo jedes hingehört.
Diese Haltung ist für BPM-Verantwortliche besonders nützlich, denn Ihre Aufgabe ist nicht, ein Technologielager zu verteidigen. Sie besteht darin, domänenübergreifende Workflows effizient, konsistent, transparent und resilient zu machen.
Wenn Teams klare Kriterien nutzen, werden Architekturdiskussionen produktiver. Es geht dann nicht mehr um Meinungen, sondern um die Passung:
- Braucht der Konsument sofort eine bestätigte Antwort?
- Wie viele nachgelagerte Systeme reagieren auf diese Änderung?
- Kann Ihr Team eine Event-Infrastruktur bereits betreiben?
Diese drei Fragen lösen nicht jede Integrationsaufgabe, aber sie beenden überraschend viele Debatten, die sich im Kreis drehen.
Und was noch wichtiger ist: Sie helfen Ihnen, Workflows zu entwerfen, die in der Realität funktionieren, nicht nur auf dem Whiteboard.
Wenn Ihre Organisation Integration noch immer als Entscheidung zwischen API und Events versteht, stellt sie womöglich die falsche Frage. Domänenübergreifende Workflows brauchen meist eine Kombination beider Muster, bewusst eingesetzt.
Setzen Sie APIs ein, wenn der Prozess eine sofortige, verbindliche Antwort braucht. Setzen Sie Events ein, wenn sich eine geschäftliche Änderung über mehrere Konsumenten verbreiten muss. Und bevor Sie auf Entkopplung setzen, prüfen Sie ehrlich, ob Ihr Team den betrieblichen Anforderungen gewachsen ist, die damit einhergehen.
So wird aus einer Architekturdebatte eine Entscheidung.
Welche dieser drei Fragen lässt sich in Ihrer Organisation am schwersten ehrlich beantworten? Wenn Sie neu überlegen, wie Ihre domänenübergreifenden Workflows integriert werden sollen, hilft Ihnen KONDEVS, die richtige Grenze zwischen APIs, Events und Prozessorchestrierung zu bestimmen.
