12.02.2021 | FABIAN DIMSKI

Man könnte meinen, dass es im Jahr 2021 zu einer Binsenweisheit geworden ist, dass hochwertige Daten die notwendige Voraussetzung für erfolgreiche (digitale) Prozesse sind:

„Daten sind das Öl des 21. Jahrhunderts“, „Daten sind das neue Gold“, „Daten sind (so wichtig) wie Wasser“ – fast mantra-artig werden diese Vergleiche seit Jahren bemüht und sollen alle dasselbe unterstreichen:

Ohne (gute) Daten funktioniert im 21. Jahrhundert nichts mehr.

Deshalb wäre zu erwarten, dass mittlerweile jedes Unternehmen seinen Daten auch tatsächlich die entsprechende „Aufmerksamkeit“ widmet, die sie offensichtlich verdienen: dass also die Themen Data Governance (DG) und Data Quality Management (DQM) im Fokus der Geschäftsführung stehen und zentrale Bestandteile des unternehmerischen Handelns geworden sind. Selbstverständlich ausgestattet mit den erforderlichen personellen und finanziellen Ressourcen.

Die Praxis sieht jedoch anders aus: in vielen Unternehmen fristet das Thema Datenqualität noch immer ein Nischendasein, dessen Bedeutung vielfach unterschätzt wird.

Aber leider stellt sich in keinem Unternehmen der Welt hochwertige Datenqualität einfach von selbst ein, sondern sie ist immer das Ergebnis von strategischen, taktischen und operativen Maßnahmen, und zwar auf organisatorischer, prozessualer und technischer Ebene. Das heißt, nachhaltiges DG und zielgerichtetes DQM sind komplexe Herausforderungen.

Vielleicht ist das, neben dem Kostenaspekt, einer der Gründe, dass viele Unternehmen in der Praxis (noch) davor zurückschrecken, sich den Themen strukturiert zu widmen: wo und wie soll man anfangen? Noch dazu, wenn die eigene IT-Landschaft aus Dutzenden oder sogar Hunderten Systemen besteht, und die Prozesse und Daten proprietär und heterogen sind?

Einfache Lösungen gibt es dafür naturgemäß leider nicht. Aber von zahlreichen Herstellern gibt es ausgereifte Data-Governance- und Data-Quality-Systeme, die mit ihren generischen Konzepten und ihrer großen Flexibilität, beliebige „Datenlandschaften“ erfassen und abbilden können, um so die Grundlage für erfolgreiches DG- und DQ-Management zu schaffen.

Denn natürlich gilt gerade für die Datenqualität: If you can’t measure it, you can’t manage it.

Im Folgenden soll deshalb ein Schlaglicht auf ein solches DQ-System geworfen werden, mit dem Datenqualität transparent und damit steuerbar gemacht werden kann. Bayard Consulting begleitet seit fast drei Jahren einen international agierenden Handelskonzern bei Aufbau und Roll-Out des DQ-Systems Data Quality von Informatica.

Ziel dieses Blog-Beitrags soll es natürlich nicht sein, das System umfassend vorzustellen, sondern einen Eindruck über die Einsatzmöglichkeiten des Systems, seine Stärken und auch seine Schwächen zu vermitteln.

Deshalb wäre zu erwarten, dass mittlerweile jedes Unternehmen seinen Daten auch tatsächlich die entsprechende „Aufmerksamkeit“ widmet, die sie offensichtlich verdienen: dass also die Themen Data Governance (DG) und Data Quality Management (DQM) im Fokus der Geschäftsführung stehen und zentrale Bestandteile des unternehmerischen Handelns geworden sind. Selbstverständlich ausgestattet mit den erforderlichen personellen und finanziellen Ressourcen.

Die Praxis sieht jedoch anders aus: in vielen Unternehmen fristet das Thema Datenqualität noch immer ein Nischendasein, dessen Bedeutung vielfach unterschätzt wird.

