Data Architect — Einstieg in die Rolle

Begriffe vor dem Lesen

• Accountable — die Rolle, die eine Entscheidung verbindlich verantwortet.
• verantwortliche Person — fachlich verantwortliche Rolle für Zweck, Bedeutung, Risiko oder Nutzung eines Datenprodukts.
• Steward — operative Rolle, die Definitionen, Qualitätserwartungen und Nachweise pflegt.
• technischer Betreiber — technische Rolle, die Plattform, Zugriff, Laufzeit und Umsetzung betreibt.
• Nutzer — Person oder Team, das Daten für eine Entscheidung nutzt und Rückmeldung geben muss.

Ausgangslage

Viele Governance-Programme scheitern nicht daran, dass niemand Verantwortung will. Sie scheitern daran, dass eine Rolle zu viel bedeuten soll. Dann entscheidet eine Person über Zweck, Definition, Zugriff, Qualität, Betrieb und Produkt-Roadmap zugleich. Das wirkt schnell, erzeugt aber Reibung: Fachbereiche fühlen sich übergangen, technische Teams tragen fachliche Risiken, und Datenschutz oder Compliance kommen zu spät in die Entscheidung.

Diese Einstiegsstory erklärt die Rolle Data Architect so, dass neue Leserinnen und Leser verstehen, wofür sie gebraucht wird, wo ihre Grenze liegt und mit wem sie zusammenarbeitet.

Wofür diese Rolle da ist

Data Architect sorgt dafür, dass Governance im Alltag handhabbar bleibt. Der Schwerpunkt liegt auf Grain, Schnittstellen, Lineage, Architekturgrenzen und Änderbarkeit. Die Rolle ersetzt keine anderen Rollen, sondern macht ihre Entscheidung sichtbar: Wer entscheidet? Wer liefert Expertise? Wer setzt technisch um? Wer nutzt das Ergebnis?

Was diese Rolle nicht lösen sollte

Die Rolle darf nicht zum Sammelbecken für alles werden, was unklar ist. Wenn Zweck, Zugriff, technische Umsetzung und fachliche Definition in derselben Person verschwinden, entsteht genau die politische Reibung, die Governance eigentlich beruhigen soll.

Zusammenarbeit

Typische Partner sind: Owner, Steward, Custodian, Data Engineering und Plattformteam. Gute Zusammenarbeit heißt: Der Fachbereich behält Verantwortung, Expertinnen und Experten beraten, technische Teams setzen kontrolliert um, und Consumer melden Lücken statt eigene Schattenlogik aufzubauen.

Einstieg in die Serie

Diese Serie ist der kurze Einstieg in die Rolle. Danach passen je nach Situation die fachlichen Landschaften, die Foundations zu Verantwortung, Quality und Metadata sowie die Vertriebsserien, wenn Governance als Dienstleistung angeboten werden soll.

Konkretes Beispiel

Eine Rolle wird erst verständlich, wenn sie an einer Entscheidung sichtbar wird. Ein Dashboard zeigt eine Zahl, ein Team zweifelt an der Definition, ein technisches Konto hat zu viele Rechte oder ein Datenprodukt soll für einen neuen Zweck genutzt werden. Dann reicht ein Rollenname nicht aus. Die Organisation muss wissen, wer entscheidet, wer berät, wer umsetzt und wer das Ergebnis nutzt.

Für Data Architect — Einstieg in die Rolle heißt das: Die Rolle braucht einen klaren Scope. Sie darf nicht alles besitzen, aber sie darf auch nicht nur symbolisch genannt werden. Gute Governance macht sichtbar, an welcher Stelle diese Rolle verbindlich sprechen kann und wo andere Rollen übernehmen müssen.

Woran man die Rolle erkennt

• Die Rolle kann eine konkrete Entscheidung benennen, nicht nur eine Zuständigkeit.
• Die Grenze zu Owner, Steward, technischer Betreiber, Product Owner oder Nutzer ist erklärbar.
• Beratende Expertinnen und Experten werden eingebunden, ohne fachliche Verantwortung zu verschieben.
• Nach der Entscheidung bleibt ein Nachweis, der später auffindbar ist.

Mini-Check für die nächste Story

Welche Entscheidung trifft diese Rolle? Welche Entscheidung trifft sie ausdrücklich nicht? Wer muss vorher beraten? Wo bleibt der Nachweis?