Scenario Lab — Cases 8–14
Scenario 8 — Dependency-aware sequencing
Case: Downstream Billing modernization begins before the foundational Customer/Product data it depends on is stable, causing repeated rework.
Best answer: Use business-data dependency logic to sequence lower-dependency/data-originating capabilities before dependent consumers, while still considering business priorities.
Leading area: Data Architecture roadmap.
Support: Business Architecture, portfolio planning.
Weaker response: begin with the most visible downstream capability while ignoring prerequisites.
Changed fact: if a downstream capability does not depend on the missing foundational data and has the highest urgent value, the roadmap can legitimately prioritize it. Dependency logic informs—it does not replace—business prioritization.
Source: p. 113.
Scenario 9 — COTS acquisition
Case: A package is purchased and the vendor refuses to provide its data model.
Best answer: Reverse engineer as necessary, map vendor structures/definitions/rules to enterprise architecture, document gaps, and obtain vendor documentation where possible.
Leading area: Data Architecture project implementation — Buy.
Support: Modeling, Metadata, Integration.
Weaker response: automatically treat vendor semantics as enterprise semantics.
Changed fact: if a complete vendor model is supplied and maps cleanly, reverse engineering is unnecessary; validation/mapping remains.
Source: p. 115.
Scenario 10 — Agile does not mean no architecture
Case: Sprint team says data capture/storage/distribution design can wait because Agile values working software.
Best answer: Keep appropriate data-model, capture, storage, distribution, and standard decisions inside iterative delivery with close architect/developer collaboration.
Leading area: Data Architecture project integration.
Weaker responses: skip architecture entirely, or create a huge up-front architecture package disconnected from sprints.
Changed fact: if the sprint changes only presentation logic and has no data/interface impact, architecture review can be proportionate rather than heavy.
Source: p. 115.
Scenario 11 — Technology lifecycle ambiguity
Case: One diagram gives the same appearance to a supported database, pilot technology, preferred platform, and retirement candidate.
Best answer: Apply explicit lifecycle statuses and connect them to investment/migration decisions.
Leading area: Data Architecture lifecycle technique/governance.
Support: Technology Architecture, portfolio management.
Weaker response: rely on age or decorative color without defined status semantics.
Changed facts: pilot → Emerging; restricted existing use → Containment; planned removal → Retirement; recommended default → Preferred.
Source: pp. 116–117.
Scenario 12 — Architecture chart that confuses everyone
Case: flow has random crossings, unexplained colors, inconsistent symbols, and an unreliable legend.
Best answer: Repair diagramming clarity—legend, symbol consistency, direction, crossings, meaningful visual attributes, and layout.
Leading area: Data Architecture technique/communication.
Weaker response: add more technical detail before fixing readability.
Changed fact: if the visual is clear but the underlying current-state content is inaccurate, the primary problem becomes evaluating/updating architecture specifications.
Source: p. 117; pp. 112–113 for changed fact.
Scenario 13 — Sponsor but no adoption
Case: excellent models exist, but project teams see them as IT paperwork, executives contradict them, and one application owner dominates decisions.
Best answer: Treat this as a behavior/culture/governance failure. Build broader sponsorship, integrate architecture into project ways of working, clarify decision rights, communicate value, and govern exceptions.
Leading area: Data Architecture implementation/readiness.
Support: Change management, Data Governance.
Weaker response: produce even more models and assume better artifacts will create adoption.
Changed fact: if adoption/governance are strong but the models themselves are wrong, shift to evaluating/improving the specifications.
Source: pp. 117–120.
Scenario 14 — Metrics that only count diagrams
Case: the architecture team’s success dashboard reports only number of diagrams produced.
Best answer: Use the three metric families—architecture compliance, implementation trends, and business value.
Leading area: Data Architecture governance/measurement.
Weaker response: increase the diagram production target. More artifacts do not show adherence, estate change, or outcome.
Changed fact: project review rate → compliance; reuse/retirement progress → implementation trends; agility/quality/cost result → business value.
Source: pp. 120–121.