Aber leider stellt sich in keinem Unternehmen der Welt hochwertige Datenqualität einfach von selbst ein, sondern sie ist immer das Ergebnis von strategischen, taktischen und operativen Maßnahmen, und zwar auf organisatorischer, prozessualer und technischer Ebene. Das heißt, nachhaltiges DG und zielgerichtetes DQM sind komplexe Herausforderungen.

Vielleicht ist das, neben dem Kostenaspekt, einer der Gründe, dass viele Unternehmen in der Praxis (noch) davor zurückschrecken, sich den Themen strukturiert zu widmen: wo und wie soll man anfangen? Noch dazu, wenn die eigene IT-Landschaft aus Dutzenden oder sogar Hunderten Systemen besteht, und die Prozesse und Daten proprietär und heterogen sind?

Einfache Lösungen gibt es dafür naturgemäß leider nicht. Aber von zahlreichen Herstellern gibt es ausgereifte Data-Governance- und Data-Quality-Systeme, die mit ihren generischen Konzepten und ihrer großen Flexibilität, beliebige „Datenlandschaften“ erfassen und abbilden können, um so die Grundlage für erfolgreiches DG- und DQ-Management zu schaffen.

Denn natürlich gilt gerade für die Datenqualität: If you can’t measure it, you can’t manage it.

Im Folgenden soll deshalb ein Schlaglicht auf ein solches DQ-System geworfen werden, mit dem Datenqualität transparent und damit steuerbar gemacht werden kann. Bayard Consulting begleitet seit fast drei Jahren einen international agierenden Handelskonzern bei Aufbau und Roll-Out des DQ-Systems Data Quality von Informatica.

Ziel dieses Blog-Beitrags soll es natürlich nicht sein, das System umfassend vorzustellen, sondern einen Eindruck über die Einsatzmöglichkeiten des Systems, seine Stärken und auch seine Schwächen zu vermitteln.

Data Quality von Informatica

„Data Quality“ von Informatica (kurz IDQ) ist ein Enterprise-System zur Validierung von Daten. Das System ist sowohl als On-Premise-Lösung als auch in der Cloud verfügbar.

Dass einer der „Platzhirsche“ unter den ETL-Tools prädestiniert dafür ist, auch im Bereich Datenqualität ein mächtiges Werkzeug, oder eher noch einen ganzen Werkzeugkasten, bereitzustellen, ist wenig überraschend: denn jede Datenqualitätsprüfung besteht aus diesen drei Schritten:

  • Extract: die zu prüfenden Daten werden aus dem/den Quellsystem(en) geladen.
  • Transform: die Daten werden den jeweiligen Prüfprozessen unterzogen.
  • Load: die Prüfergebnisse werden gespeichert.

Die Umsetzung dieser drei Prozessschritte mit IDQ soll im Folgenden erläutert werden. (Nicht vorgestellt wird dabei die webbasierte IDQ-Analyst-Komponente, mit der sog. Data-Profilings ad hoc auch durch Endanwender möglich sind.)

1. Extract – flexibler Zugriff auf beliebige Datenquellen mit IDQ

Ein IDQ-System lässt sich schnell und flexibel in tatsächlich jede IT-Landschaft integrieren: mit seinen zahlreichen so genannten Konnektoren bietet IDQ direkten Zugriff auf beliebige Datenquellen: alle gängigen relationalen Datenbanksysteme, Non-SQL-Datenspeicher, Data Lakes und Webservices können mit IDQ angebunden werden. In der Regel sind dazu lediglich Konfigurationseinstellungen im jeweiligen Konnektor vorzunehmen.
Nach dem Verbindungsaufbau kapseln so genannte Logical Data Objects (LDO) den Datenzugriff und verbergen technische Details, so dass sämtliche Daten nach dem Einlesen quellsystem-unabhängig und standardisiert weiterverarbeitet werden können. Selbstverständlich erlauben LDO es auch, komplexe Datenstrukturen innerhalb von IDQ aufzubauen, um diese anschließend zu analysieren. Die Datenzugriffe können parametriert erfolgen, so dass eine maximale Wiederverwendbarkeit der Komponenten auch in komplexen IT-Landschaften gewährleistet ist.

