Entwicklung und Integration einer Enterprise Application mit Web-UI, Workflow-gesteuerten Java-Prozessen und Message-Queuing
E-Plus (Telefónica) hat sich an das wichtige Thema “Datenlöschung” gewagt und verwaltet nun als einer der ersten Telefonanbieter seinen Kundendatenbestand strukturiert und zentralisiert datenschutzkonform.
Bisher wurden die Löschungen manuell nach einem dezentralen Analyseverfahren durch die Mitarbeiter vorgenommen. Das führte zu unterschiedlichen Auslegungen des Regelwerks und war kompliziert in der Abstimmung mit anderen Abteilungen.
Um zu verstehen, wie komplex dieses Thema ist, muss man sich vorstellen, wie viele Systeme an der Bereitstellung, Verwaltung und Betreuung der Telekommunikationsdienste beteiligt sind. Betrachten wir dazu einen fiktiven Kunden: Nennen wir ihn Frank.
Frank hat einen Mobilfunkvertrag für sich selber. Für seine Frau Andrea hat Frank eine zweite SIM-Karte unter seinem Vertrag laufen. Dann hat er vor einiger Zeit für seine Tochter Lisa einen Prepaid-Tarif bestellt. Lisa ist nun volljährig und hat selber einen Mobilfunkvertrag. Die Prepaid-Karte hat zwar noch ein Restguthaben, ruht jedoch. Für seinen Sohn Luke hat er auch einen Prepaid-Tarif gewählt. Lukes Handy wurde samt Karte gestohlen. Die Karte ist zwar gesperrt, wurde aber zwischenzeitlich von Dritten genutzt – hier ist noch offen, ob Franks Versicherung oder die des Telefonanbieters den Schaden trägt.
Jetzt hat sich Frank dazu entschlossen, den Mobilfunkanbieter zu wechseln und kündigt seinen Vertrag. Für den Mobilfunkanbieter hat er nun den Status eines „deaktiven Kunden“ und der Anbieter steht vor der Herausforderung, Franks Daten in Hinblick auf Datenschutz, buchhalterische und rechtliche Vorgänge korrekt zu verwalten.
Was an dem Beispiel deutlich werden sollte: Franks personenbezogene Daten sind in vielen verschiedenen Systemen hinterlegt und werden dort auch benötigt:
Für verschiedene Abläufe gelten unterschiedliche Aufbewahrungsfristen. Rechnungen müssen beispielsweise 10 Jahre lang aufbewahrt werden. Verbindungsdaten hingegen müssen bereits nach kurzer Zeit gelöscht werden – es sei denn, sie sind wiederum rechnungsrelevant.
Eine weitere Herausforderung liegt darin, dass nicht jedes System dieselben Daten speichert. Manche Systeme verwenden und kennen nur die SIM-Nummer der stillgelegten Prepaid-Karte, andere nur die Mobilfunknummer der zweiten SIM-Karte. Alle diese Daten sind jedoch personenbezogen, da sie auf die Person Frank zurückzuführen sind.
In dieser Ausgangssituation ist unser Kunde zu uns gekommen. Unsere Aufgabe war es, ein System zu entwickeln, welches die Löschung obsoleter Kundendaten steuert und kontrolliert. Nur Daten zu löschen, wäre einfach. Unser System soll natürlich nur die Daten zur Löschung freigeben, die nach gewissen Vorgaben entfernt werden müssen. Und zwar überall dort, wo Daten hinterlegt sind, die auf irgendeine Weise Rückschlüsse auf die Person Frank zulassen. Im weiteren Verlauf nennen wir diese Löschkandidaten „deaktive Kunden“.
Aus der Beschreibung oben wurde sicherlich klar, dass diese Aufgabe ganz schön komplex ist.
Ein System für die saubere und automatisierte Löschung personenbezogenener Kundendaten
Zunächst mussten wir herausfinden, in welchen Systemen personenbezogene Daten erfasst werden – denn in diesen müssen die Daten gelöscht werden.
Dabei gibt es:
Systeme der zweiten und dritten Kategorie nennen wir Quellsysteme, da sie uns helfen, die Löschkandidaten zu identifizieren. Systeme in denen Daten gelöscht werden müssen, nennen wir Zielsysteme.
Das Kniffelige ist, dass keines der Quellsysteme alle Identifikationsmerkmale darüber enthält, ob ein Kunde gelöscht werden darf und auch nicht alle zu löschenden Datenarten enthält. Jedes System verwaltet seine Daten an Hand seiner eigenen Verwaltungsstruktur.
Hier ein vereinfachtes Beispiel: Quellsystem A kennt die Kundennummer und die Vertragsnummer. Quellsystem B kennt die Telefonnummer und die SIM-Kartennummer aber keine Vertrags- oder Kundennummer. System C kennt dafür wiederum die Vertragsnummer und die Telefonnummer. Über System C können so die Daten aus System A und System B verknüpft werden und einer spezifischen Kundennummer zugeordnet werden.
Allerdings kann es sein, dass gewisse Daten eines deaktiven Kunden noch nicht gelöscht werden dürfen. Das ist beispielsweise der Fall, wenn das Restguthaben einer Prepaid-Karte noch nicht ausgezahlt wurde oder es noch offene Rechnungen bei einem Laufzeitvertrag gibt.
Diese Information kommt aus Quellsystem D. Es muss also ein weiterer Abgleich stattfinden.
Nur die Systeme A, B, C und D zusammen, enthalten die Informationen darüber, ob ein Kunde gelöscht werden darf.
Soweit so gut. Fassen wir zusammen: DROP fragt bei verschiedenen Quellsystemen die Daten an, die benötigt werden, um ein vollständiges Bild des deaktiven Kunden zu erhalten. Das bedeutet, in DROP liegen nun die Daten, die zwingend nötig sind, um eine Löschentscheidung zu treffen und um die Kunden in den verschiedenen Zielsystemen zu identifizieren.
Wie jedoch eingangs schon beschrieben, gibt es Daten, die länger aufbewahrt werden müssen als andere. Und unter gewissen Umständen dürfen auch Daten, deren ursächliche Aufbewahrungsfrist schon verstrichen ist, noch nicht gelöscht werden.
Diese (wirklich sehr verschachtelten) fachlichen Zusammenhänge wurden von uns in ein programmatisches Regelwerk übersetzt. Das klingt jetzt irgendwie simpel – war es aber nicht. Die vielen Wenn-Dann-Fälle sauber in ein logisches Regelwerk zu packen, war ein zentraler Meilenstein des Projekts.
Zusammenfassung: Nach der Konsolidierung durchlaufen die Daten in DROP ein Löschregelwerk. Dabei wird für jeden Kunden entschieden, ob und nach welchen Regeln er gelöscht werden muss.
Erst jetzt ist das Bild vollständig: DROP kennt alle Kunden, weiß ob und warum sie gelöscht werden müssen und kann sie in jedem Zielsystem eindeutig zuordnen.
Sie denken, wir können jetzt endlich mit dem Löschen beginnen? Nun ja – nachdem die vorangegangenen Schritte so komplex waren, liegt auf der Hand, dass die Übertragung der Löschbefehle nicht weniger komplex ist.
Um die Löschung anzustoßen, erstellt DROP eine Liste mit Löschbefehlen. Diese Liste wird den Zielsystemen (Sie erinnern sich? Das sind die Systeme in denen Daten entfernt werden müssen.) zur Verfügung gestellt. Jedes Zielsystem kann dieser Liste entnehmen, ob und welche Daten es zu löschen hat.
So viel zur Theorie. In der Praxis bedeutet dieser Vorgang: Es muss eine enorme Datenmenge verschoben und verarbeitet werden. Diese Rechenleistung wird den unterschiedlichsten, teilweise sehr alten Systemen abverlangt. Nicht jedes System kann mit solch großen Datenmengen gleichermaßen umgehen. Um den Betriebsablauf nicht zu stören, galt zu berücksichtigen, dass die Systeme durch die Löschvorgänge nicht verlangsamt werden dürfen.
Unsere Lösung: Damit hier so schnell wie möglich aber so langsam wie nötig vorgegangen werden kann, bekommt jedes System die Löschbefehle individuell in genau den Paketmengen, die das jeweilige System verarbeiten kann. Die Löschpakete werden also asynchron zugestellt.
Manche Systeme bekommen nur Daten in der Nacht – also zu betriebsarmen Stunden – andere können pro Stunde maximal eine Hand voll Datensätze verarbeiten und andere Systeme sind leistungsstärker und kommen zügiger voran.
Jetzt wird es wieder etwas einfacher. Die Löschlisten werden in regelmäßigen Abständen den Zielsystemen zur Verfügung gestellt. Kunden, welche auf der Liste stehen, werden aus den Systemen entfernt.
Der Gesetzgeber verlangt einen Beleg über die Löschung der Daten. Um dieser Forderung nachzukommen, wird in einem separaten Report dokumentiert, welche Daten erfolgreich gelöscht wurden. Da dieser Report wiederum personenbezogene Daten enthält, wird dieser nach eine Schutzdauer ebenfalls vernichtet. Ist dieser Prozess abgeschlossen, sind die Kundendaten unwiderruflich und somit datenschutzkonform gelöscht.
Dass die ganze Nummer recht kompliziert wird, war uns klar. Im Laufe des Projekts gab es jedoch noch ein paar unvorhergesehene Herausforderungen zu meistern.
Eine der Herausforderungen war die teilweise schlechte Datenqualität. Viele Datenbestände waren so alt, wie das Unternehmen – viele Daten, Systeme und Prozesse sind 10 bis 20 Jahre alt – im digitalen Zeitalter sind das regelrechte Fossilien.
Damit nichts Falsches gelöscht wird, haben wir so eine Art Reißleine eingebaut: Stößt DROP auf ein widersinniges oder unverständliches Datum, wird es nicht gelöscht, sondern es wird eine Warnung zurück gespielt. Diese Daten müssen dann individuell, händisch abgeglichen und korrigiert werden. Nach der Korrektur kann der Datensatz beim nächsten Durchlauf von DROP erneut erfasst werden.
Das Löschen von Kundendaten ist ein unternehmenskritischer Vorgang. Fehler sind hier nicht verzeihlich. Daher gab es eine intensive Testphase und eine mehrstufige Einführung des Systems.
Im Laufe der Integrationstests wurde jedoch schnell klar, dass die Testdaten nicht „echt“ genug waren. Die Komplexität der Vorgänge erforderte ein realitätsnäheres Testfeld als die bisherigen Systeme.
Wir haben die Live-Daten ausführlich analysiert und konnten für das Testing so ein passgenaues Testfeld aufstellen.
Die ganze Anwendung DROP ist geprägt von Asynchronität und Parallelität. Damit DROP sauber läuft, mussten wir jede Menge komplexe Abläufe und Datenbeziehungen formulieren, Prozesse steuern und externe Schnittstellen bedienen. Für die Ablaufsteuerung haben wir Activiti eingesetzt – eine BPMN-konforme Workflow Engine. Das hat den Vorteil, dass Workflows grafisch dargestellt werden und sich so auch den Fachverantwortlichen (die Code nicht so sehr lieben wir wir) erschließen. Das erleichterte die Kommunikation zwischen Technikern und Fachbereichen enorm. So konnten wir gemeinsam die technische Umsetzung der Anforderungen begutachten.
Um die Prozesse zeitlich voneinander zu entkoppeln, kommunizieren diese über einen Message-Bus (Active MQ) miteinander. Bei der Implementierung der Schnittstellen nach Außen haben wir auf bewährte Enterprise Integration Patterns gesetzt. Dabei kam Apache Camel zum Einsatz.
Wir betreuen Unternehmen der Telekommunikationsbranche in den Bereichen Fraud-Management und Compliance bereits seit vielen Jahren. Für dieses Projekt wurden wir explizit angefragt, da wir als versierter, unkomplizierter und flexibler Partner bekannt sind.
Insgesamt haben wir gemeinsam von der Konzeption über das Testing bis zum Livegang sehr eng zusammengearbeitet. Wir waren stets über die Status der Aufgaben der anderen informiert.
Seit April 2015 ist das System live und obsolete Kundendaten werden datenschutzkonform gelöscht.
Spring Framework | ORM (Objekt Relationales Mapping ) – Hibernate |Message Queuing – Active MQ | Web-Framework – Apache Wicket | BPMN Workflow Engine – Activiti | Enterprise Integration – Apache CAMEL
DROP war sicherlich eines der anspruchsvollsten Projekte, die wir bisher machen durften. Gerade deswegen sind wir stolz auf das Ergebnis und haben selber sehr viel dabei gelernt. Es ist immer wieder schön, Herausforderungen zu meistern und davon hat uns dieses Projekt jede Menge geboten. Unser Kunde hat die Wichtigkeit des Themas erkannt und mit diesem System einen wahren Meilenstein in Sachen Datenschutz gelegt. Aus Sicht der Verbraucher ist zu hoffen, dass andere Unternehmen diesem Vorbild folgen und ebenfalls zügig einen datenschutzkonformen Umgang mit ihren Kundendaten etablieren.
Stefan Michaelis
Prokurist, Business Unit Executive
valantic Telco Solutions & Services
