Drei Basics zum BI Quality Management

Bei Business Intelligence steht das Thema „Qualität“ immer wieder an zentraler Stelle, wird dabei aber auf die unterschiedlichsten Weisen behandelt. Das liegt daran, dass es bisher kein einheitliches Verständnis und damit auch kein standardisiertes Vorgehen zur BI-Qualität gibt.

Dass dies mehr und mehr zum Problem wird, verdeutlicht auch die Umbenennung des aktuellen Gartner Quadrant. Statt Data Quality „Tools“ heißt dieser nun Data Quality „Solutions“. Denn: Während sich viele Hersteller mittlerweile „was mit Qualität“ auf die Fahne schreiben, eint sie meist lediglich ein verschwindend kleiner gemeinsamer Nenner: Probleme zu finden, zu verstehen und zu lösen. Zwar ist dies, das muss man ihnen zugutehalten, nach dem Philosophen Karl Popper immerhin die Quelle allen technischen Fortschritts. Mit Datenqualität per se hat das aber noch nicht zwingend etwas zu tun. In diesem Beitrag werde ich deshalb das Thema BI-Qualität etwas ordnen und strukturieren und nenne das Ganze deshalb „BI Quality Management“. So bleibt noch eine Menge Luft zum „Total BI Quality Management“, wie es schon seit geraumer Zeit in den Ingenieursdisziplinen angewendet und gelehrt wird.

Erstens: Abgrenzung zur Softwareentwicklung

Es ist beinahe ein Reflex, beim Thema BI-Qualität einen Blick auf die Softwareentwicklung zu werfen. Sie ist auf dem Gebiet des Testings extrem weit vorangeschritten. IT-Bücher dazu füllen bereits etliche Regalmeter. Auch in der BI gibt es schon länger den (guten) Trend, vermehrt Prinzipien und Tools aus der Softwareentwicklung einzusetzen und die BI-Landschaften als CI/CD-Umgebungen zu designen. Zahlreiche Testvarianten entlang der Deployment-Pipeline, wie automatische Builds und Tests beim Code einzuchecken, Modularisierung – die Testpyramide gehört heute in der BI vielerorts zum Standardrepertoire.

Dennoch haben wir in der BI mit diesem Ansatz nach wie vor ein bisher unlösbares Problem: Wir befinden uns bereits eine Ebene tiefer und reden über „Testing“ statt über „Qualität“. Für viele operative Softwareanwendungen mag diese Vorgehensweise wunderbar funktionieren. Wenn die Tests nahezu alles abdecken, stimmt auch – in den meisten Fällen – die Qualität. Das funktioniert so nur leider nicht für die BI. Aber woran liegt das?

In der BI haben wir es mit Datenströmen zu tun, die oftmals eine schier riesige Variation an möglichen Input- und Outputvektoren zulassen, mit zahlreichen Transformationen für die Business-Logik dazwischen. Das Testen mit vordefinierten Daten während der Entwicklung kann dies mengenmäßig nicht leisten – mit dem reinen Abarbeiten der klassischen Testpyramide kommt die BI an ihre Grenzen. Dass das auch in der Softwareentwicklung bereits Thema ist und dort als „Pipeline Debt“ diskutiert wird, zeigt beispielsweise dieser Blogbeitrag.

Ausbalancierung des Quality Managements

Für mich ergibt sich daraus erstens, dass der Qualitätskontrolle im Produktivsystem eine sehr hohe Bedeutung zukommt, womit wir beim Thema Validieren, Monitoren und Balancing sind.

Zweitens besteht leider ein ständiges Dilemma in Bezug auf die Testdaten: Daten aus der Produktion dürfen (aufgrund von Datenschutz) und/oder können (aufgrund ihrer Masse) nicht verwendet werden. Ein automatisches Ableiten eines anonymisierten Subsets der Daten ist deshalb extrem aufwändig – wenn auch je nach Situation dennoch möglich. Grundsätzlich bleibt das Problem beim Testen anhand von produktionsnahen/-abgeleiteten Daten, dass ich als Entwickler oder Product Owner nicht sicher sein kann, ob diese Daten alle Anforderungen abdecken. Für ein Test Driven Development (TDD) und aussagekräftige User Acceptance Tests (UAT) sind daher detaillierte Testdaten elementar.