1. Extract – flexibler Zugriff auf beliebige Datenquellen mit IDQ

Ein IDQ-System lässt sich schnell und flexibel in tatsächlich jede IT-Landschaft integrieren: mit seinen zahlreichen so genannten Konnektoren bietet IDQ direkten Zugriff auf beliebige Datenquellen: alle gängigen relationalen Datenbanksysteme, Non-SQL-Datenspeicher, Data Lakes und Webservices können mit IDQ angebunden werden. In der Regel sind dazu lediglich Konfigurationseinstellungen im jeweiligen Konnektor vorzunehmen.
Nach dem Verbindungsaufbau kapseln so genannte Logical Data Objects (LDO) den Datenzugriff und verbergen technische Details, so dass sämtliche Daten nach dem Einlesen quellsystem-unabhängig und standardisiert weiterverarbeitet werden können. Selbstverständlich erlauben LDO es auch, komplexe Datenstrukturen innerhalb von IDQ aufzubauen, um diese anschließend zu analysieren. Die Datenzugriffe können parametriert erfolgen, so dass eine maximale Wiederverwendbarkeit der Komponenten auch in komplexen IT-Landschaften gewährleistet ist.

2. Transform – eine gut sortierte Bibliothek für alle Arten der Datenverarbeitung

Als klassisches ETL-System bildet auch IDQ die Datenverarbeitungen durch den Aufbau von Transformationsketten ab. Die Bibliothek der einzelnen Transformationsbausteine in IDQ bildet dabei das „Herz“ der Applikation: wie auch in vergleichbaren Tools stehen selbstverständlich u. a. Joiner-, Sorter-, Parser- oder Filter-Transformationen zur Verfügung, die per Drag and Drop miteinander verkettet werden. Datenvalidierungen, um bspw. die Vollständigkeit, Konsistenz und Gültigkeit von Daten zu prüfen, lassen sich so auf einfache Art und Weise konfigurieren.
Besonders interessant in IDQ ist die so genannte Match-Transformation, die es erlaubt, mit Hilfe verschiedener Algorithmen (wie z. B. Bigram-, Jaro- oder Hamming-Distance) Ähnlichkeiten zwischen Datensätzen zu identifizieren. Für komplexe Dublettenprüfungen, mit denen (unerwünschte) Duplikate in Datenbeständen identifiziert werden können, ist dies ein mächtiges Werkzeug in IDQ.
Einzelne Transformationsketten werden in IDQ in sog. Mapplets gekapselt, die wiederum in sog. Mappings wiederverwendet werden können). Etabliert man (idealerweise zum Start der (I)DQ-Initiative) entsprechende Design-Standards und Coding Principles und investiert die erforderliche Zeit auch in die Dokumentation der implementierten Module, erlaubt IDQ auf diese Art eine komponentenbasierte Entwicklung, die kurze Entwicklungszyklen und ein robustes Laufzeitverhalten der IDQ-Workflows ermöglicht.
Wie bei jedem anderen „Werkzeug“ auch, wird natürlich Erfahrung im Einsatz mit IDQ benötigt, um nicht versehentlich mit einem „Schraubendreher“ einen „Nagel in die Wand schlagen zu wollen“. Tatsächlich ist die Einarbeitung in IDQ allerdings so gering komplex, dass erfahrene Software-Entwickler bereits nach kurzer Zeit arbeitsfähig sind, wenn auch naturgemäß tiefe Expertise mit der Zeit erarbeitet werden muss.

2. Transform – eine gut sortierte Bibliothek für alle Arten der Datenverarbeitung

