Wiederverwendung: Chancen und Herausforderungen

Benjamin Tenke, Senior Architect bei Cofinpro, thematisiert die Herausforderungen der Wiederverwendung in komplexen Bankarchitekturen. Die Annahme, dass Mehrfachnutzung vorhandener Funktionalitäten Aufwand spart, erweist sich oft als irreführend. — Benjamin Tenke, Senior Architect Cofinpro

Wiederverwendung gilt als etabliertes Prinzip moderner Softwarearchitektur. Wer vorhandene Funktionalität mehrfach nutzt, spart Aufwand. Doch in komplexen Bank-Systemlandschaften entpuppt sich diese Annahme schnell als Trugschluss. Auf Architekturebene ist nicht allein entscheidend, ob etwas mehrfach verwendet wird, sondern ob eine gemeinsame Lösung in unterschiedlichen Kontexten nachhaltig tragfähig und wirtschaftlich ist.

von Benjamin Tenke, Confinpro

In der langfristigen Betrachtung wird das Dilemma sichtbar: Rund 20 Prozent der Kosten entstehen bei der anfänglichen Umsetzung einer Software. Etwa 80 Prozent fallen danach an, beispielsweise durch Weiterentwicklung, Anpassungen, Betrieb, Tests und Abstimmung.“

Was einmal zentral entwickelt wurde, muss fortan von vielen Seiten verändert, abgestimmt und abgesichert werden. In Banken ist dieser Effekt besonders stark, denn hier laufen Anwendungen oft über Jahrzehnte. In dieser Zeit ändern sich jedoch kontinuierlich regulatorische Anforderungen, Produkte und Vertriebskanäle. Zentrale Lösungen geraten unter Druck, da sie immer mehr unterschiedliche Anforderungen gleichzeitig erfüllen müssen. Was als saubere, einheitliche Komponente gestartet ist, entwickelt sich schrittweise zu einem komplexen System aus Varianten, Ausnahmen und Sonderfällen. Der ursprüngliche Gewinn durch die Wiederverwendung kehrt somit in Form von technischer und organisatorischer Komplexität zurück.

Der wirkliche Zielkonflikt wird dabei häufig übersehen: Zentrale Wiederverwendung spart zwar kurzfristig Implementierungsaufwand, kostet aber langfristig Geschwindigkeit, Wartbarkeit und Autonomie. Architekturentscheidungen sind deshalb keine reinen Technikfragen, sondern auch wirtschaftliche Abwägungen über den gesamten Lebenszyklus hinweg.“

Die drei Ebenen der Wiederverwendung

Bei der Entscheidung für eine Architektur sollte zunächst Klarheit über die verschiedenen Ebenen der Wiederverwendung erzielt werden. Die Hierarchie der Wiederverwendung gliedert sich wie folgt:

Know-how ist die grundlegendste Form. Dazu zählen gemeinsame Domänenmodelle, dokumentierte Architekturentscheidungen, Referenzmuster und Prozessbilder. Diese Form schafft Orientierung, ohne operative Abhängigkeiten zu erzeugen.
Duplizierung mit Anpassung ist eine oft unterschätzte, aber pragmatische Option. Dabei werden bestehende Strukturen oder Logiken übernommen, jedoch bewusst unabhängig implementiert. Was zunächst wie ineffiziente Doppelarbeit wirkt, kann sich langfristig als robuster erweisen: weniger Abstimmungsaufwand, klarere Zuständigkeiten und eine bessere Anpassungsfähigkeit an unterschiedliche Anforderungen. Ein großer organisatorischer Vorteil: Die Autonomie der Teams bleibt gewahrt und ermöglicht unterschiedliche Entwicklungsgeschwindigkeiten.
Die Systemintegration über Schnittstellen ist die anspruchsvollste Form der Wiederverwendung. Sie ermöglicht Synergien, setzt jedoch voraus, dass fachliche, organisatorische und technische Rahmenbedingungen stabil und kompatibel sind.

Autor: Benjamin Tenke, Cofinpro

Benjamin Tenke, Senior Architect bei Cofinpro, präsentiert sich in formeller Kleidung. Sein neutraler Gesichtsausdruck und der direkte Blick unterstreichen Professionalität. Die Thematik der Wiederverwendung in IT-Architekturen könnte in seinem Kontext von Bedeutung sein.

Benjamin Tenke ist Senior Architect bei Cofinpro (Website). Dort ist er seit 2014 tätig und hat sich über mehrere Stationen vom Consultant bis zum Senior Architect entwickelt. Sein Schwerpunkt liegt unter anderem auf Artificial Intelligence, Enterprise Application Integration und Prozessautomatisierung. Er studierte Wirtschaftsinformatik an der Hochschule Karlsruhe und schloss anschließend einen Master of Science in Business Informatics an der Otto-Friedrich-Universität Bamberg ab.

