Lesezeit: 4 Minuten
Daten-Silos in Legacy-Applications aufbrechen
Fast in jedem Unternehmen gibt es sie: in die Jahre gekommene Software, die nach wie vor wichtige Kernaufgaben erfüllt. Und fast immer würde man genau diese Software gerne um neue Features erweitern, doch das ist oft mehr als schwierig.
Wir möchten mit diesem Artikel einen interessanten Weg aufzeigen, wie wir eine Legacy-App ohne Programmieraufwand um einen Audit-Log erweitert haben.
Wo drückt der Schuh?
Unsere Agentur dkd Internet Service GmbH existiert seit über zwanzig Jahren. Sehr bald erkannten wir, dass wir eine Software zur Zusammenarbeit in Projekten, Zeiterfassung und Kollaboration im Arbeitsalltag benötigen. Zum damaligen Zeitpunkt gab es noch nicht die unglaubliche Auswahl an Produktivitätswerkzeugen wie heute, weshalb wir die Entwicklung unserer Agentur-Software selbst in die Hand genommen haben.
Auch wenn ein Produkt nicht aktiv an Dritte verkauft wird, muss es doch gewartet und weiterentwickelt werden. Dabei sind neue Features vergleichsweise teuer, da man diese nur für sich selbst entwickelt. So ist auch unsere Agentur-Software deutlich in die Jahre gekommen und deshalb wollen wir keine umfangreichen Features mehr ergänzen. Dennoch ist eine Ablösung dieser immens wichtigen Software nicht von heute auf morgen möglich.
Eine Funktionalität, die wir immer wieder vermissen, ist die Versionierung von Datensätzen und somit die Protokollierung sämtlicher Vorgänge innerhalb der Software. Häufig spricht man hier auch von einem Audit-Log. Zu jedem Zeitpunkt wollen wir in der Lage sein, nachvollziehen zu können, wie sich unsere Daten über die Zeit verändert haben. Zum Beispiel: Hatte die Mitarbeiterin Freya im Januar nun 30 oder 40 Wochenstunden?
Bei der Softwareentwicklung setzen wir schon länger ein Versionskontrollsystem ein. Gibt es vielleicht etwas Vergleichbares für die mindestens ebenso wichtigen Daten?
Features ohne Programmierung
Die Idee stand im Raum, den Code unserer fast zwanzig Jahre alten Software um die neue Funktionalität, das Audit-Log, zu erweitern. Das würde aber vermutlich nicht nur viel Zeit in Anspruch nehmen, sondern auch mögliche neue Fehlerquellen in die Software einführen. Glücklicherweise hatten wir uns bei der Entwicklung unserer Agentur-Software bereits für die Speicherung der Anwendungsdaten in einem Datenbanksystem (MySQL) entschieden. Was wäre, wenn die Erweiterung der Software um die Versionierung der Daten ohne jegliche Veränderung der Software umgesetzt werden kann? Könnten wir vielleicht direkt an der verwendeten MySQL-Datenbank ansetzen? Wir machten uns daher auf die Suche nach einem externen Ansatz zur Umsetzung des benötigten Features.
CDC to the Rescue
Bei unserer Suche stießen wir auf die Technologie Change Data Capture (CDC). Damit können sämtliche Änderungen an einer Datenbank erkannt und weiterverarbeitet werden. Und mit der Data-Pipeline-Plattform DataCater lässt sich diese Technologie auch mit geringem Aufwand zum Einsatz bringen.
DataCater stellt CDC-Konnektoren für die meisten Datensysteme, so auch MySQL, zur Verfügung und ermöglicht Anwendern Konnektoren und Pipelines innerhalb weniger Minuten zu erstellen und in Betrieb zu nehmen.
DataCater arbeitet nach dem Streaming-Prinzip: Änderungen an unserer MySQL-Datenbank (und somit an Daten unserer Agentur-Software) stehen nicht nur feingranular zur Verfügung, sondern können auch in Echtzeit weiterverarbeitet werden. So können wir beispielsweise Pseudonymisierungen durchführen, bevor wir die extrahierten Daten für die weitere Speicherung in einer neuen Datenbank ablegen.
Den jeweiligen Stand eines relevanten Datensatzes speichern wir in einer separaten Datenbank. Diese haben wir basierend auf der Struktur der Originaldatenbank erstellt. In der neuen Datenbank werden nun alle Änderungen mit einem Zeitstempel archiviert.
Auf Basis dieses Setups haben wir nun Zugriff auf alle Veränderungen, die im Laufe der Zeit an einzelnen Datensätzen erfolgt sind. Die Daten liegen so zwar noch in einer recht rohen Form vor – im ersten Schritt relevant ist jedoch, dass wir die Information überhaupt zur Verfügung haben. (Den komfortablen Umgang mit diesen Daten erläutern wir weiter unten im Abschnitt “Die Technik im Detail”.)
Ergebnis
DataCater hat uns schnell und einfach in die Lage versetzt, unsere Legacy-App “Agentursoftware” um das Feature eines Audit-Logs zu erweitern. Damit waren wir ohne direkte Anpassungen am Code der Software selbst in der Lage eine Änderungsverfolgung in unserer Agentur-Software nachzurüsten – und das auch noch für sehr kleines Geld.
Wer sich nun noch für die technischen Details interessiert, kann einfach weiterlesen, denn darauf gehen wir im nachfolgenden Abschnitt detailliert ein.
Die Technik im Detail
Change Data Capture (CDC)
CDC ist die Kerntechnologie, die in unserem Use Case zum Einsatz kommt. In unserem Fall kann CDC bei MySQL mithilfe des MySQL-Features Binlog umgesetzt werden. Sämtliche Änderungen, die auf einer Datenbank ausgeführt werden, also INSERTs, UPDATEs und DELETEs, werden in chronologischer Reihenfolge zur Verfügung gestellt und so eignet sich diese Technologie perfekt zur Versionierung unserer Datenbasis.
Bei DataCater stehen neben MySQL aber auch jede Menge andere Konnektoren zur Verfügung (PostgreSQL, Azure SQL, etc.), so dass ein großes Spektrum an Datenquellen unterstützt wird.
Streaming Data-Pipelines
Über eine Streaming Data-Pipeline lassen sich die entstehenden Daten bequem und effizient aus der Datenquelle (in unserem Fall die MySQL-Datenbank unserer Agentursoftware) in eine Datensenke (in unserem Fall eine zweite MySQL-Datenbank) überführen. Zwei große Vorteile einer Pipeline sind dabei, dass der Transfer in Echtzeit erfolgt und dass während des Transfers Transformationen und Filter angewendet werden können. So können irrelevante oder sensible Informationen verworfen oder Daten in ein anderes Format überführt werden.
Insbesondere in diesem Schritt kann DataCater seine Stärken ausspielen, denn für das Anlegen der Pipelines sind keinerlei Programmierkenntnisse erforderlich. Die gesamte Pipeline-Verwaltung geschieht über ein benutzerfreundliches Web-Interface und ist in wenigen Minuten erledigt.
Zugriff auf Versionierungsdaten
Da die erzeugten Versionierungsdatensätze alle in einer SQL-Datenbank gespeichert sind, ist ein Zugriff auf diese direkt per SQL möglich. Das setzt aber Kenntnisse in SQL voraus und bleibt so eher erfahrenen Entwicklern vorbehalten.
Um den Zugriff auf diese Daten zu vereinfachen haben wir uns ein eigenes Package in der Programmiersprache »R« geschrieben. Da wir bei dkd die meisten Datenanalysen mit »R« durchführen, war dies auch hier unsere erste Wahl. So sind für eine Verwendung der Daten immer noch R-Kenntnisse erforderlich – allerdings reicht hier bereits Einsteigerniveau.
Unser R-Paket kann für den Benutzer aus den gesamten Versionierungsdatensätzen die gefragten Informationen direkt zurückliefern. So können Anfragen wie “In welchem Team war der Mitarbeiter »Baldr« im Monat Januar?” über eine einfache Abfrage beantwortet werden.
Fazit
Die oben beschriebene Lösung hat uns mit nur geringem Zeit- und Geldeinsatz in die Lage versetzt, eine deutlich veraltete Software um ein wichtiges Feature zu erweitern – und das ohne Risiko die Applikation selbst zu beeinträchtigen.
Und ja, wir würden es wieder so machen, denn das Ergebnis hat uns sehr positiv überrascht.
Wer jetzt neugierig geworden ist, findet auf der Website von DataCater mehr Informationen zu Streaming-Data-Pipelines und auf der Website von Projekt R mehr über diese sehr spannende Programmiersprache.
Jetzt Daten-Silos in Legacy-Applications aufbrechen!
Kommentare
Keine Kommentare
Kommentar schreiben