Als klassisches ETL-System bildet auch IDQ die Datenverarbeitungen durch den Aufbau von Transformationsketten ab. Die Bibliothek der einzelnen Transformationsbausteine in IDQ bildet dabei das „Herz“ der Applikation: wie auch in vergleichbaren Tools stehen selbstverständlich u. a. Joiner-, Sorter-, Parser- oder Filter-Transformationen zur Verfügung, die per Drag and Drop miteinander verkettet werden. Datenvalidierungen, um bspw. die Vollständigkeit, Konsistenz und Gültigkeit von Daten zu prüfen, lassen sich so auf einfache Art und Weise konfigurieren.
Besonders interessant in IDQ ist die so genannte Match-Transformation, die es erlaubt, mit Hilfe verschiedener Algorithmen (wie z. B. Bigram-, Jaro- oder Hamming-Distance) Ähnlichkeiten zwischen Datensätzen zu identifizieren. Für komplexe Dublettenprüfungen, mit denen (unerwünschte) Duplikate in Datenbeständen identifiziert werden können, ist dies ein mächtiges Werkzeug in IDQ.
Einzelne Transformationsketten werden in IDQ in sog. Mapplets gekapselt, die wiederum in sog. Mappings wiederverwendet werden können). Etabliert man (idealerweise zum Start der (I)DQ-Initiative) entsprechende Design-Standards und Coding Principles und investiert die erforderliche Zeit auch in die Dokumentation der implementierten Module, erlaubt IDQ auf diese Art eine komponentenbasierte Entwicklung, die kurze Entwicklungszyklen und ein robustes Laufzeitverhalten der IDQ-Workflows ermöglicht.
Wie bei jedem anderen „Werkzeug“ auch, wird natürlich Erfahrung im Einsatz mit IDQ benötigt, um nicht versehentlich mit einem „Schraubendreher“ einen „Nagel in die Wand schlagen zu wollen“. Tatsächlich ist die Einarbeitung in IDQ allerdings so gering komplex, dass erfahrene Software-Entwickler bereits nach kurzer Zeit arbeitsfähig sind, wenn auch naturgemäß tiefe Expertise mit der Zeit erarbeitet werden muss.

3. Load – Erzeugung beliebiger Ausgaben mit IDQ

Auf der Ausgabeseite ist IDQ einerseits stark aufgestellt, weil das System es erlaubt, beliebige Daten(-strukturen) als Ergebnis der Qualitätsprüfungen zu persistieren. In der Regel geschieht dies in einem „klassischen“ RDBMS.
Andererseits ist dieser hohe Freiheitsgrad des Tools natürlich gleichzeitig auch eine Herausforderung: es ist zwingend erforderlich vor dem Start der Implementierung ein tragfähiges Datenmodell zu entwickeln, um den größtmöglichen Nutzen aus den Ergebnisdaten der Qualitätsmessungen ziehen zu können.
IDQ ist speziell an dieser Stelle tatsächlich primär ein „Werkzeugkasten“ – „Baupläne“ für ein konkretes „IDQ-Gebäude“ müssen erstellt werden.
Dabei sind die Anforderungen vielfältig, denen ein solches (I)DQ-Datenmodell genügen muss. Vor allen Dingen muss ein solches Datenmodell:
  • beliebige Arten von Quelldaten abbilden können,
  • und die Ergebnisdaten für den operativen, taktischen und strategischen Einsatz auf unterschiedlichen Verdichtungsebenen effizient bereitstellen.

Im oben genannten IDQ-Projekt war das Design eines solchen Datenmodells und DQ-Kennzahlensystems eine der zentralen Aufgaben, mit denen Bayard Consulting betraut wurde.

Stark vereinfacht zeigt die nebenstehende Abbildung die Kerntabellen des Modells:

  • Als „Prüfgegenstand“ werden sog. Datenobjekte (=Datensätze) aus Quellsystemen in das IDQ-System eingelesen und mit Basisinformationen persistiert.
  • Jedes Datenobjekt wird einem Datenobjekttypen zugeordnet, um bspw. für ein Handelsunternehmen Lieferantendatensätze von Produktdatensätze zu unterscheiden. Aber natürlich ist mit diesem generischen Ansatz die Abbildung beliebiger Anwendungsdomänen möglich.
  • Um die Datenqualität zu messen, werden (Validierungs-)Regeln definier
  • Die Regeln werden jeweils genau einem (Daten-)Feld zugeordnet, das sie prüfen.
  • Bei jeder Ausführung der IDQ-Workflows entstehen so zahlreiche Prüfergebnisse, die das binäre Prüfergebnis (Fehler? JA/NEIN) einer Regel für ein spezielles Datenobjekt repräsentieren.
  • Diese granularen Prüfergebnisse werden einerseits direkt als Fehlerlisten ausgespielt, um die einzelnen Datenfehler im operativen Tagesgeschäft in den Quellsystemen zu bereinigen. Zusätzlich werden basierend auf den Prüfergebnissen DQ-Kennzahlen für die Datenobjekte (Datenobjektqualität) sowie für die geprüften Felder (Feldqualität) berechnet, die zur taktischen und strategischen Auswertung auf unterschiedlichen Verdichtungsebenen genutzt werden können. So kann bspw. die Datenqualität eines ganzen Quellsystems, einzelner Datenobjekttypen oder auch einzelner Felder im Zeitverlauf ausgewertet werden, um daraus organisatorische, technische oder prozessuale Maßnahmen abzuleiten.

3. Load – Erzeugung beliebiger Ausgaben mit IDQ

Auf der Ausgabeseite ist IDQ einerseits stark aufgestellt, weil das System es erlaubt, beliebige Daten(-strukturen) als Ergebnis der Qualitätsprüfungen zu persistieren. In der Regel geschieht dies in einem „klassischen“ RDBMS.
Andererseits ist dieser hohe Freiheitsgrad des Tools natürlich gleichzeitig auch eine Herausforderung: es ist zwingend erforderlich vor dem Start der Implementierung ein tragfähiges Datenmodell zu entwickeln, um den größtmöglichen Nutzen aus den Ergebnisdaten der Qualitätsmessungen ziehen zu können.
IDQ ist speziell an dieser Stelle tatsächlich primär ein „Werkzeugkasten“ – „Baupläne“ für ein konkretes „IDQ-Gebäude“ müssen erstellt werden.
Dabei sind die Anforderungen vielfältig, denen ein solches (I)DQ-Datenmodell genügen muss. Vor allen Dingen muss ein solches Datenmodell:
  • beliebige Arten von Quelldaten abbilden können,
  • und die Ergebnisdaten für den operativen, taktischen und strategischen Einsatz auf unterschiedlichen Verdichtungsebenen effizient bereitstellen.
Im oben genannten IDQ-Projekt war das Design eines solchen Datenmodells und DQ-Kennzahlensystems eine der zentralen Aufgaben, mit denen Bayard Consulting betraut wurde.
Stark vereinfacht zeigt die nebenstehende Abbildung die Kerntabellen des Modells:
  • Als „Prüfgegenstand“ werden sog. Datenobjekte (=Datensätze) aus Quellsystemen in das IDQ-System eingelesen und mit Basisinformationen persistiert.
  • Jedes Datenobjekt wird einem Datenobjekttypen zugeordnet, um bspw. für ein Handelsunternehmen Lieferantendatensätze von Produktdatensätze zu unterscheiden. Aber natürlich ist mit diesem generischen Ansatz die Abbildung beliebiger Anwendungsdomänen möglich.
  • Um die Datenqualität zu messen, werden (Validierungs-)Regeln definiert.
  • Die Regeln werden jeweils genau einem (Daten-)Feld zugeordnet, das sie prüfen.
  • Bei jeder Ausführung der IDQ-Workflows entstehen so zahlreiche Prüfergebnisse, die das binäre Prüfergebnis (Fehler? JA/NEIN) einer Regel für ein spezielles Datenobjekt repräsentieren.
  • Diese granularen Prüfergebnisse werden einerseits direkt als Fehlerlisten ausgespielt, um die einzelnen Datenfehler im operativen Tagesgeschäft in den Quellsystemen zu bereinigen. Zusätzlich werden basierend auf den Prüfergebnissen DQ-Kennzahlen für die Datenobjekte (Datenobjektqualität) sowie für die geprüften Felder (Feldqualität) berechnet, die zur taktischen und strategischen Auswertung auf unterschiedlichen Verdichtungsebenen genutzt werden können. So kann bspw. die Datenqualität eines ganzen Quellsystems, einzelner Datenobjekttypen oder auch einzelner Felder im Zeitverlauf ausgewertet werden, um daraus organisatorische, technische oder prozessuale Maßnahmen abzuleiten.

