Bei der Entwicklung von IT-Systemen, so auch Data Warehouse-Lösungen, werden manchmal Kompromisse eingegangen, die nicht den Architektur-Vorgaben oder Design Pattern entsprechen. Diese bewussten oder unbewussten Abweichungen werden als technische Schuld (engl. «technical debt») bezeichnet.
Im Gegensatz zu Fehlern läuft das System zwar korrekt. Wie bei allen Schulden entstehen dadurch Zinsen. Jedoch wurden Abhängigkeiten geschaffen, die einen späteren Ausbau erschweren oder zu einem aufwändigeren Betrieb führen.
Diese Abhängigkeiten werden als technische Schulden bezeichnet. Schulden müssen irgendwann mit Zinsen zurückbezahlt werden. Zinsen sind zukünftige Mehraufwände. Werden diese Schulden nicht vermieden oder schnellstens eliminiert, ist irgendwann eine effiziente Weiterentwicklung der DWH-Plattform nicht mehr möglich.
Martin Fowler, ein bekannter englischer Autor und Dozent zu Softwarearchitektur, unterscheidet folgende Arten von technischen Schulden:
| Rücksichtslos | Umsichtig | |
| Vorsätzlich, bewusst | „Wir haben keine Zeit für das Design.“ | „Wir müssen jetzt ausliefern und (später) mit den Konsequenzen umgehen.“ |
| Ungewollt, ohne Absicht | „Was ist ein Schichtenmodell?“ | „Jetzt wissen wir, wie wir es hätten tun sollen.“ |
Bewusste Schulden entstehen häufig unter Zeitdruck. Denn der angestrebte Meilenstein muss unbedingt erreicht werden. Unwissentliche Schulden entstehen eher durch unpräzise Anforderungen, die falsch interpretiert und umgesetzt werden. Ein weiterer Grund ist die Unkenntnis von Design Pattern.
Was sind Ursachen von technischen Schulden?
Leider ist man sich der Auswirkungen von technischen Schulden lange nicht bewusst, manchmal werden sie nicht gleich erkannt. Die Effektivität nimmt langsam ab. Es dauert immer länger, bis Erweiterungen umgesetzt werden können.
Technical Debts sind öfters auch die Ursache für spätere Fehler, was zu Korrekturen und einer weiteren Ressourcenbindung führt. Das heißt, dass die Liste nicht erfüllter Changes immer länger wird. Die Kosten für die Umsetzung kleinerer Anforderungen steigen. Die Unzufriedenheit auf Business-Seite wächst und das Vertrauen in das Data Warehouse beginnt zu erodieren. Letztendlich kann es dazu führen, dass das System gestoppt wird.
Doch was sind die eigentlichen Ursachen? Es gibt mehrere Hauptgründe:
- Architekturprinzipien werden nicht eingehalten, beispielsweise das Abweichen vom Schichtenmodell.
- Mangelhafte technische Infrastruktur, wie das Erstellen und Pflegen von Testfällen in Excel.
- Fehlende Entwicklungsstandards und Design Pattern.
- Unpräzise Business-Anforderungen, die falsch verstanden und umgesetzt werden. Nachträglich werden sie durch Workarounds korrigiert.
- Zeitdruck: Um Lieferergebnisse rechtzeitig bereit zu stellen, werden «Abkürzungen» genommen. Das heißt, es kommt bewusst zu Verletzungen der Architektur- und Designvorgaben.
- Ständig wechselnde Anforderungen oder zusätzliche Anforderungen (moving targets). Wenn dabei nicht jeweils der Projektplan angepasst wird, ist die Erfüllung nur noch mit Kompromissen möglich.
Dies sind nur einige Gründe. In vielen Fällen kommt es noch zu einer Vermischung mit sogenannten Anti-Pattern. Dies sind ungünstige oder schädliche Muster in der Lösungsentwicklung, die in diesem Artikel nicht weiter behandelt werden.
- Sie erhalten eine Zusammenfassung der Umfrageergebnisse
- Sie stellen sicher, dass Ihre Erfahrungen in die Auswertung einfließen
- Sie nehmen an der Verlosung eines von zehn Amazon-Gutscheinen im Wert von 50 € teil.
Was sind Technical Debts in einem Data Warehouse?
In der Praxis habe ich bereits mehrere Beispiele von Technical Debts gesehen, die zu einer kompletten Ineffizienz führten. In wenigen Fällen führte dies dazu, dass Data Warehouses gestoppt wurden. Dazu ein paar Beispiele von Technical Debts aus meiner Praxis:
Verwendung des Data Warehouses als Data Hub
Die meisten Data Warehouses verfügen über eine effiziente Datentransformation in Ladeprozessen, in Form von ETL-Tools. Jedoch fehlt in mehreren IT-Infrastrukturen eine zentrale Lösung zum Automatisieren von Datenflüssen und für das Schnittstellen-Management. Dadurch wird immer wieder die ETL-Infrastruktur eines Data Warehouses als Data Hub zwischen operativen Systemen missbraucht.
Das bedeutet, dass das Data-Warehousing-Team nun auch für operative Datenflüsse verantwortlich wird. Diese kriegen jeweils die höhere Priorität. Somit fehlen Ressourcen für den Betrieb und die Weiterentwicklung des Data Warehouses.
Das Data Warehouse oder das BI Tool wird zur Datenpumpe
Anstelle von Analysen ab der «offiziellen» Infrastruktur, werden die Tools nur für Datenextrakte verwendet. Üblicherweise werden nur verschiedene Queries gebaut und anschließend nach Excel exportiert, anstelle von Dashboards und Analysen. Das eigentliche Analysetool ist dann Excel.
In einem anderen Fall wurde das Data Warehouse offiziell zum Befüllen von verschiedenen individuellen Analyselösungen in den Fachbereichen verwendet. Dies waren Schatten-Data-Warehouses im eigentlichen Sinne und es gab über 60 davon. Das Data-Warehousing-Team war in der Pflicht entsprechende Schnittstellen zu bauen und zu betreiben. Obwohl diese Aufgaben nichts mit dem eigentlichen Zweck des Data Warehouses zu tun hatten, wurden dafür die gesamten Ressourcen absorbiert. Das Data-Warehousing-Team beklagte sich sogar, dass sie nicht einmal genügend Kapazität hatten um diese abweichenden Aufgaben zu erfüllen. In diesem Extremfall wurde das Data Warehouse tatsächlich gestoppt und mit einer Neuentwicklung begonnen. Auch zukünftig waren individuelle Lösungen erlaubt, jedoch lag die Erstellung in der Pflicht der Fachbereiche.
Verwendung des Data Warehouses als Archiv
Zur Einhaltung der rechtlichen Aufbewahrungsfristen werden Daten länger in einem Data Warehouse gespeichert als notwendig. In einem Fall sollte ein Altsystem abgelöst werden, dessen Daten bisher nicht im Data Warehouse gespeichert wurden. Das Data Warehouse hatte bisher nur den Zweck, operative Auswertungen für einen rückwirkenden Zeitraum von maximal einem Jahr zu erstellen. Da kein Datenarchiv existiert, entstand die Idee die Detaildaten des Altsystems für einen Zeitraum von mehr als 15 Jahren ins Data Warehouse zu speichern. Dadurch würde das Datenmodell um das zehnfache aufgebläht, obwohl die Daten für keine Analysen benötigt werden. Trotz anderweitiger Empfehlung wurde dies leider umgesetzt. Als Konsequenz ging die Performance deutlich herunter und Entwicklungsaufwände nahmen zu, weil auch das Datenmodell der archivierten und nicht genutzten Daten mitgepflegt werden musste.
Sourcing über Altsysteme
Bei der Ablösung eines alten Data Warehouses besteht häufig ein großer Zeitdruck, das neue System rechtzeitig bereitzustellen. Daher ist es naheliegend, bereits korrekte Ladestrecken zu nutzen und aus dem alten Data Warehouse zu übernehmen, anstatt neue Sourcings zu bauen. Dies wird damit begründet, dass die neuen Ladestrecken später gebaut werden. In der Praxis habe ich diese Begründung schon mehrfach gehört, jedoch habe ich noch nie erlebt, dass später die Ladestrecken neu gebaut wurden. Somit wurde eine Abhängigkeit zum Altsystem geschaffen, die zu einem unbefristeten Weiterbetrieb beider Systeme zwingt.
Abweichungen vom Schichtenmodell
Die Daten werden jeweils nur vom Datenakquisitions-Layer, also vom Quellsystem in eine höhere Schicht transportiert. Leider wird immer wieder davon abgewichen und es gibt bidirektionale Datenflüsse zwischen den Schichten oder zwischen operativen Systemen und dem Data Warehouse.
Das Schichtmodell hat einen bestimmten, definierten Zweck. Dies sind nur wenige Grundsätze: Daten werden nur über die unterste, die Data-Akquisition-Schicht geladen und geprüft. Es gibt keine direkte Datenintegration in eine andere Schicht. Daten werden immer von unten nach oben transferiert und nie in die Gegenrichtung. Datenextrakte sind nur aus einer definierten Schicht erlaubt für regulatorische Bereitstellung und nie für operative Systeme. Der Userzugriff ist limitiert auf die oberste oder die obersten Schichten. Ansonsten müssen für alle Schichten Berechtigungsmodelle erstellt und verwaltet werden. Das gleiche gilt für ein Business-Glossar.
Das Fehlen oder Nichteinhalten von Entwicklungsgrundsätzen
Dazu gibt es die unterschiedlichsten Formen von Abweichungen, wie das Nichteinhalten von Namenskonventionen oder Schritten in der Datentransformation. Ich habe auch schon gesehen, dass Testsysteme teilweise für produktive Analysen verwendet wurden. Das heißt, dass es im eigentlichen Sinn zwei produktive Systeme gibt: ein offizielles und ein inoffizielles. Somit waren nur noch eingeschränkt Tests möglich, was dazu führte, dass nicht alle Fehler entdeckt wurden und es regelmäßig zu Produktionsstörungen nach Release-Terminen kam.
Unvollständige Infrastruktur
Es gibt zwar Tools für die Datenintegration, -speicherung und -analyse. Jedoch kein vollständiges Toolset für die Entwicklung und Verwaltung der Systeme, wie ein Repository für Anforderungen, Code-Repositories und Versionierung, Testfälle, geschweige denn eine automatisierte Regressionstest-Library.
Die Entwickler behelfen sich mit manuellen organisatorischen Lösungen, wie Ordnerstrukturen auf einem Fileserver und diversen Excel-Listen. Unter Zeitdruck kommt es dabei immer wieder zu Fehlern, weil nicht alles nachgeführt wurde.
Ungenügendes Patch- und Release-Management
Business-Anforderungen werden häufig höher priorisiert als technische Anforderungen. Das bedeutet, dass häufig keine Zeit mehr besteht, die neusten Patches einzuspielen und Sicherheitslücken zu schließen. Vereinzelt geschieht dies auch aus einem falschen Verständnis von Stabilität.
So hat mir schon einmal ein BI-Manager voller Stolz erklärt, dass sie seit knapp einem Jahr keinen einzigen Patch mehr eingespielt haben, nach dem irrigen Prinzip «never change a running system».
In einer anderen Situation war der Kunde mit seiner Dashboard-Lösung nicht mehr zufrieden und wollte ein neues Tool evaluieren. Es hat sich dann herausgestellt, dass der Hersteller bereits zwei Release-Nummern weiter war, also nicht mehr Release 6.x, sondern 8.x. Der Kunde musste nur noch die neuen Releases einspielen, für die er mit seiner jährlichen Maintenance-Gebühr berechtigt war, zu einem Bruchteil der Gesamtkosten, wie eine Neubeschaffung.
Datenpflege oder Datenbereinigung im Data Warehouse
Nicht erlaubt ist die transaktionale Datenpflege in einem Data Warehouse, insbesondere nicht von Stammdaten. Eine Fehlerfassung kann die Richtigkeit sämtlicher Auswertungen zerstören. Datenpflege hat in separaten Applikationen zu erfolgen, die über den normalen Sourcing Prozess ins Data Warehouse geladen werden.
Dasselbe gilt für die Bereinigung von Datenqualitätsproblemen. Cleansing ist zwar ein üblicher Vorgehensschritt beim Laden von Daten. Jedoch ist es nicht Zweck eines Data Warehouses, Daten zu bereinigen und anschliessend korrigiert ins operative System zurückzuschreiben.
Schon gar nicht erlaubt sind Datenmanipulationen direkt in den Tabellen über ein Administratoren-Tool. Der Audittrail wird dadurch unterbrochen.
Feature coding
Manchmal werden Anforderungen formuliert, die nicht zu den Standardfunktionen eines eingesetzten Tools gehören. Nun werden Zusatzfunktionen mittels Macros, Stored Procedures oder sonstige Programmierfunktionen nachgebaut. Nur selten sind diese Codes dokumentiert.
Regelmäßig führen genau diese selbstprogrammierten Erweiterungen zu Schwierigkeiten bei einem Major-Release-Wechsel der eingesetzten Software. Die meisten dieser Features, die ich gesehen habe, wurden einzig mit dem Zweck gebaut, marginale Layout-Anpassungen an Reports oder Dashboards vorzunehmen. Ist es das wirklich wert?
Wie können Technical Debt’s vermieden werden?
Wie schon einleitend beschrieben, entstehen viele dieser Probleme aus Zeitdruck oder Unwissenheit. Die Vermeidung und Eliminierung von Technical Debts beginnt meistens bei einer schriftlich dokumentierten Governance wie der Beschreibung des Entwicklungsprozesses, einer definierten Architektur, Entwicklungsgrundsätzen und Design Patterns, Betriebshandbücher, usw.
Das Definieren von Handlungsanweisungen allein genügt nicht. Damit die Regeln gelebt und eingehalten werden sind Schulungen notwendig, beispielsweise für neueintretende Mitarbeiter. Weiter benötigt es eine regelmäßige Überprüfung der Regeleinhaltung, wie Audits.
Ebenfalls hilfreich sind integrierte Tools, um einen möglichst hohen Automatisierungsgrad zu erreichen. Tools verhindern auch die Regelabweichung. Fachliche Anforderungen werden zu technischen Komponenten mit dazugehörenden Testfällen. Wird eine integrierte Toollandschaft gewählt, können Mehrfacherfassungen vermieden werden. Bei unabhängigen Tools besteht zusätzlich das Risiko, dass darin ein unterschiedlicher Stand abgebildet ist, weil noch nicht alle Informationen nachgeführt sind.
BARC kann Sie bei der Identifikation und schrittweisen Eliminierung bestehender Technical Debts unterstützen. Unsere Beratungsleistungen umfassen auch den Entwurf einer zweckmäßigen Systemarchitektur, einer Governance, beispielsweise eines «Book of Standards» oder Evaluierung der benötigten Tools. Kontaktieren Sie uns und vereinbaren Sie ein erstes unverbindliches Gespräch.
