Der Integrationsweg: Vom Befund zur funktionierenden Datenarchitektur

Von der Diagnose zur Umsetzung

In den ersten beiden Teilen dieser Serie haben wir die Datenlücken zwischen Banken und Finanzdienstleistern analysiert und die Integrationsmuster beschrieben, die diese Lücken schließen können. Diagnose und Architektur sind notwendig — aber sie sind nicht hinreichend.

Die entscheidende Frage für den Vorstand ist nicht "Was ist das Problem?" oder "Welche Muster gibt es?", sondern: Wie kommen wir von hier nach dort?

Dieser Beitrag beschreibt einen erprobten Weg.

Phase 1: Assessment — Verstehen, was ist

Jede Integrationsinitiative beginnt mit einer Bestandsaufnahme. Nicht mit Technologieauswahl, nicht mit Produktevaluation, sondern mit dem Verständnis der bestehenden Landschaft.

Was ein Assessment klärt:

• Systemkartierung: Welche Systeme existieren? Welche führen welche Daten? Wo gibt es Überschneidungen, wo Lücken?

• Datenflüsse: Welche Daten fließen heute zwischen welchen Systemen? Über welche Wege (Batch-Dateien, manuelle Übertragung, Schnittstellen)?

• Schmerzpunkte: Wo entstehen heute die größten Reibungsverluste? Welche Prozesse sind am stärksten von Datenlücken betroffen?

• Abhängigkeiten: Welche externen Partner sind angebunden? Welche Rechenzentren und Bankverarbeitungssysteme setzen den Rahmen?

Das Assessment produziert keine Powerpoint-Präsentation mit 200 Folien. Es produziert eine klare Karte: Hier stehen wir. Dort sind die kritischsten Lücken. Das sind die Abhängigkeiten, die jede Lösung berücksichtigen muss.

Phase 2: Architekturentwurf — Die Integrationsschicht planen

Auf Basis des Assessments entsteht der Architekturentwurf. Hier werden die Entscheidungen getroffen, die den Rahmen für die Umsetzung setzen:

Welche Muster für welche Datenflüsse? Stammdaten-Synchronisation im Batch? Prozessdaten über Echtzeit-APIs? Welche Datenflüsse sind kritisch genug für ereignisbasierte Integration?

Wo liegt die Integrationsschicht? Wird sie als eigenes System betrieben? Als Schicht innerhalb der bestehenden Infrastruktur? In Zusammenarbeit mit dem Rechenzentrum?

Was ist das kanonische Datenmodell? Welche Felder, Formate und Schlüssel bilden die gemeinsame Sprache zwischen den Systemen?

Der Architekturentwurf ist nicht endgültig. Er ist ein belastbarer Ausgangspunkt, der sich mit wachsendem Verständnis weiterentwickelt. Aber er verhindert, dass die Umsetzung in beliebige Richtungen driftet.

Phase 3: Pilot — Klein anfangen, Erfahrung sammeln

Ein häufiger Fehler: die gesamte Integrationslandschaft auf einmal umbauen wollen. Das scheitert fast immer — an Komplexität, an Abhängigkeiten, an organisatorischem Widerstand.

Der erprobte Weg ist ein Pilot:

Einen konkreten Datenfluss auswählen, der repräsentativ ist und messbaren Nutzen bringt. Zum Beispiel die Stammdaten-Synchronisation zwischen Maklersoftware und Kernbanksystem für eine Partnergruppe.

Die Integrationsschicht für diesen einen Fluss aufbauen: Normalisierung, Orchestrierung, Fehlerbehandlung. Nicht mehr, nicht weniger.

Erfahrungen sammeln: Was funktioniert wie geplant? Wo weicht die Realität vom Entwurf ab? Welche Annahmen müssen korrigiert werden?

Der Pilot liefert zwei Ergebnisse: eine funktionierende Integration für einen konkreten Anwendungsfall und belastbare Erfahrungen für den Ausbau.

Phase 4: Schrittweiser Ausbau

Nach dem erfolgreichen Pilot wird die Integrationsschicht schrittweise erweitert:

• Weitere Datenflüsse anbinden: Zuerst die mit dem höchsten Nutzen und der geringsten Komplexität, dann sukzessive die anspruchsvolleren

• Weitere Partner einbeziehen: Zusätzliche Maklergruppen, Verbundpartner, weitere interne Fachabteilungen

• Zusätzliche Muster aktivieren: Vom reinen Batch-Betrieb schrittweise Echtzeit-Fähigkeiten ergänzen, wo sie tatsächlich gebraucht werden

Jeder Ausbauschritt baut auf den Erfahrungen des vorherigen auf. Das reduziert Risiko und erlaubt es, den Aufwand zu steuern.

Realistische Erwartungen

Drei Dinge, die ein Vorstand wissen sollte, bevor er ein Integrationsprojekt freigibt:

Es ist kein IT-Projekt

Integration zwischen Bank und Finanzdienstleister ist ein Organisationsprojekt mit IT-Komponente. Die technischen Herausforderungen sind lösbar. Die organisatorischen — unterschiedliche Prioritäten, Release-Zyklen, Zuständigkeiten zwischen Bank, Partner und Rechenzentrum — sind die eigentliche Aufgabe.

Perfektion ist nicht das Ziel

Nicht jede Datenlücke muss geschlossen werden. Nicht jeder Datenfluss muss in Echtzeit laufen. Das Ziel ist eine Architektur, die die kritischsten Lücken schließt und erweiterbar ist — nicht eine, die jeden theoretischen Anwendungsfall abdeckt.

Es braucht jemanden, der beide Seiten kennt

Integrationsprojekte scheitern selten an der Technologie. Sie scheitern daran, dass die Beteiligten die jeweils andere Seite nicht ausreichend verstehen. Der Banker versteht nicht, wie Maklersoftware funktioniert. Der Makler-IT-Dienstleister kennt die Zwänge des Kernbanksystems nicht. Erfolgreiche Integration erfordert jemanden, der beide Welten kennt und übersetzen kann.

Das Gesamtbild

Diese dreiteilige Serie hat einen Bogen gespannt:

1. Die Lücken verstehen: Interne Silos und externe Datenbrüche sind der Normalzustand — nicht der Ausnahmefall

2. Die Muster kennen: Batch, API und ereignisbasierte Integration lassen sich gezielt kombinieren

3. Den Weg gehen: Assessment, Architektur, Pilot, Ausbau — in dieser Reihenfolge, mit realistischen Erwartungen

Der erste Schritt ist immer derselbe: die eigene Situation ehrlich bewerten. Nicht die Situation, die in einer Präsentation steht, sondern die, die im Tagesgeschäft erlebt wird.

Nächster Schritt

Dream-Bit arbeitet mit führenden Finanz-, Versicherungs- und Immobilienmaklern zusammen und bringt tiefe Kenntnis beider Seiten der Integrationsgrenze mit. Wir wissen: Jede Systemlandschaft hat ihre eigene Geschichte, ihre eigenen Zwänge und ihre eigenen Prioritäten. Deshalb beginnen wir nicht mit einer Lösung, sondern mit einem Gespräch.

In einem unverbindlichen Erstgespräch hören wir zu, stellen die richtigen Fragen und geben eine ehrliche Einschätzung, ob und wie wir helfen können. Kein Pitch, kein Verkaufsgespräch — sondern ein fachlicher Austausch auf Augenhöhe.

Erstgespräch vereinbaren ->