4. (K)ein Frontend – Visualisierung der DQ-Ergebnisse mit BI-Systemen

IDQ ist (abgesehen von der oben kurz erwähnten Analyst-Applikation) primär ein Backend-System. Das bedeutet, dass für die Visualisierung der Ergebnisse der Datenqualitätsprüfungen Dritt-Systeme integriert werden sollten, wenn sich die Endanwender nicht äußerst bescheiden mit Excel-Dateien zufriedengeben.

Prädestiniert dafür sind selbstverständlich sog. Business-Intelligence-Lösungen (BI), die es in großer Zahl am Markt gibt und die in vielen Unternehmen, unabhängig vom Thema „Datenqualität“, bereits im Einsatz sind. Neben bspw. Tableau, Microsoft PowerBI oder Qlik gehört auch Microstrategy zu diesen BI-Tools, mit denen in kurzer Zeit dynamische und flexible Dashboards und Reports erstellt werden können, um die DQ-Ergebnisse bedarfsgerecht und zielgruppen-spezifisch bereitzustellen.

4. (K)ein Frontend – Visualisierung der DQ-Ergebnisse mit BI-Systemen

IDQ ist (abgesehen von der oben kurz erwähnten Analyst-Applikation) primär ein Backend-System. Das bedeutet, dass für die Visualisierung der Ergebnisse der Datenqualitätsprüfungen Dritt-Systeme integriert werden sollten, wenn sich die Endanwender nicht äußerst bescheiden mit Excel-Dateien zufriedengeben.

Prädestiniert dafür sind selbstverständlich sog. Business-Intelligence-Lösungen (BI), die es in großer Zahl am Markt gibt und die in vielen Unternehmen, unabhängig vom Thema „Datenqualität“, bereits im Einsatz sind. Neben bspw. Tableau, Microsoft PowerBI oder Qlik gehört auch Microstrategy zu diesen BI-Tools, mit denen in kurzer Zeit dynamische und flexible Dashboards und Reports erstellt werden können, um die DQ-Ergebnisse bedarfsgerecht und zielgruppen-spezifisch bereitzustellen.

Fazit

Das Enterprise-ETL-System Data Quality von Informatica ist ein funktionsmächtiger Werkzeugkasten, um Transparenz über die tatsächliche Datenqualität in der gesamten IT-Landschaft eines Unternehmens zu gewinnen und existierende Probleme zu identifizieren.
Seine Stärken hat das System insbesondere mit Blick auf seine hervorragenden Integrationseigenschaften einerseits, die den Zugriff auf alle Arten von Daten erlauben, und andererseits hinsichtlich seiner Transformationsbibliothek, die jede Art von Datenprüfung ermöglicht.

Entscheidend ist hierbei allerdings, dass die Anwendung dieses Werkzeugkastens sehr strukturiert, standardisiert und dokumentiert erfolgt, um eine hohe Wiederverwendbarkeit der Komponenten und kurze Entwicklungszyklen zu erreichen.

Zum Funktionsumfang von IDQ gehört ausdrücklich kein benutzerfreundliches Frontend. Deshalb ist die Anbindung eines BI-Systems zur Visualisierung der DQ-Ergebnisse ratsam.

Mit den richtigen Konzepten in puncto Ergebnisdatenmodellierung und DQ-Kennzahlensystem kann mit Data Quality von Informatica eine umfassende Datenbasis  aufgebaut werden: damit schafft IDQ die notwendige Voraussetzung für erfolgreiches Data Quality Management.

Comments are closed.