© Shutterstock / Dotted Yeti
Wie man verteilte Geschäftsprozesse modelliert

Das perfekte Zusammenspiel


Wenn sich Geschäftsprozesse verändern, muss die Software mithalten können. Doch welcher Architekturstil ist der richtige? Mit Orchestrierung und Choreografie stehen zwei spannende Ansätze für verteilte Systeme zur Wahl, die beide ihre Vor- und Nachteile besitzen.

Bei der Aufnahme und Analyse von fachlichen Anforderungen des Kunden sollte ein Schwerpunkt auf der Betrachtung seiner Geschäftsprozesse liegen. Viele sich wiederholende Tätigkeiten, das sogenannte Tagesgeschäft eines Kunden, basieren auf solchen Prozessen. Das Verständnis der Geschäftsprozesse des Kunden und damit verbunden ihre fachliche sowie technische Umsetzung sind ein wichtiger Bestandteil bei der Analyse und Planung von Softwaresystemen. Gerade in Bezug auf eine verteilte Architektur gibt es einige interessante Chancen und Risiken, die beachtet werden müssen. Der nachfolgende Artikel beschreibt zwei gängige Architekturansätze.

Entwurf der Softwarearchitektur

Sind die allgemeinen Anforderungen für ein Projekt dokumentiert und erste fachliche Geschäftsprozesse modelliert, wird im nächsten Schritt im Architekturmeeting über die grundlegende technische Softwarearchitektur des zu erstellenden Systems diskutiert. Der Kunde wünscht natürlich einen Einsatz der Anwendung über verschiedene Standorte hinweg. Des Weiteren soll die Anwendung zu Spitzenzeiten nicht unter der Last der Anwender kollabieren. Aus diesen Gründen wird heutzutage meist eine verteilte Softwarearchitektur gewählt. Dabei können entweder nur einzelne Komponenten auf Systeme verteilt werden oder aber ganze fachliche Domänen werden in Microservices zerlegt und verteilt betrieben. Als Infrastruktur wird das eigene Rechenzentrum genutzt, Teile aber auch in die Cloud ausgelagert. Basierend auf den oben getroffenen Entscheidungen und Annahmen werden nun fachliche und technische Domänen gebildet, die Daten samt Strukturen geplant, modelliert und auf die Domänen verteilt. Dabei werden gängige Methoden eingesetzt, die die Planung unterstützen und die Entscheidungsfindung vereinfachen, beispielsweise Domain-driven Design (DDD).

Leider lassen es Kunden und Projekte nicht immer zu, perfekt nach dem Lehrbuch zu arbeiten, sodass hier mitunter interessante Konstrukte entstehen. Dazu zählen beispielsweise ausgiebige, fast philosophische Diskussionen über Domänenschnitte auf Architektenebene. Manchmal wird aber auch nach Anzahl der Teams oder nach Interesse beziehungsweise Gefühl des Kunden geplant. Des Weiteren werden in agilen Projekten zu Projektbeginn in den seltensten Fällen sämtliche Anforderungen erhoben, geschweige denn detailliert analysiert. Das bedeutet, dass das Projekt bereits startet und die Softwareentwicklung Fahrt aufnimmt, während die Businessanalysten parallel weitere Anforderungen erheben und dokumentieren. So kann es passieren, dass die fachlichen Domänen bereits definiert sind und sich in der Umsetzung befinden, während ein neuer Geschäftsprozess vorgestellt wird, der sich beispielsweise über mehrere Domänen erstrecken würde. Oder aber es werden mehrere Geschäftsprozesse erfasst, die die verschiedenen Domänen gleichzeitig nutzen.

Je komplexer die Anforderungen sind, desto komplizierter wird es. Folgende Fragen müssen zuerst geklärt werden, bevor man ein Projekt weiter vorantreibt:

  • War der Domänenschnitt zu Beginn des Projekts richtig oder muss er überdacht werden?

  • Was passiert mit den Datenstrukturen, die in den verschiedenen Domänen genutzt werden? Müssen sie neu strukturiert und auf die Domänen verteilt werden?

  • Müssen die Geschäftsprozesse redundant auf Domänen verteilt werden oder können sie in Teilprozesse zerlegt werden?

Damit neue Geschäftsprozesse nicht regelmäßig das Projekt-Set-up in Frage stellen, muss bereits in der Architekturentscheidung während der Projektplanung erörtert werden, wie mit Geschäftsprozessen umgegangen werden soll. Hier haben sich in den letzten Jahren zwei Ansätze herauskristallisiert, die in den gängigen Foren und Auditorien teils kontrovers diskutiert werden. Die Ansätze werden als „Orchestrierung von Geschäftsprozessen“ und „Choreografie von Geschäftsprozessen“ bezeichnet.

Anhand der nachfolgenden Erläuterungen werden beide Ansätze detailliert erklärt, die Vor- und Nachteile aufgezählt und anonymisierte Fälle aus verschiedenen realen Projekten der letzten Jahre beschrieben. Ziel ist es, einen Überblick über die Chancen und Risiken bei der Modellierung verteilter Geschäftsprozesse aufzuzeigen.

Orchestrierung von Geschäftsprozessen

Beim Architekturansatz „Orchestrierung von Geschäftsprozessen“ wird ein führender Service implementiert, der den gesamten Geschäftsprozess kennt. Dieser wird in der eigenen Domäne modelliert und gesteuert. Der führende Service wird auch als orchestrierender Service beziehungsweise Dirigent bezeichnet. Die Begriffe sind an ein Musikkonzert angelehnt, in dem die Musiker von einem Dirigenten geführt werden. Auch hier richtet sich das Orchester ausschließlich nach den Anweisungen des Dirigenten. Teilprozesse werden in weiteren losgelösten Services abgebildet. Diese Services kennen dabei nur ihre eigene Domäne und den orchestrierenden Service, nicht die anderen Services, die ebenfalls am Gesamtprozess beteiligt sind. Die fachliche sowie zeitliche Steuerung des Geschäftsprozesses und damit der Teilprozesse in den Services wird ausschließlich durch den Dirigenten vorgegeben. Dieser verteilt die Daten an die Services und schreibt ihnen vor, was zu tun ist.

Die Modellierung und Realisierung des orchestrierenden Service wird in der Architekturplanung des Projekts definiert. Der Geschäftsprozess kann dabei entweder sel...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang