Beim Bottom-Up-Vorgehen werden bestehende Backend-Services einfach zusammengeführt und zu Prozessen verbunden. Das Kernproblem dabei:
Die Praxis zeigt deutlich, dass zahlreiche Projekte genau daran scheitern, weil zu viele Backend-Services direkt aus der Endanwendung heraus aufgerufen werden.
Typische Konsequenzen:
Das Resultat: Alte Silos in neuer Verkleidung.
Der Top-Down-Ansatz startet immer beim fachlichen Prozess – ungeachtet der vorhandenen Systemlandschaft. Erst die fachliche Zerlegung bestimmt, welche Services, Daten und Schnittstellen tatsächlich gebraucht werden.
Ein zentraler Leitsatz aus der Praxis lautet:
„Stell dir bei jeder Entscheidung vor, du wüsstest nicht, gegen welche Systemlandschaft deine Lösung einmal laufen wird.”
Der Vorteil ist klar: Die neue Anwendung bleibt vollständig unabhängig von Systemlogiken, Datenformaten und technischen Vorentscheidungen.
Top-Down bedeutet konkret:
So entsteht eine saubere fachliche Aussensicht, die nicht durch bestehende APIs verzerrt wird.
Viele Teams sind überzeugt: „Wir müssen die vorhandenen Services direkt nutzen. Eine Alternative gibt es nicht.”
Die prozessgesteuerte Methodologie widerlegt diese Annahme klar. Häufig wird behauptet, man müsse bestehende Datenstrukturen oder Serviceoperationen übernehmen – doch in Wirklichkeit fehlt lediglich die methodische Grundlage, einen eigenständigen fachlichen Servicevertrag zu definieren.
Die Warnung ist eindeutig:
„Das grösste Problem liegt darin, dass zu viele der von den Backends bereitgestellten Services direkt aus der Endanwendung heraus aufgerufen werden.”
Die Folgen davon sind:
Kurz gesagt: Wer das Backend als Ausgangspunkt wählt, verliert die Kontrolle über die Architektur.
Eine prozessgesteuerte Anwendung definiert ihre eigenen fachlichen Schnittstellen – unabhängig von den dahinterliegenden Backend-Systemen. Diese Serviceverträge bilden genau das ab, was der Prozess benötigt – nicht das, was das Backend zufällig anbietet.
Gemäss der prozessgesteuerten Methodologie gilt:
Das ist der wesentliche Unterschied zwischen einer flexiblen, prozessgesteuerten Anwendung und einer starren, zusammengestückten SOA-Lösung.
Top-Down liefert:
Bottom-Up hingegen führt fast immer zu einer Architektur, die sich an bestehenden Systemen orientiert – statt an den realen Geschäftsanforderungen.
Für moderne prozessgesteuerte Anwendungen ist daher unmissverständlich: Top-Down ist keine Option unter vielen – es ist das Fundament.
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.