Als strategische Grundhaltung empfiehlt sich ein klarer Default: Autonomie vor Integration. Das bedeutet, Systeme werden zunächst so gestaltet, dass sie für einen konkreten Anwendungsfall eigenständig funktionieren, ohne Abhängigkeiten zu anderen Teams oder Komponenten.

Integration erfolgt erst dann, wenn sich über die Zeit zeigt, dass mehrere Kontexte fachlich tatsächlich übereinstimmen und dauerhaft von einer gemeinsamen Lösung profitieren. Sie ist damit kein Ausgangspunkt, sondern eine Entscheidung, die bewusst begründet werden muss. Der Grundgedanke dahinter: Unabhängige Systeme lassen sich schneller verändern, einfacher betreiben und besser an neue Anforderungen anpassen. Genau das ist in dynamischen Umfeldern wie dem Banking ein entscheidender Vorteil.

Wo Entscheidungen zur Wiederverwendung typischerweise scheitern

In der Praxis scheitert dieser Ansatz jedoch häufig, weil Entscheidungen auf einer zu allgemeinen Ebene getroffen werden. Die Einteilung anhand von Aussagen wie „Wir haben doch schon eine Produktsuche“ oder „Diese Funktion existiert bereits“ ist zu grob.

Stattdessen sollte vor der Architekturentscheidung eine detaillierte Prüfung erfolgen.“

Denn oft wirken Systeme nur auf den ersten Blick ähnlich; Unterschiede und die damit verbundene Komplexität werden erst im Detail sichtbar.

Ein typisches Beispiel aus dem Bankensektor ist die Bereitstellung von Produktinformationen für verschiedene Kanäle. Flüchtig betrachtet wirken die Produktsuche für Endkunden und die für Berater identisch: gleiche Datenbasis, ähnliche Darstellung, vergleichbare Funktionalität. Bei genauem Hinsehen zeigen sich jedoch fundamentale Unterschiede: Die Endkundensuche muss keine Eignungsprüfung durchführen. Diese ist bei der Beratersuche erforderlich, denn MiFID II verpflichtet den Berater, nur Produkte zu empfehlen, die zum Risikoprofil des Kunden passen. Was im B2C-Kontext ein einfaches Suchergebnis ist, wird im B2B-Kontext zur regulatorisch relevanten Entscheidungsgrundlage mit anderen Datenfeldern, Validierungen und Auditanforderungen.

Vier Prüfsteine für die Entscheidung

Genau hier entsteht das Problem: Eine gemeinsame Lösung muss plötzlich mehrere Anforderungsszenarien gleichzeitig bedienen und verliert dadurch an Klarheit, Wartbarkeit und Veränderbarkeit. Damit die Entscheidung für oder gegen eine Wiederverwendung nicht intuitiv oder auf Basis von Einzelaspekten getroffen wird, bietet sich ein strukturierter Bewertungsrahmen mit klar definierten Kriterien an. Es wird fachlich, organisatorisch und technisch geprüft. Erst wenn alle diese Dimensionen positiv bewertet werden können, ist eine Integration langfristig tragfähig:

Fachliche Kongruenz und Problemraum: Löst die Funktion in beiden Kontexten tatsächlich dasselbe fachliche Problem? Entscheidend sind nicht die Oberfläche, sondern die Geschäftsregeln, der Nutzungskontext und der fachliche Schnitt. Unterschiede in Prozessen oder Dateninterpretationen sind ein starkes Signal gegen eine Integration.
Evolutionäre Kopplung und Änderungsgeschwindigkeit: Werden sich die Anwendungsfälle langfristig gleich entwickeln? Unterschiedliche Innovationszyklen oder Marktanforderungen können dazu führen, dass eine gemeinsame Lösung zur Bremse wird. Eine Integration koppelt die Entwicklungsgeschwindigkeit – und damit auch die Flexibilität.
Organisatorisches Modell und Verantwortung: Wer hat die Verantwortung für Betrieb und Weiterentwicklung? Ohne ein klares Ownership-Modell wird eine zentrale Komponente schnell zum Flaschenhals. Eine Integration ist nur dann sinnvoll, wenn ein dediziertes Team die Rolle eines stabilen Service-Anbieters übernimmt.
Technologie, Architektur und Qualität: Ist die bestehende Lösung technisch geeignet? Handelt es sich um einen sauber entkoppelten Service mit stabiler API oder müsste die Funktion erst aufwendig aus einem Monolithen herausgelöst werden? Wo liegen die Daten und welche Netzwerklast entsteht bei zentraler Nutzung? Werden mit der Integration möglicherweise bekannte NFR-Probleme, wie mangelnde Skalierbarkeit oder technische Schulden, importiert? Entscheidend ist auch der Blast Radius: Je mehr Systeme von einer zentralen Komponente abhängen, desto größer ist der Schaden bei einem Ausfall.

