Answers & Rationales DA4-029–042
DA4-029 — A
Why: This is exactly the Evaluate Existing Data Architecture Specifications activity: identify, assess accuracy/completeness/detail, and update to reality.
Weaker: B discards useful evidence; C plans from an untrusted baseline; D is passive/reactive.
Source: p. 112.
Confusion pair: current-state evaluation vs target planning.
DA4-030 — B
Why: The roadmap provides a pragmatic roughly 3–5 year path from actual conditions toward target architecture using dependencies, milestones, resources/costs, and business priorities.
Weaker: A is inventory/current state; C should integrate with, not replace, EA roadmap; D is far too implementation-specific.
Source: pp. 112–113.
Confusion pair: roadmap vs current-state documentation.
DA4-031 — C
Why: The source’s business-data-driven example begins with lower-dependency/data-originating capabilities and works toward dependent consumers.
Weaker: A reverses the dependency logic; B ignores data dependency; D invents a universal downstream starting point.
Source: p. 113.
Confusion pair: dependency-aware roadmap sequencing.
DA4-032 — D
Why: After project specifications exist, architecture asks about enterprise conformance, what should be incorporated/generalized, future needs, and reuse/delivery implications.
Weaker: A is UI-local; B ignores enterprise semantics; C would pollute the EDM by automatically promoting every local concept.
Source: p. 114.
Confusion pair: project scope vs enterprise architecture.
DA4-033 — A
Why: Scope should consider EDM alignment, reuse, project contribution to enterprise architecture, and external/downstream dependencies.
Weaker: B/C are generic project concerns; D is late physical sizing and misses early architecture work.
Source: p. 114.
Confusion pair: architecture scope vs local delivery.
DA4-034 — B
Why: Chapter 4 explicitly lists entity, source(s), availability, quality, pain points, and business value as data-related project requirements.
Weaker: A/C/D are partial or unrelated subsets.
Source: p. 114.
Confusion pair: data requirements vs technical-only requirements.
DA4-035 — C
Why: In the Buy path, reverse engineer when needed, map to enterprise structures, and document structural/definition/rule gaps; seek vendor documentation where possible.
Weaker: A accepts vendor semantics automatically; B falsely excludes COTS from architecture; D replaces enterprise truth with one product schema.
Source: p. 115.
Confusion pair: Buy vs Reuse vs Build.
DA4-036 — D
Why: Reuse emphasizes mapping existing application data to common structures/processes, understanding CRUD, enforcing authoritative/system-of-record use, and documenting gaps.
Weaker: A creates uncontrolled copies; B describes Buy; C ignores source authority.
Source: p. 115.
Confusion pair: Reuse vs Buy/Build.
DA4-037 — A
Why: Build means implement storage according to the agreed data structure and integrate according to standardized/designed specifications.
Weaker: B rejects enterprise standards; C is Buy-path activity; D postpones an implementation concern until too late.
Source: p. 115.
Confusion pair: Build vs Buy/Reuse.
DA4-038 — B
Why: Agile still requires appropriate specifications for models, capture, storage, and distribution, with close architect/programmer collaboration and standards.
Weaker: A/D falsely restrict architecture to Waterfall; C discards enterprise context.
Source: p. 115.
Confusion pair: Agile vs architecture.
DA4-039 — C
Why: Architecture should proactively influence portfolio choices/project scope so funded work moves enterprise architecture toward target rather than merely reacting after funding.
Weaker: A overstates architect budget authority; B removes needed domains; D wrongly replaces the larger EA roadmap.
Source: pp. 115–116.
Confusion pair: architecture vs portfolio/project priorities.
DA4-040 — D
Why: Modeling tools/repositories manage linked enterprise models and track lineage/relationships across purposes and abstraction levels.
Weaker: A says tools replace the model; B is not their use; C confuses repository capability with business-value measurement.
Source: p. 116.
Confusion pair: tool vs architecture content.
DA4-041 — A
Why: Asset management inventories contain system Metadata valuable for researching current state and constructing flows/dependencies.
Weaker: B cannot automate architectural judgment; C describes graphical design tools; D misstates the relationship.
Source: p. 116.
Confusion pair: asset inventory vs modeling/diagramming.
DA4-042 — B
Why: Current identifies products currently supported and used.
Weaker: Emerging = research/pilot; Reviewed = evaluated but no other status; Retirement = leaving use.
Source: pp. 116–117.
Confusion pair: lifecycle statuses.