heise+ | Das Data-Governance-Drama vor dem Teststart und wie es sich auflösen lässt
Es ist immer dieselbe Geschichte: Erster Akt. Die Datenarchitektur entsteht sorgfältig. Teams modellieren Produktionsdaten, schneiden sie in fachliche Domänen oder führen sie in zentralen Strukturen zusammen. Sie hinterlegen Budget dafür und benennen Verantwortliche. In keiner dieser Planungen tauchen Testdaten als eigenständiges Anliegen auf. Sie sind kein Thema, weil sie niemandem gehören.
- Testdatenprobleme resultieren oft aus fehlender Zuständigkeit, nicht aus Kommunikationsmängeln.
- Der blinde Fleck der Datenarchitektur: Testdaten haben keinen klaren Eigentümer.
- Ein strukturiertes Verantwortungsmodell auf drei Ebenen kann durch frühzeitige Einbindung in den Architekturentwurf Abhilfe schaffen.
Zweiter Akt. Kurz vor Teststart fehlen die Testdaten. Quantitativ, weil zu wenige Datensätze vorliegen, um realistische Last zu erzeugen, und qualitativ, weil die vorhandenen Daten die fachlichen Konstellationen nicht abbilden. Die IT verweist auf die Fachabteilung, die die Anforderungen kenne. Die Fachabteilung verweist auf die IT, die die Systeme betreibe, oder gerne auf den angeblich allwissenden Architekten. Die Projektleitung sieht auf den Terminplan und wartet.
Dritter Akt. Das performative Fingerzeigen beginnt, im Projektjargon: „der Eiertanz“. In den Statusberichten erscheint Woche für Woche die Zeile „Testdaten in Klärung“, ohne dass sich an der Klärung etwas ändert. Das Verantwortungsvakuum verfestigt sich mit jeder Eskalation, die nicht stattfindet.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.