Der Datenbesitzer, den niemand zugewiesen hat

Das Versagen, das wie ein Ingenieurproblem aussieht

Das System ist gebaut, die Pipeline läuft und die Bewertung ist akzeptabel. Dann driftet der Korpus ab: Ein Quellsystem ändert ein Feld, ein Ordner wird neu organisiert, ein Dokumentensatz wird nicht mehr aktualisiert, weil die Person, die ihn gepflegt hat, das Team gewechselt hat. Die Antwortqualität verschlechtert sich über Wochen hinweg, und das Ingenieurteam kann es nicht beheben, weil die Lösung kein Code ist.

Nothing in dieser Geschichte ist schwierig. Es ist einfach nicht zugeordnet.

Warum Eigentümerschaft die eigentliche Abhängigkeit ist

Ein AI-Feature, das auf Unternehmensdaten aufbaut, hat eine Abhängigkeit von Personen außerhalb des Build-Teams, und diese Abhängigkeiten verhalten sich anders als Software-Abhängigkeiten. Sie sind nicht versioniert, sie scheitern nicht laut und sie ändern sich, wenn sich eine Organisation ändert. Drei davon sind für den größten Teil des Zeitplansrisikos verantwortlich.

Aktualisierung. Wer ist verantwortlich dafür, dass der Korpus den aktuellen Zustand des Unternehmens widerspiegelt, in welchem Rhythmus und wie würde jemand bemerken, wenn er aufhört?

Schema. Welche Felder existieren, welche sind veraltet und wer wird informiert, wenn sich die Bedeutung eines Feldes ändert. Ein umbenanntes Feld ist ein stilles Abrufversagen, kein Absturz.

Berechtigung. Die Zuordnung zwischen dem Berechtigungsmodell des Quellsystems und der Zugriffssteuerungsliste des Index muss von jemandem mit Autorität über das Quellsystem gepflegt werden. Das ist selten ein Ingenieur.

Es explizit machen

• Eine Person, nicht ein Team, für jede Datenquelle benennen und eine Ersatzperson benennen. Unbesetzte Eigentümerschaft ist nicht zugeordnet.
• Den Aktualisierungsrhythmus in den Projektplan als Abhängigkeit mit Datum schreiben, sodass eine gestoppte Aktualisierung an der gleichen Stelle wie eine gestoppte API-Integration erscheint.
• Einen Alerting-Kanal für Schema-Änderungen vor dem Beginn der Ingestion vereinbaren, nicht nach dem ersten stilen Versagen.
• Die Korpus-Frische auf dem gleichen Dashboard wie Latenz und Kosten anzeigen, sodass Qualitätsabbau sichtbar wird, bevor Benutzer ihn als Qualitätsproblem melden.
• Die Eigentümerschaft bei jeder Reorganisation überprüfen. Eigentümerschaftsvereinbarungen überleben nur so lange, wie die Personen, die sie unterzeichnet haben.

Warum es sich lohnt, die Papiere zu machen

Zwei Dokumente ändern das Ergebnis: Eine einseitige Datenflussbeschreibung, die jeden Quell, seinen Eigentümer und seinen Rhythmus benennt, und ein Risikoregister, das auflistet, was das System falsch machen kann, mit der Abmilderung für jedes. Beide sind langweilig, beide dauern einen Nachmittag und beide wandeln eine Klasse von Problemen, die erst im vierten Monat entdeckt worden wären, in eine Reihe von Entscheidungen um, die bereits in der ersten Woche getroffen werden können.