Scenarios 19–23
Scenario 19 — No Data Architects
Situation: DMO needs architecture alignment, but the company has no dedicated Data Architects. - Primary problem: alternative DMO–EA interface required. - Supporting: Data Architecture; Data Governance. - Roles: DMO lead, EA lead, ARB/governance. - Best response: coordinate via Data Governance, ARB, or periodic leader meetings; formalize if ad-hoc coordination becomes difficult. - Weaker response: absence of a Data Architect does not remove architecture governance. - Changed fact: Data Architects are hired → they can directly represent architecture in governance/ARB discussions. Source: pp. 535–536.
Scenario 20 — Global standards drift
Situation: regional teams use different definitions, training, and monitoring; each succeeds locally but enterprise reports conflict. - Primary problem: global coordination/standardization/accountability gap. - Supporting: Data Governance; Metadata; Data Quality. - Roles: enterprise DMO/CDO, regional DMOs, stewards. - Best response: align standards, processes, accountability, training, monitoring, and economies of scale while permitting justified regional variation. - Weaker response: eliminate all regional autonomy; local laws/business needs can be legitimate. - Changed fact: regions are highly uniform with little autonomy → stronger centralization may be feasible. Source: pp. 536–537.
Scenario 21 — Steward or DQ Analyst
Situation: business SME owns Customer definitions, valid values, DQ rules, and issue decisions. - Primary problem: role classification — business stewardship/accountability. - Supporting: Data Governance; Data Quality; Metadata. - Roles: Steward, data owner, DQ Analyst. - Best response: Data Steward. - Weaker response: DQ Analyst emphasizes fitness monitoring/root cause/improvement. - Changed fact: job becomes profiling defects, monitoring condition, root-cause analysis → DQ Analyst. Source: pp. 538–539.
Scenario 22 — Architect or modeler
Situation: one task needs enterprise data-integration direction; another needs detailed logical/physical model and business rules. - Primary problem: two design responsibilities. - Supporting: Data Architecture; Data Modeling & Design. - Roles: Data Architect, Data Modeler. - Best response: Architect for architecture/integration direction; Modeler for detailed requirements/models/rules. - Weaker response: one role for both obscures the source distinction. - Changed fact: task becomes model version/change control → Data Model Administrator. Source: p. 538.
Scenario 23 — Integration architect or specialist
Situation: choose enterprise integration technology pattern, then build ETL/replication flows. - Primary problem: design vs implementation. - Supporting: Data Integration & Interoperability. - Roles: Integration Architect, Integration Specialist. - Best response: Architect designs the technology; Specialist implements systems/flows. - Weaker response: calling implementer “architect” because the work is complex ignores the responsibility definition. - Changed fact: primary task is application-system integration rather than data integration → Application Architect becomes more relevant. Source: p. 538.