Hintergrund in Datenmodellierung
Im Jahr 2010 las ich im Internet über Dan Linstedt und seine Arbeit, nachdem ich bereits durch Projektarbeit mit Data Vault 1.0 vertraut war. Als ich mehr über seine Arbeit erfuhr, war ich schnell von dieser Art der Modellierung begeistert. Zu dieser Zeit arbeitete ich als Entwickler, um ein Data Vault-Projekt zu unterstützen, das in Oracle implementiert wurde. Im Jahr 2018 fand ich mich in Deutschland wieder und erfuhr von einem Bootcamp, in dem ich Data Vault 2.0 im Detail kennenlernen sollte. Außerdem hatte ich die Möglichkeit, eine Prüfung abzulegen, um eine Zertifizierung zu erhalten. Nach dem Bootcamp nahm ich mir etwas Zeit, um mich auf die Prüfung vorzubereiten, und schaffte es, als Data Vault 2.0 Practitioner zertifiziert zu werden. Im Laufe der nächsten Jahre habe ich mein Fachwissen erweitert, indem ich an Data Vault-Projekten mitgearbeitet, bei POCs beraten und mehrfach als Datenentwickler gearbeitet habe. Außerdem sammelte ich Erfahrungen in den Bereichen Data Engineering, Python Data Engineering und Datenmigrationsprojekte.
Zwischen Februar 2022 und September 2024 hatte ich die Gelegenheit, an einem Datenmodellierungsprojekt zu arbeiten, das Teil einer globalen Initiative für eine große Versicherungsorganisation in deren Konzernzentrale in Deutschland war. Das Ziel war ehrgeizig: Rationalisierung des Berichtswesens für die Portfoliosteuerung in mehr als 10 operativen Einheiten (OEs). Bei diesen Einheiten handelte es sich um Versicherungsunternehmen innerhalb des Konzerns, die jeweils in einem anderen Land ansässig waren und eigene Geschäftspraktiken und Berichts-KPIs hatten. Die Herausforderung: Ermöglichung des Konzernberichtswesens im Group Data Office für die Portfoliosteuerung.
Die Herausforderungen des Kunden verstehen
Die erste Hürde war die schiere Vielfalt der Geschäftspraktiken in den einzelnen OEs. Jede Region hatte ihre eigene Art zu arbeiten und den Erfolg zu messen, was es schwierig machte, die Daten in einem einzigen, zusammenhängenden Modell zu vereinen. Hinzu kam die Notwendigkeit, die Data Vault 2.0-Methodik zu befolgen und sich an einer übergreifenden Unternehmensontologie zu orientieren, um sicherzustellen, dass alle Daten in einen einheitlichen, standardisierten Rahmen passen. All dies musste in einem Group Business Glossary (GBG) verankert werden, das wichtige Geschäftsdatenfelder definiert und standardisiert.
Erfahrungen aus der Vergangenheit nutzen
Zum Glück war ich darauf vorbereitet. Meine Erfahrungen mit Data Vault 2.0 halfen mir, die Group Enterprise Ontology dieses großen Versicherungsunternehmens zu verstehen; sie umfasste verschiedene Versicherungsbereiche. Um das Gruppendatenmodell zu verbessern und neue Bereiche hinzuzufügen, wurden Workshops und Interviews mit Fachexperten (KMU) durchgeführt. Diese Gespräche waren wichtig, um die Feinheiten ihrer Geschäftsanforderungen, Geschäftsdaten und Berichterstattungsziele zu verstehen, angefangen bei der verwendeten Terminologie bis hin zur Art und Weise, wie sie ihr Geschäft tagtäglich betreiben, und um ihren Hintergrund für die Anforderungen zu verstehen. Ich übersetzte diese Geschäftsanforderungen, die ich in den Workshops und Interviews klären konnte, in klare Modellierungs- und GBG-Definitionen und ließ sie in das Endprodukt einfließen – das Datenmodell und die Datenstandards.
Einer der wichtigsten Beiträge, die ich geleistet habe, war die Erstellung eines umfassenden Leitfadens für das Data Mapping. Dieses Dokument wurde zu einer wichtigen Ressource für OEs, da es die Ziele, die Erwartungen an die Datengranularität und die für den Abgleich erforderlichen Beziehungen erklärt. Er enthielt auch praktische Beispiele, um die Richtlinien leichter nachvollziehbar zu machen, was Missverständnisse bei der Umsetzung erheblich reduzierte. Außerdem führte ich verschiedene OE-Einführungssitzungen durch, in denen die OE-Vertreter/innen die Möglichkeit hatten, Fragen zu stellen und ihr Feedback oder Hindernisse bei der Umsetzung des Datenmodells und der Datenstandards mitzuteilen.
Überraschungen auf dem Weg
Kein Projekt verläuft ohne Überraschungen. Eine der denkwürdigsten Herausforderungen war die Verwaltung der Adressdaten durch die OEs. Anstatt eine einheitliche Ansicht zu haben, waren die Adressen auf der Seite der OEs über verschiedene Systeme verstreut – die Adressen der Versicherungsnehmer in den Policenverwaltungssystemen, die Adressen der Schadenfälle in den Schadenverwaltungssystemen und die Rechnungsadressen wurden alle separat verwaltet. Als wir vorschlugen, diese in einer einzigen Einheit mit eindeutigen Identifikatoren zusammenzufassen, wehrten sich einige OEs mit dem Argument, dass dies nicht praktikabel sei, insbesondere in mehrsprachigen Umgebungen. In Wirklichkeit war es für sie schwierig, die Adressen zu extrahieren und zu vereinheitlichen.
Um ihre Bedenken auszuräumen, schlug ich eine zukunftsfähige Lösung für die nächste Version des Modells vor: die Anreicherung der Adressdaten mit Breiten- und Längengraden, die als eindeutige Identifikatoren dienen. Dieser Ansatz erforderte zwar eine langfristige Verpflichtung, aber er half, die unmittelbaren Bedenken zu zerstreuen und ermöglichte uns, voranzukommen.
Eine weitere Herausforderung waren die unterschiedlichen Dateninfrastrukturen der einzelnen OEs. Während einige moderne Plattformen wie Snowflake nutzten, verließen sich andere auf Altsysteme, einschließlich Mainframes. Diese Diskrepanz bedeutete, dass wichtige Kennzahlen wie die Bruttoprämie (GWP) oft nicht einheitlich verfügbar waren. In einigen Fällen Ersatzwerte verwendet werden, was eine zusätzliche Validierung erforderte, um die Genauigkeit sicherzustellen.
Vielfältige Ansichten navigieren
Die unterschiedlichen Sichtweisen der Geschäftsbereiche auf die Daten machten die Sache noch komplexer. Das Group Data Office, in dem ich arbeitete, legte zum Beispiel den Schwerpunkt auf die versicherungstechnische Sichtweise (UWY), während andere sich auf die buchhalterischen Kennzahlen (ACY) konzentrierten. Dies führte zu einer weiteren Reihe von Sitzungen, in denen die Abstimmung dieser Sichtweisen detaillierte Arbeit, das Erstellen von Beispielen, Vergleiche und Erklärungen erforderte, um einen Konsens zu finden. Diese Sitzungen waren zeitintensiv, aber auch lohnend.
Die Integration älterer 3NF-Modelle in das Data Vault Framework erwies sich ebenfalls als schwierig. Einige dieser Modelle waren XML-basiert und wiesen Beziehungen auf, die sich nicht sauber in die neue Ontologie einfügen ließen. Hier ging meine Rolle über die technische Implementierung hinaus – ich musste das Team durch die Feinheiten der Abstimmung dieser Unterschiede führen und gleichzeitig die Integrität des einheitlichen Modells wahren.
Zusammenarbeiten für den Erfolg
Als das Projekt wuchs, wurden zusätzliche interne Teammitglieder an Bord geholt. Dies erweiterte zwar die Kapazität, brachte aber auch Herausforderungen mit sich, da diese Teammitglieder mit der 3NF-Modellierung besser vertraut waren als mit Data Vault. Das erforderte viel Geduld und Zusammenarbeit von mir. Ich erstellte detaillierte Beispiele, Dokumentationen und Mapping-Validierungen, um alle auf den neuesten Stand zu bringen und die Einheitlichkeit im Team zu gewährleisten. Trotz dieser Hürden haben sich die gemeinsamen Anstrengungen am Ende ausgezahlt.
Wert für den Kunden schaffen
Zum Abschluss des Projekts lieferten wir ein robustes, einheitliches Datenmodell, das:
- Standardisierte Datenberichterstattung: Konsolidierte Daten aus verschiedenen Quellen in kohärenten Rahmen, was die Gruppenberichterstattung zuverlässiger macht
- Verbesserte Datenqualität: Durch Deduplizierung und Clustering wurden Diskrepanzen beseitigt und die Entscheidungsfähigkeit verbessert.
- Verbesserte Zukunftsfähigkeit: Entwickelt, um sich an die sich entwickelnden Geschäftsanforderungen und fortschrittlichen Analyseanwendungen anzupassen.
- Erleichterte Einhaltung: Durch klare Definitionen und kontrollierten Zugang wurde die Einhaltung der GDPR und der internen Governance-Standards sichergestellt.
Zukunftsträchtig
Dieses Projekt hat mich in meinem Glauben bestärkt, dass eine durchdachte Datenmodellierung selbst die komplexesten Herausforderungen meistern kann. Es hat mir auch gezeigt, wie wichtig Anpassungsfähigkeit und effektive Kommunikation bei der Arbeit mit unterschiedlichen Interessengruppen sind. Mit Blick auf die Zukunft freue ich mich auf die Möglichkeit, Projekte in Angriff zu nehmen, die:
- Verbessere die Ontologiemodellierung und nutze Wissensgraphen für umfassendere Erkenntnisse.
- Löse grenzüberschreitende Datenherausforderungen für globale Organisationen.
- Nahtlose Integration mit KI-Systemen, um vorausschauende Analysen und Automatisierung zu ermöglichen.
Wenn ich auf diese Reise zurückblicke, bin ich unglaublich stolz auf die Lösungen, die wir entwickelt haben, und auf den kollaborativen Spirit, der zum Erfolg des Projekts beigetragen hat. Wenn Du vor ähnlichen Herausforderungen stehst oder Deine Datenarchitektur zukunftssicher machen willst, lass uns zusammenarbeiten und gemeinsam etwas Außergewöhnliches schaffen.
