Scenario Lab — Cases 1–7
Scenario 1 — “Data model = architecture” shortcut
Case: A team has a detailed physical database model and declares the enterprise Data Architecture complete.
Best answer: A physical model is one implementation-level artifact. Enterprise Data Architecture needs enterprise blueprints across abstraction levels plus flow, state/roadmap, standards, and enterprise alignment.
Leading area: Data Architecture.
Support: Data Modeling & Design, flow/lineage, roadmap/state management.
Roles: Data Architect, project architect/modeler, governance.
Weaker response: approve the physical model because it is highly detailed. Detail does not create enterprise scope.
Changed fact: if the task is only to verify that one database schema correctly implements an approved logical model, Data Modeling & Design becomes the more direct task.
Source: pp. 99–110.
Scenario 2 — A new digital product
Case: A manufacturer designs a connected-device service; product designers make data-access/capture choices before architecture is involved.
Best answer: Engage Enterprise Data Architects and strategic Data Stewards early so business intent becomes explicit data/system requirements before technology decisions harden.
Leading area: Data Architecture.
Support: Business Architecture, Governance, product/project planning.
Roles: Enterprise Data Architect, Data Steward, product/business leaders.
Weaker response: wait until database design because architecture is “technical.” That loses the strategy-to-execution bridge.
Changed fact: if the product only consumes an existing governed service with no new data meaning, capture, storage, or distribution decision, architecture involvement can be lighter and focused on confirming reuse/alignment.
Source: pp. 101–103.
Scenario 3 — Which architecture domain?
Case: One group asks how customer-service processes create value; another asks how Customer data should be organized; another which applications act on it; another which platforms host them.
Classification:
Business → value/process/capability.
Data → organization/management of data.
Application → application structure/function.
Technology → platform/infrastructure.
Weaker response: treat every technology-enabled data question as Application or Technology Architecture.
Changed fact: change “how should Customer data be organized?” to “which CRM capabilities support service?” and the leading domain switches from Data to Application.
Source: pp. 103–104.
Scenario 4 — Zachman misuse
Case: A project manager expects Zachman to prescribe the exact modeling steps and project sequence.
Best answer: Zachman is being misused. It is an ontology/classification framework, not a methodology.
Leading area: Data Architecture / architecture frameworks.
Best use: classify/check viewpoints and artifacts; choose work methods separately.
Weaker response: follow the grid as a mandatory build sequence.
Changed fact: if the question asks how to classify a “Who” stakeholder description from a particular perspective, Zachman is directly useful.
Source: pp. 104–105.
Scenario 5 — Enterprise model with no flow
Case: EDM defines Customer, Product, and Order, but nobody knows where Customer originates, which stores replicate it, who updates it, or where it transforms.
Best answer: Add Data Flow Design / lineage and align it with the EDM.
Leading area: Data Architecture.
Support: Integration, Metadata/lineage.
Roles: Data Architect, integration/application owners, Stewards.
Weaker response: add more attributes to the EDM; richer semantics still do not show movement.
Changed fact: if the actual problem is disagreement over what Customer means, strengthen the EDM/definitions rather than flow first.
Source: pp. 106, 109–110.
Scenario 6 — Project model diverges from enterprise
Case: A project invents a new Customer definition because its local schedule is tight.
Best answer: Review mappings/definitions, direct reuse where appropriate, and improve/generalize enterprise artifacts when the project reveals a valid new enterprise need.
Leading area: Data Architecture.
Support: Modeling, Governance, Metadata.
Roles: Data Architect, Data Steward, project modeler/team.
Two bad extremes: blindly force an obsolete enterprise artifact, or allow unreviewed local divergence.
Changed fact: if the project’s concept is genuinely enterprise-relevant and the EDM is incomplete/wrong, update the EDM rather than label the project noncompliant.
Source: pp. 114–115.
Scenario 7 — Roadmap without current-state validation
Case: Leadership jumps to a target architecture and five-year plan even though existing diagrams may be obsolete.
Best answer: Evaluate existing specifications for accuracy, completeness, and detail; update the current state before relying on it for roadmap decisions.
Leading area: Data Architecture current-state assessment.
Roles: Data Architect, portfolio/program leaders, application owners.
Weaker response: infer current state from memory and go straight to target design.
Changed fact: once current-state artifacts are verified and current, move into target/roadmap trade-offs and sequencing.
Source: pp. 112–113.