Answers & Rationales DA4-015–028
DA4-015 — C
Why: Successful EDMs are usually built incrementally and iteratively; resource availability affects initial scope and detail.
Weaker: A assumes big-bang completeness; B treats an industry model as final enterprise truth; D abandons the enterprise view.
Source: pp. 106–107.
Confusion pair: incremental vs big-bang EDM.
DA4-016 — D
Why: Mapping from physical/project levels upward through logical/Subject Area/enterprise concepts is vertical linkage/model lineage.
Weaker: A is same-level linkage; B is copy consistency; C is lifecycle status.
Source: pp. 107–108.
Confusion pair: vertical vs horizontal mapping.
DA4-017 — A
Why: Relationships among peer Subject Area models/entities at the same abstraction level are horizontal mappings.
Weaker: B crosses abstraction levels; C is migration state; D is an application/technology dependency.
Source: pp. 107–108.
Confusion pair: horizontal vs vertical.
DA4-018 — B
Why: An entity resides in one Subject Area, although relationships can cross Subject Area boundaries.
Weaker: A duplicates semantic ownership; C makes application ownership a universal discriminator; D wrongly prohibits cross-area relationships.
Source: p. 108.
Confusion pair: Subject Area residence vs cross-links.
DA4-019 — C
Why: Top-down EDM construction starts by forming Subject Areas and populating them; bottom-up starts from existing models.
Weaker: A is COTS implementation; B abandons enterprise modeling; D describes bottom-up.
Source: p. 108.
Confusion pair: top-down vs bottom-up.
DA4-020 — D
Why: The discriminator should be consistent across the enterprise, and Chapter 4 says normalization is usually most effective for Data Architecture work.
Weaker: A is only one possible organizing principle; B destroys enterprise consistency; C falsely excludes source-listed discriminator options.
Source: p. 109.
Confusion pair: Subject Area discriminator choices.
DA4-021 — A
Why: End-to-end flows show origin, storage/use, movement, and transformation through processes and systems.
Weaker: B is governance authority; C is only one technical detail; D is EDM semantics.
Source: p. 109.
Confusion pair: data flow vs model.
DA4-022 — B
Why: Mapping which roles create/read/update/delete data is CRUD responsibility mapping within Data Flow Design.
Weaker: A is not the source use; C is a metric; D is Subject Area structure.
Source: p. 109.
Confusion pair: data-flow CRUD roles.
DA4-023 — C
Why: A process/data matrix clearly represents many-to-many create/use relationships, acquisition responsibility, and process dependencies.
Weaker: A falsely assumes one-way flow; B treats matrices/diagrams as mutually exclusive; D is far too narrow.
Source: pp. 109–110.
Confusion pair: matrix vs flow diagram.
DA4-024 — D
Why: Quality-oriented architecture improves execution, prevents deterioration, supports standardization/governance, and advances long-term architecture quality.
Weaker: A describes innovation orientation; B contradicts quality control; C describes short-horizon experimentation.
Source: p. 111.
Confusion pair: quality vs innovation.
DA4-025 — A
Why: Disruptive data-enabled services, leading-edge technology, and unproven business logic match innovation-oriented architecture.
Weaker: B is too control/quality-only; C is only one lifecycle activity; D is measurement rather than orientation.
Source: p. 111.
Confusion pair: innovation vs quality.
DA4-026 — B
Why: The five work streams are Strategy; Acceptance & Culture; Organization; Working Methods; Results.
Weaker: A is generic delivery; C are domains/categories; D mixes state and lifecycle terms.
Source: pp. 111–112.
Confusion pair: architecture practice work streams.
DA4-027 — C
Why: Architecture review checks that project designs are consistent with enterprise architecture and long-term organizational strategy, not only locally correct.
Weaker: A does not require identical physical design; B confuses oversight with execution; D wrongly prevents projects from contributing valid enterprise concepts.
Source: p. 112.
Confusion pair: architecture review vs project execution.
DA4-028 — D
Why: Replication can improve performance/availability but create inconsistency; controls must match the business consistency requirement.
Weaker: A wrongly bans replication; B falsely requires identical strictness everywhere; C reduces a data consistency concern to network architecture.
Source: p. 112.
Confusion pair: replication benefit vs consistency risk.