Beispiel für eine typische Ausgangslage vor dem Einsatz einer automatisierten TDM Lösung wie XDM von UBS-Hainer.
Die folgende Beschreibung bildet das reale Beispiel eines großen Versicherers und Kunden von UBS Hainer ab. Dieser konnte durch den Einsatz der Testdatenmanagement-Software „XDM“ alle seine Herausforderungen meistern (und steht übrigens als Referenzkunde jederzeit für diesbezügliche Nachfragen und Auskünfte zur Verfügung).
Und das war die Ausgangslage bzw. Aufgabenstellung:
Das IT-technische Rückgrat des Versicherers war ein in den 1990er Jahren entwickeltes Versicherungs-Agentursystem. Dabei handelte es sich im Wesentlichen um ein monolithisches System mit einer zentralen Hausdatenbank, in der sämtliche Daten gelagert waren.
Durch diese Konstellation war es relativ einfach, Testdaten zu generieren. Dazu zapfte man einfach den zentralen Datentopf mit Produktivdaten an. Die gewünschten Datensätze wurden herunterkopiert und auf die verschiedenen Testsysteme verteilt. Während des Kopiervorgangs wurden gleichzeitig die personenbezogenen Informationen in den Datensätzen pseudonymisiert. Der komplette Vorgang des Kopierens, Verteilens und der Pseudonymisierung wurde mittels eines auf dem Host selbst entwickelten Software-Tools bewerkstelligt.
All das hat recht gut funktioniert, bis man dann im Jahr 2015 gewisse Grenzen erreichte. Die Constraints bei den Anwendungen nahmen zu. Es gab Handlungsbedarf – nicht zuletzt, um den IT-technischen Anschluss nicht zu verlieren.
Umstrukturierung der Produktivdaten
Daher begann man im Jahr 2015, eine Nachfolgelösung aufzubauen und dazu das bestehende Versicherungs-Agentursystem umzubauen. Das neu entstandene System basiert – zumindest in Teilen – auf einem Self-Contained-Systems-Ansatz. Dazu wurde das bisher monolithische System in Teilsysteme verschiedener fachlicher Anwendungskomponenten zerschlagen. Diese Teilsysteme sind in sich geschlossen und kommunizieren untereinander über REST bzw. Kafka Schnittstellen.
Rein praktisch führte dies dazu, dass die Datensätze jetzt nicht mehr wie vorher komplett in einer Hausdatenbank liegen, sondern über mehrere Datenbanken hinweg verteilt sind. So liegen z.B. die Stammdaten eines Kunden in einer der Datenbanken, die Vertragsdaten „Kfz“ in einer anderen und weitere Vertragsdaten in weiteren Datenbanken.
Hinzu kommt, dass es sich bei diesen Datenbanken nicht um eine homogene Datenbanklandschaft handelt. Vielmehr werden mehrere Datenbanktypen parallel eingesetzt. Einige der für Testzwecke benötigten Daten liegen z.B. auf einer IBM LUW, andere in einer PostgreSQL. Aber auch das IBM DB2/zOS System wird – voraussichtlich bis zum Jahr 2030 – verwendet. Auch dort werden also weiterhin produktive Daten liegen, die für Tests gebraucht werden.
Die bisherige TDM-Lösung funktionierte nicht mehr
Was bedeuten diese Änderungen nun für die Beschaffung von Testdaten? Im Zuge der Umstrukturierung wurde die Beschaffung von Testdaten zu einer massiven Herausforderung. Die bisher bewährte Lösung funktioniert nicht mehr.
Wird nun ein kohärenter Datensatz zu Testzwecken benötigt, müssen die jeweils benötigten Teildaten auf den verschiedenen Systemen gefunden, kopiert und dann zu einem kompletten Satz kombiniert werden. Gleichzeitig muss dieser Testdatenfall konsistent pseudonymisiert werden.
Der so entstehende DSGVO-konforme Testdatenfall muss nun in das jeweilige Testsystem kopiert und dort wieder auf die verschiedenen Datenbanksysteme verteilt werden. Dabei müssen die authentischen Relationen bestehen bleiben. All das muss automatisiert und je nach Bedarf mit hunderttausenden Datensätzen erfolgen. Dazu braucht es ein stabiles und erprobtes System, das gleichzeitig von mehreren hundert Entwicklern genutzt werden kann.
Letztlich suchte man zur Ablösung des Bestandssystems eine neue Lösung, die mit der verteilten Welt zurechtkommt aber auch problemlos auf die zOS-Welt zugreifen kann. Und es musste möglich sein, dieses System im laufenden Betrieb zu implementieren. Der beschriebene Versicherer kam zu dem Schluss, dass XDM von UBS Hainer diese Herausforderungen meistern kann. Es wurde ein PoC aufgesetzt, und in der Folge wurde die Testdatenautomation erfolgreich implementiert.
