Die drei Säulen prozessgesteuerter Anwendungen
1. Methodologie – Die prozessgesteuerte Denkweise
Im Zentrum prozessgesteuerter Anwendungen steht nicht die Technologie, sondern die fachlichen Prozesse. Deshalb beginnt die Methodologie auch Top-Down: Ausgehend von den Zielprozessen werden Schritt für Schritt die Bestandteile der Anwendung abgeleitet, unabhängig von der existierenden Systemlandschaft.
Die prozessgesteuerte Denkweise stellt klar:
Die fachlichen Zielprozesse von prozessgesteuerten Anwendungen werden nicht von vorhandenen APIs bestimmt, sondern von der Frage: Welche Daten und welche Funktionalitäten benötigen die Zielprozesse wirklich?
Die Methodologie umfasst drei Kernprinzipien:
Top-Down-Dekomposition
Die Fachprozesse werden fachlich zerlegt, bis klar ist, welche Services, Objekte und UI-Elemente benötigt werden.
Fachliche Trennung von Prozessen
Die Methodik unterscheidet bewusst zwischen fachlichen und technischen Prozessen, die getrennt modelliert und umgesetzt werden sollen.
Unabhängigkeit von Backend-Systemen
Prozessgesteuerte Anwendungen definieren ihre Schnittstellen (Serviceverträge) selbst – sie übernehmen nicht die Strukturen existierender Systeme.
Damit schafft die Methodologie die Grundlage für echte Flexibilität:
Fachlichkeit zuerst – Implementierung später.
2. Architektur – Das Schichtenmodell als Grundlage
Die Architektur prozessgesteuerter Anwendungen folgt einem klaren, erprobten Schichtenmodell, das wie folgt zusammengefasst werden kann:
1. Prozessschicht
Sie bildet die fachlichen Abläufe ab – agile, dynamische, kollaborative Prozesse, die über mehrere Systeme laufen.
2. Benutzeroberflächenschicht
Aufgabenorientierte UIs unterstützen die jeweiligen Rollen in den Prozessen. Sie sind speziell für die Anwendung gebaut – keine Wiederverwendung von Backend-Masken.
3. Geschäftsobjekt- & Serviceschicht
Hier liegen die technischen Implementierungen für:
Neue fachliche Geschäftslogik in Form von (Micro-)Services
Persistenz neuer, für die prozessgesteuerte Anwendung essenzieller Geschäftsobjekte. Für diese Objekte ist die prozessgesteuerte Anwendung das führende System
4. Servicevertragsschicht (SC - Service Contract)
Schnittstellenbeschreibungen aus Sicht der prozessgesteuerten Anwendung für externe Bedürfnisse, sowohl hinsichtlich der Aufrufe nach Außen als auch für Aufrufe von Außen
5. Servicevertrag-Implementierungsschicht (SCIL - Service Contract Implementation Layer)
Umsetzung der in der Servicevertragsschicht geforderten Dienste in Form von Integrationen in die bereits existierende IT-Landschaft und Service-Welt
Dieses Schichtenmodell ermöglicht:
klare Verantwortlichkeiten
lose Kopplung
Austauschbarkeit von Implementierungen
strukturiertes Vorgehen beim Design
Wiederverwendung von Funktionalitäten
Besonders hervorzuheben ist die Rolle der Serviceverträge. Für sie gilt:
Ein Vertrag je Prozessanwendung
Fachlich motivierte Schnittstellen
Hinsichtlich der Begrifflichkeiten und Kardinalitäten gilt:
Eine prozessgesteuerte Anwendung besitzt genau einen Servicevertrag (1:1)
Ein Servicevertrag besteht aus mindestens einem Service (1:n)
Ein Service besteht aus mindestens einer Serviceoperation (1:n)
Für jeden Servicevertrag kann es mehrere Implementierungen geben (1:n), abhängig von den Ziel-IT-Landschaften, auf denen die prozessgesteuerte Anwendung agieren soll
Unabhängigkeit von konkreten Backend-APIs und deren Datenstrukturen
Die Architektur schafft damit die Basis für Entkopplung, Kontrolle und Wiederverwendbarkeit.
3. BPMN – Die gemeinsame Sprache
Die dritte Säule ist die Modellierungssprache BPMN, die in der Methodologie als das zentrale Werkzeug anzusehen ist – sowohl für fachliche als auch für technische Prozesse.
Warum ist BPMN so essenziell?
1. Einheitliches Verständnis
Fachbereiche und IT sprechen dieselbe Sprache: BPMN-Modelle sind für Fachlichkeit und Entwickler zugänglich.
2. Klare Trennung der Prozessarten
BPMN unterstützt sowohl:
fachliche Prozesse (Endanwender-Ablauflogik)
technische Prozesse (Integrations- und Serviceaufrufe)
und macht diese Trennung explizit.
3. Ausführbarkeit
BPMN ist nicht nur Modellierung – sie ist auch Laufzeitlogik. Damit können:
Prozessschritte automatisiert,
Nachrichten gesteuert,
Services orchestriert
und Abläufe flexibel angepasst werden.
4. Integration
Gerade aufgrund der heterogenen Systemlandschaften (SAP, Non-SAP, Legacy, Cloud) empfiehlt sich BPMN als Orchestrierungsschicht, wobei jedoch aus den ausführbaren BPMN-Modellen die Backendsysteme nie direkt aufgerufen werden. Hierfür sieht die Architektur dedizierte Integrationslösungen vor.
Damit wird BPMN zum verbindenden Element zwischen Methodologie und Architektur – ein Werkzeug, das Prozesse nachvollziehbar, automatisierbar und veränderbar macht.
Fazit – Erst die drei Säulen gemeinsam schaffen echte Flexibilität
Prozessgesteuerte Anwendungen entfalten ihr Potenzial nur, wenn:
Methodologie sicherstellt, dass fachliche Anforderungen im Zentrum stehen
Architektur eine stabile, lose gekoppelte Struktur liefert
BPMN Prozesse klar, ausführbar und anschlussfähig abbildet
Diese drei Säulen machen es möglich, komplexe End-to-End-Prozesse abzubilden, ohne sich in der IT-Landschaft zu verlieren. Sie sind der Schlüssel für flexible, nachhaltige und langfristig kosteneffiziente digitale Lösungen.
Quelle / Ursprung
Dieser Blogbeitrag basiert auf Inhalten aus dem Buch „Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN: Wie flexible Anwendungsarchitekturen wirklich erreicht werden können“ von Prof. Dr. Volker Stiehl.