Data Architect — Zusammenarbeit und Evidence

Einstieg

Architektur wird nur wirksam, wenn sie mit Fachbereichen, Betrieb und Umsetzung zusammenarbeitet. Ein schönes Zielbild hilft wenig, wenn es nicht zeigt, wer eine Entscheidung braucht, welche Systeme betroffen sind und wie eine Änderung später geprüft wird.

Diese Story zeigt, wie Architekturarbeit nachvollziehbar bleibt.

Begriffe vor dem Lesen

• Architecture Decision Record — kurzer Nachweis einer Architekturentscheidung mit Kontext, Optionen, Entscheidung und Folgen.
• Stakeholder — Person oder Team, das von einer Architekturentscheidung betroffen ist.
• Abhängigkeit — anderes System, Team, Datenprodukt oder Entscheidung, von dem die Umsetzung abhängt.
• Migrationspfad — geplanter Weg von einer heutigen Lösung zu einer besseren Zielarchitektur.
• Reviewdatum — Zeitpunkt, an dem eine Architekturentscheidung erneut geprüft wird.

Einfaches Schaubild

Wer beteiligt ist

• Data Owner: entscheidet fachliche Bedeutung, Nutzung und Risiko.
• Data Steward: liefert Definitionen, Qualitätsregeln und Katalogkontext.
• Data Product Owner: priorisiert Produktnutzen und Release.
• Custodian / Plattformteam: bewertet Betrieb, Zugriff, Kosten und Stabilität.
• Data Engineering: baut Pipelines, Modelle, Tests und Schnittstellen.
• Security, Datenschutz, Legal: beraten, wenn Schutzbedarf, Rechte oder Pflichten betroffen sind.
• Consumer: erklären, welche Nutzung durch eine Architekturentscheidung möglich oder schwierig wird.

Gute Architektur-Evidence

Ein guter Nachweis muss nicht lang sein. Er muss später erklären können:

• Welche Frage wurde entschieden?
• Welche Optionen wurden betrachtet?
• Warum wurde diese Option gewählt?
• Welche Folgen hat sie für andere Teams?
• Welche Risiken bleiben?
• Wer muss umsetzen oder beraten?
• Wann wird die Entscheidung überprüft?

Mini-Fall

Ein Bereich möchte Kundendaten direkt aus dem operativen System in ein BI-Tool laden, weil der Report dringend gebraucht wird. Das kann kurzfristig helfen, erzeugt aber eventuell doppelte Logik, unklare Zugriffe und schwer nachvollziehbare Zahlen.

Der Architect prüft Alternativen: direkter Übergang mit Ablaufdatum, Nutzung eines bestehenden Datenprodukts oder Aufbau einer neuen Schnittstelle. Owner und Steward klären Bedeutung und Einschränkungen. Custodian und Engineering bewerten Betrieb. Die Entscheidung wird dokumentiert, damit aus der schnellen Lösung kein dauerhafter Schattenpfad wird.

Erster Umsetzungsschnitt

1. Wähle eine aktuelle Schnittstellen- oder Modellentscheidung.
2. Schreibe die Frage in einem Satz.
3. Liste zwei realistische Optionen mit Folgen.
4. Benenne betroffene Datenprodukte, Teams und Risiken.
5. Lege Entscheidung, Reviewdatum und Nachweisort fest.

Weiterlesen

• Data Product Owner — Einstieg in die Rolle
• Data Contracts Operating
• Governance Evidence Register