Abbildung 1: Produkqualität vs. Testing

Zweitens: Ordnen

Der nächste wichtige Punkt, um beim Thema Qualität Ordnung zu schaffen, ist die Differenzierung hinsichtlich Produktion und Entwicklung.

Produktion: im Takt der Ladezyklen

In der Produktion geht es im Wesentlichen um beobachtendes Validieren und Monitoren der zuvor implementierten Prozesse mit ihrer Businesslogik auf der gesamten produktiven Datenmenge. Sprich: Zeitreihen im Takt der Ladezyklen. Oft wird auch das Validieren von Quelldaten auf Feldebene (z. B. Adresse und E-Mail-Adresse) aufgeführt und von vielen Tools angeboten, was meiner Meinung nach aber eine ganz normale Cleansing-Aufgabe ist und teils schon direkt beim Laden implementiert wird (ELT/ETL). Separate Tools wie das „Great Expectations“ Package in Python machen dies ebenfalls möglich.

Beim Balancing geht es darum, die Vollständigkeit an definierten Lade- oder Prozessstellen zu überprüfen und die Vollständigkeit der Datenbasis entlang der gesamten Data-Lineage sicherzustellen.

Grundsätzlich empfehle ich, diese übergeordneten Qualitätstests auf der Produktionsumgebung in einem separaten Tool zu lösen statt beispielsweise im ELT-Tool selbst (natürlich soll das ETL-Tool seinen Teil der Datenvalidierung übernehmen). Das hat den Vorteil, dass bei einer Erweiterung oder Migration die existierenden Qualitätstests bestehen bleiben und unabhängig von den eingesetzten Tools weiterlaufen können.

Für die Monitoringlogik reichen dabei meist ein paar einfache SQLs. Zum Reporten der Ergebnisse bieten sich Dashboard-Tools wie z. B. Grafana an. Wichtiger ist es mir persönlich allerdings, den Überblick über die Testmetriken behalten und Toleranzbereiche definieren zu können. Da es hier bislang keine BI-spezifische Lösung gibt, verwenden wir bei b.telligent unser eigens dazu entwickeltes DQM-Tool, das diese Aufgaben übernimmt. Mehr dazu findest Du in unserem Whitepaper „Datenqualität erhöhen“, das Du kostenfrei in unserer b.ibliothek downloaden kannst.

Entwicklung: Das Problem sind immer die Testdaten

In der Entwicklung hingegen geht es um das kontinuierliche, wiederholte Testen von kleinen Einzelteilen (Unit-Test) bis hin zum großen Ganzen (Integrations-, Systemtest). Hier hilft es, wenn das BI-System so modular aufgebaut ist, dass es als CI/CD-Pipeline betrieben werden kann, und das Testen darin möglichst automatisiert abläuft. Eine sehr gute Einführung für die BI gibt es dazu im Webinar „Qualitätsoffensive DWH-Entwicklung“ meiner Kollegen Beyer und Schuster (ebenso kostenlos abrufbar in der b.telligent-Webinarthek).

Die Aufteilung der Qualitätsschritte findest Du in der erweiterten BI-Testpyramide:

Abbildung 2: BI-Testpyramide

Drittens: Testen mit Daten

Daran führt kein Weg vorbei: Data-Lineage

Die Herausforderung in der BI ist, dass wir meistens sehr viele Testdaten brauchen, um einen durchgängigen Prozess abbilden zu können. Da viele Daten aber in ihrer Businesslogik zusammenhängen, müssten für eine kleine Änderung oft eine Vielzahl an Testdaten angepasst werden. Das ist in den meisten Fällen extrem aufwändig und führt dazu, dass ein vollständiges Testen mit konstruierten Daten unverhältnismäßig teuer wird. Wenn dann noch die Data-Lineage nicht automatisiert vorliegt, sondern jedes Mal mühsam händisch nachvollzogen werden muss, steigen die Kosten für Aufbau und Wartung von Testdaten ins Unermessliche. Das Resultat sind schwach abdeckende Testdaten und zahlreiche ungetestete Codeteile.

