Lösungsarchitekt – Enterprise Data Warehouse

Zeitraum:
05/16 - 07/18
Branche:
Banken
Projektziel
Entwurf und Prototyping Lösungsarchitektur für BCBS239 Anforderungen
Projektaufgaben
Lösungsarchitekt, Datenarchitekt, IT Architekt

Frisch zurück aus einem Retreat in Brasilien. Das letzte Projekt zuvor abgeschlossen, fahre ich in eine neue Stadt mit dem Auftrag, einen zweitägigen Workshop zur Umsetzung der BCBS239 durchzuführen.

Die BCBS239 ist eine Vorschrift des “Basel Committee on Banking Supervision” und erwartet von den Banken, ihr Risikoreporting zu konsolidieren und auf verlässliche Beine zu stellen. Viele Prozesse basieren noch auch Excel- und Access-gestützte Modelle. Darüber hinaus erwartet die Vorschrift, sich intensiver mit Zuständigkeiten, Verantwortung (Governance) und Datenqualität zu beschäftigen.

Im Rahmen des Workshop gefallen meine Ansätze und ich erhalte einen Auftrag, als Lösungsarchitekt ein Szenario zu entwerfen, welches auf die Bedarfe dieser Spezialbank und ihrer Kultur passt.

Wir besprechen ein agiles Vorgehen, etwas Neues für das Haus. Wir wollen schnell nutzbare Werte schaffen. Lieber mal einen kleinen Fehlschritt zurücknehmen als in langen “Wasserfallzyklen” auf Nutzen warten müssen.

Ich gehe die verschiedenen Ansätze durch, mit denen ich schon Erfahrung gesammelt habe und recherchiere nach neuen. Dabei stoße ich auf “Data Vault 2.0”. Von Data Vault hatte ich schon gehört, aber noch nicht damit gearbeitet. Also rufe ich alte Kontakte an, lasse mir Ansprechpartner empfehlen und stelle fest, dass das “unsere” Lösung wird. Mehr über Data Vault 2.0 findet sich hier.

Beim Kunden wird bisher kaum programmiert, eher mit verlängerter Werkbank gearbeitet. Also wird eine Teil der IT, den ein großer Bankdienstleister für das Meldewesen gebaut hat, in die Architektur integriert und der Dienstleister beauftragt, die vorhandenen Berichtsdaten auf die Data Vault Struktur anzupassen. Das spart Kosten, denn die ganze, in der Lösung steckende Fachlichkeit bleibt erhalten, wir bleiben synchron zum Meldewesen und kompatibel zu weiteren Datenabnehmern, die noch nicht angefasst werden sollten. Integration eben.

Das Ganze passiert, während ich mit dem Talend Open Studio (Informationen dazu hier) einen Prototypen baue, der einen guten Teil der Daten schon mal in eine Datenbank holt und dort einfacher nutzbar und auswertbar macht. Damit wird das erste Stück Excel-Verarbeitung abgelöst und neue Möglichkeiten geschaffen, da nun viel mehr Daten an einer Stelle zu finden sind.

Ein neuer Dienstleister wird gefunden und kommt ins Boot. Erfahrene Talend-Enthusiasten bauen die Datenstrecken, die von der o.g. Meldewesenstrecke nicht berücksichtigt werden. Es werden Templates aufgebaut, also Vorlagen, die dafür sorgen, dass wir neue Quellen schnell integrieren können und schnell neue Auswertungen erstellt werden.

“Nebenbei” schaffen wir Zusatznutzen und kreieren Visionen: Die ursprünglich für eine konkrete Vorschrift gedachte Lösung darf nun auch die Integration eines Impairmentrechners für IFRS vornehmen. Daten, die wir schon haben, werden dort auch gebraucht. Weitere Daten, die dort herangezogen werden, brauchen wir später. Synergie und Kosteneffizienz “im Vorbeigehen” (na ja, etwas Aufwand war schon angefallen 😉 ). Und wenn in einer Bank schon Risikocontrollierung, Finance und Meldewesen ihre Daten zusammenführt haben, ist der Weg zu vielen anderen Bereichen kurz und einfach.

Aus der Umsetzung einer “lästigen” Anforderung wird plötzliche eine Enterprise Data Warehouse:

“Können wir nicht auch die Neugeschäftspipeline einbinden?”
“Kann man da vielleicht auch Internetrecherchen zu unseren Kundenengagements anbinden, so etwas wie Big Data?”
“Kann man damit einen 360 Grad Blick auf unser Haus gewinnen?”

Ja, dass alles ist möglich mit dem gewählten Ansatz. Und das nicht, weil es von vornherein vorgesehen war, sondern weil die Architektur offen und integrationsorientiert entworfen ist.

Dieser Ansatz findet in einer Bank statt, ist jedoch völlig branchenunabhängig.