Wirklich sinnvoll ist eine Integration nur dann, wenn alle vier Prüfsteine positiv bewertet werden können. Andernfalls ist die Duplizierung die strategisch robustere Entscheidung.

Von der Entscheidung zur Architektur

Grundlage für diese Bewertung ist eine belastbare Wissenslandkarte.

Domänenmodelle, Prozessmodelle, Customer Journeys und Capability Maps helfen dabei, gemeinsame fachliche Kerne zu identifizieren und oberflächliche Ähnlichkeiten aufzudecken.“

Entscheidend ist die Reihenfolge der Betrachtung: Zunächst steht die Fachlichkeit im Mittelpunkt, dann die Nutzerinteraktion und erst danach die technische Umsetzung.

Ohne diese Transparenz werden Entscheidungen zur Wiederverwendung zwangsläufig auf Basis von Annahmen getroffen und bergen damit ein strategisches Risiko. Aus der Bewertung ergeben sich zwei mögliche Architekturpfade: die bewusste Schaffung einer autonomen, spezialisierten Lösung oder die gezielte Integration in die bestehende Systemlandschaft.

Fällt die Entscheidung aus technischen Erwägungen heraus für strategische Autonomie und gegen zentrale Integration, steht mit dem „Vertical Slice” ein bewährtes Architekturmuster bereit. Anstatt einen monolithischen Zentralservice für alle Nutzungskontexte aufzubauen, stellt das verantwortliche Fachteam pro Anwendungsfall einen eigenständigen, durchgängigen Schnitt bereit – von der API bis zur Datenschicht. Im Beispiel der Produktsuche bedeutet das: Für den B2C-Kanal entsteht eine schlanke Such-API für Endkunden. Für den Beraterkontext wird eine separate, datenreichere API mit zusätzlichen Validierungen, Berechtigungen und Audit-Anforderungen bereitgestellt. Beide Lösungen können intern auf denselben Stammdaten basieren, sind nach außen jedoch entkoppelt, unabhängig deploybar und organisatorisch klar verantwortet. So wird vermieden, dass ein zentraler Service für immer neue Sonderfälle „aufgebohrt” wird.

Fällt die Entscheidung hingegen zugunsten einer Integration aus, sollte diese so lose wie möglich gekoppelt umgesetzt werden. Leitprinzip ist dabei die maximale Unabhängigkeit der beteiligten Systeme. Auf Datenebene ist asynchrone Kommunikation über Domänen-Events – in der Praxis häufig über Apache Kafka – oft robuster als synchrone REST-Aufrufe.

Jedes System konsumiert Events nach eigenem Bedarf, ohne eine direkte Laufzeitabhängigkeit zum Produzenten zu haben.“

Synchrone REST-Integration bleibt die Ausnahme. Sie ist nur dann sinnvoll, wenn eine fachliche Echtzeit-Konsistenz erforderlich ist und die Eventual Consistency den Anwendungsfall nicht ausreichend abbildet. Noch kritischer ist die direkte Wiederverwendung von Geschäftslogik über Systemgrenzen hinweg, da sie eine besonders starke Kopplung erzeugt. Sie sollte nur in gut begründeten Ausnahmefällen erfolgen.

Auch auf der UI-Ebene gilt: Die Integration sollte möglichst leichtgewichtig bleiben. Oftmals genügen Links, klar abgegrenzte Frontend-Fragmente oder Web Components, um die Nutzerführung und die Systemgrenzen sauber miteinander zu verbinden. Das Ziel ist nicht maximale Zentralisierung, sondern minimale Kopplung bei sinnvoller Wiederverwendung.

Fazit

Die Wiederverwendung ist in Bankarchitekturen kein Selbstzweck. Sie ist nur dann sinnvoll, wenn sie fachlich kongruent, evolutionär tragfähig, organisatorisch klar verantwortet und technisch robust umsetzbar ist. Wo diese Bedingungen nicht erfüllt sind, ist bewusste Duplizierung keine Schwäche, sondern oft die wirtschaftlich bessere Entscheidung. Die zentrale Herausforderung besteht also nicht darin, möglichst viel gemeinsam zu entwickeln, sondern zu erkennen, wann gemeinsame Lösungen mehr schaden als nutzen. Benjamin Tenke, Cofinpro