Artefakte richtig identifizieren
Anwendungsartefakte richtig identifizieren – Prozesse, UI, Daten, Services & Integrationen
Die Entwicklung einer prozessgesteuerten Anwendung beginnt immer mit der gleichen Frage: Welche Artefakte gehören wirklich zur prozessgesteuerten Anwendung – und welche nicht?
Die prozessgesteuerte Methodologie ist diesbezüglich sehr eindeutig: Eine prozessgesteuerte Anwendung umfasst eine definierte Menge an fachlichen und technischen Artefakten, die konsequent Top-Down aus dem Prozess abgeleitet werden. Erst wenn diese Artefakte sauber identifiziert und beschrieben sind, entsteht eine stabile, erweiterbare und unabhängige Architektur.
Die zentralen Artefaktkategorien lauten:
Prozesse – Benutzeroberflächen – Daten – Services – Integrationen.
1. Prozesse: Der fachliche Kern der Anwendung
Alles beginnt mit den Prozessen. Die prozessgesteuerte Methodologie legt sich diesbezüglich fest: Die fachlichen Anforderungen bestimmen Prozesse, Prozessabläufe und die daraus entstehenden Anwendungsartefakte direkt.
Wichtig ist:
Der Prozess modelliert nur fachliche Ablauflogik, keine technischen Details.
Er definiert Akteure, Abläufe, Datenflüsse und Ereignisse.
Jede Aktivität im Prozess führt zu weiteren Artefakten (UI, Service, Objekt, Integration).
Prozesse sind das führende Artefakt, aus dem alle anderen abgeleitet werden.
2. Benutzeroberflächen: Aufgabenorientiert, prozessgesteuert
Benutzeroberflächen werden im Top-Down-Modell nicht aus bestehenden Systemen übernommen, sondern ausschließlich aus der Prozesslogik abgeleitet.
Charakteristika:
UI-Artefakte sind aufgabenorientiert.
Sie zeigen genau die Daten an, die der Prozessschritt benötigt.
Sie müssen in der Lage sein, Prozesse zu starten, Daten zu liefern und Zustände zu melden (z. B. Start eines Prozesses aus einem UI heraus).
Ein UI kennt keine Backend-Logik, sondern nur die Datenstrukturen und Serviceaufrufe der prozessgesteuerten Anwendung.
3. Daten: Das kanonische Datenmodell als Fundament
Datenartefakte sind eines der kritischsten Elemente der Prozessanwendung– denn sie bestimmen, wie die Anwendung über Systeme hinweg stabil bleibt.
Die prozessgesteuerte Methodologie betont ausdrücklich: Backend-Datenstrukturen dürfen nicht wiederverwendet werden, da sie Abhängigkeiten erzeugen.
Stattdessen gibt es:
Das kanonische Datenmodell der prozessgesteuerten Anwendung:
Es enthält nur die Daten, die der Prozess wirklich benötigt.
Es definiert einheitliche Datentypen, unabhängig von Backend-Formaten.
Transformationen zwischen Systemen entfallen.
Dieses Modell bildet die Grundlage für:
UI-Felder
Prozessvariablen
Service-Verträge
Integrationen und Mappings
Geschäftsobjekte
Damit wird die Prozessanwendung systemunabhängig und änderungsrobust.
4. Services: Fachliche Funktionalität sauber gekapselt
Services sind keine technischen APIs – sondern fachliche Serviceverträge der prozessgesteuerten Anwendung.
Struktur:
Eine prozessgesteuerte Anwendung besitzt genau einen Servicevertrag.
Ein Servicevertrag besteht aus einem oder mehreren Services.
Jeder Service umfasst mindestens eine Serviceoperation.
Es gibt zwei Arten:
1. Prozessanwendung-eigene Services
Fachliche Logik wird kapselt.
Prozess- und UI-Schicht kommunizieren direkt mit ihnen.
Funktional sind sie ausschließlich an den Anforderungen der Prozessanwendung ausgerichtet.
2. Externe Services
Wiederverwendung existierender Fachlogik.
Über den Servicevertrag entkoppelt.
Konkrete Implementierung erst in der Integrationsschicht.
Die Services bilden die fachliche Außen- und Innenkommunikation der Prozessanwendung.
5. Integrationen: Sauber getrennte technische Umsetzung
Integrationen gehören nicht in den Prozess – und nicht in die UIs. Sie werden in der Servicevertrag-Implementierungsschicht umgesetzt:
Konzept:
Sie verbinden die fachlichen Serviceverträge mit den konkreten Backend-Systemen.
Sie enthalten Mappings, Konvertierungen und Transformationen.
Sie kapseln Systemabhängigkeiten vollständig.
Sie ermöglichen die Integration unterschiedlicher Systemlandschaften – inklusive Cloud, On-Premise oder Hybrid.
Integrationsartefakte sorgen dafür, dass:
die prozessgesteuerte Anwendung selbst stabil bleibt, obwohl sich Backends ändern
unterschiedliche Datenformate harmonisiert werden
Systeme austauschbar sind, ohne die Prozessanwendung anzupassen
Damit wird Integration zum geschützten technischen Raum, getrennt vom fachlichen Teil der Anwendung.
Fazit: Anwendungsartefakte sauber identifizieren – Architektur sauber halten
Wer seine Anwendungsartefakte konsequent Top-Down identifiziert, gewinnt:
Klarheit in der Architektur
Unabhängigkeit von Backend-Systemen
Flexibilität bei Änderungen
Nachvollziehbarkeit für Entwickler und Fachbereich
Wiederverwendbarkeit von Daten und Services
Saubere Trennung zwischen Fachlichkeit & Technik
Die richtige Identifikation der Artefakte ist der Schlüssel zu nachhaltigen, robusten und skalierbaren prozessgesteuerten Anwendungen.
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.