Pipeline Debt

In modernen Entwicklungsumgebungen deployt der einzelne Entwickler meist einen bestimmten Releasestand in eine virtuelle Umgebung, entwickelt und testet dort und checkt den Code schließlich im Repository für das nächste Release wieder ein. Hier liegt meist der Hase im Pfeffer: Auf welchen Daten kann in einer frisch aufgesetzten Umgebung getestet werden? Wie kommen die da hinein?

Das Dilemma mit den Testdaten ist, dass wir bei produktionsabgeleiteten Daten nicht wissen, welche Fälle tatsächlich abgedeckt sind. Synthetische Testdaten hingegen decken notorisch zu wenige Fälle ab und haben eine schlechte Änderungselastizität.

Meistens kommt es dann zu einem schmerzlichen Kompromiss: Auf den Entwicklungsumgebungen werden häufig nur sehr kleine Datensets für Unit- oder Komponenten-Tests verwendet, die nur einen isolierten Teil  der vorhandenen Prozessschritte abdecken. Anschließend wird in einer Vorproduktions-Umgebung mit Produktionsdaten (anonymisierte oder produktionsähnliche Daten) weiter getestet. Die fehlende Durchgängigkeit dieser Teststrecke für den Entwickler ist die sogenannte Pipeline Debt.

Testdatenmanagement

Was bisher fehlt, ist ein mächtiges Testdatenmanagementsystem, das auf die besonderen Bedürfnisse der BI zugeschnitten ist. Dabei sehe ich diese Funktionen als vorrangig an:

• Definition der Testdaten entlang der Data-Lineage
• Fachliche Beschreibung und Kommentierungsmöglichkeiten der einzelnen Cases
• Clustern von Testdaten in Untergruppen, um spezielle Anwendungsfälle zu simulieren
• Historisierung der Testdaten, um diese
• zugehörigen Releaseversionen zuordnen zu können

Last, but not least: Testcase Engineering

Was auf keinen Fall fehlen darf, ist die Definition der Testcases gemeinsam mit dem Fachbereich. Dies führt für beide Seiten – BI-Entwicklung und Fachbereich – zu einem besseren Verständnis und so schon ab der ersten Zeile Code zu wesentlich höherer Qualität. Aus der Praxis kann ich dazu ein Vorgehen wie die Gherkin-Szenarios mit „given – when – then“ empfehlen, die zwar in der Softwareentwicklung weit verbreitet sind, aber leider nicht zu den Daten und Strukturen in der BI passen.

Fazit

Wenn es um die Datenqualität in der BI geht, ist es elementar, sowohl das Produktivsystem als auch den Entwicklungsprozess als Einheit zu begreifen. Das eine hilft nichts, wenn das andere vernachlässigt wird. In der Produktion sollte ein unabhängiges Tool für Monitoring und Balancing eingesetzt werden. Für die Entwicklung sollte das BI-System am besten so aufgebaut sein, dass die Methoden aus der modernen Softwareentwicklung angewendet werden können.

Für konstruierte Testdaten gibt es leider keine universelle, automatisierte Lösung, und die Grenze, an der der Aufwand für Pflege und Erweiterungen die vorhandenen Ressourcen übersteigt, kann schnell erreicht sein. Eine gute Lösung zum BI-Testdatenmanagement, das den Ressourceneinsatz minimiert, gibt es aktuell am Markt leider nicht. So bleibt nur, eine eigene Lösung aufzubauen, die einen guten Mittelweg zwischen Testbedarf, Testautomatisierung und Kosten findet und dabei die Testpyramide möglichst hoch erklimmt.

Du suchst einen starken Partner, der Dich dabei unterstützt? Dann sprich mich gerne an!