Top-Down statt Bottom-Up
1. Warum Bottom-Up in die Abhängigkeit führt
Beim Bottom-Up-Vorgehen werden existierende Backend-Services einfach „hochgezogen“ und zu Prozessen kombiniert. Das Problem:
👉 Die Anwendung übernimmt automatisch Limitierungen, Datenstrukturen und Logiken aus bestehenden Systemen.
👉 Neue fachliche Anforderungen werden in den Rahmen der IT-Landschaft gepresst – statt andersherum.
👉 Die resultierende Anwendung wird schwierig wartbar und extrem abhängig.
Die Praxis belegt diese Problematik explizit und zeigt, dass viele Projekte scheitern, weil zu viele der bereitgestellten Backend-Services direkt aus der Endanwendung heraus aufgerufen werden .
Typische Folgen:
Services passen nicht zum Prozess
Datenstrukturen sind zu technisch
Schnittstellen werden unnötig komplex
Änderungen im Backend zwingen zu Änderungen in der neuen Anwendung
Keine echte lose Kopplung möglich
Das Ergebnis: Alte Silos in neuem Gewand.
2. Warum Top-Down der einzig sinnvolle Ansatz ist
Der Top-Down-Ansatz beginnt immer mit dem fachlichen Prozess – unabhängig von vorhandenen Systemen. Erst die fachliche Dekomposition entscheidet, welche Services, Daten und Schnittstellen benötigt werden.
In der Praxis hilft folgender zentraler Merksatz:
„Stellen Sie sich bei jeder Entscheidung vor, Sie wüssten nicht, gegen welche Systemlandschaft Ihre Lösung einmal laufen wird.“
Der Vorteil: Die neue Anwendung wird vollständig unabhängig von Systemlogiken, Datenformaten oder Technologieentscheidungen.
Top-Down bedeutet:
Prozesse definieren zuerst fachliche Anforderungen
Daraus werden Serviceverträge abgeleitet
Erst danach wird über technische Implementierungen der Serviceverträge gesprochen
Backend-Services werden nur dort genutzt, wo sie fachlich passen
Integration erfolgt über klare, abstrahierte Schnittstellen
So entsteht eine saubere, fachliche Außensicht, die nicht von bestehenden APIs verzerrt wird.
3. Der häufigste Denkfehler: Bestehende Services als „gesetzt“ zu betrachten
Viele Teams vertreten die Ansicht: „Wir müssen die vorhandenen Services direkt verwenden. Es gibt keine Alternative.“
Die prozessgesteuerte Methodologie zeigt aber deutlich, dass dies ein Trugschluss ist. Oft wird behauptet, man müsse vorhandene Datenstrukturen oder Serviceoperationen übernehmen – doch in Wahrheit fehlt lediglich die methodische Klarheit, einen eigenständigen fachlichen Servicevertrag zu definieren.
Die Warnung ist klar:
„Das größte Problem liegt darin, dass zu viele der von den Backends bereitgestellten Services direkt aus der Endanwendung heraus aufgerufen werden.“
Dadurch entsteht:
Technische statt fachliche Orientierung
Vermischung von Backend-Details und Prozesslogik
Hohe Kopplung
Schlechte Wartbarkeit
Kurz: Wer das Backend als Ausgangspunkt nimmt, verliert die Kontrolle über die Architektur.
4. Der Schlüssel: Fachliche Serviceverträge statt Backend-APIs
Eine prozessgesteuerte Anwendung definiert ihre eigenen fachlichen Schnittstellen, unabhängig von den Backend-Systemen. Diese fachlichen Serviceverträge entsprechen genau dem, was der Prozess benötigt – und eben nicht dem, was das Backend anbietet.
Gemäß der prozessgesteuerten Methodologie gilt:
Serviceverträge sind fachlich motiviert
Sie spiegeln den Prozess wider, nicht das Backend
Backend-Daten werden über Mappings in dedizierten Integrationsprozessen entkoppelt
Loser gekoppelte Architekturen werden dadurch erst möglich
Das ist der entscheidende Unterschied zwischen einer flexiblen, prozessgesteuerten Anwendung und einer starr zusammengesteckten „SOA-Lösung“.
5. Fazit: Top-Down ist nicht nur besser – es ist unverzichtbar
Top-Down liefert:
Fachliche Klarheit
Unabhängigkeit vom Backend
Lose Kopplung
Schnellere Anpassbarkeit
Nachhaltigere Architektur
Weniger technische Schulden
Bottom-Up dagegen 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 klar:
Top-Down ist nicht eine Option – es ist das Fundament.
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.