Answers & Rationales DA4-001–014
DA4-001 — A
Why: Data Architecture identifies enterprise data needs and designs/maintains master blueprints that guide integration, asset control, and data investment alignment.
Why the others are weaker: B is only physical modeling; C is application/IT governance; D is Data Quality execution.
Source: pp. 101–103.
Confusion pair: Data Architecture vs modeling/execution.
DA4-002 — B
Why: The source frames Data Architecture as translating business strategy/needs into data and system requirements technology execution can realize.
Weaker: A is too narrowly technical; C is a DQ process relationship; D is a procurement subset, not the chapter’s bridge.
Source: p. 101.
Confusion pair: business strategy vs technology execution.
DA4-003 — C
Why: Chapter 4 views architecture through outcomes/artifacts, activities, and behavior.
Weaker: A are governance instruments; B are neighboring EA domains; D are architecture states, not the three essential components.
Source: p. 100.
Confusion pair: artifacts vs activities vs behavior.
DA4-004 — D
Why: Physical models participate in architecture lineage but are products of Data Modeling & Design; one physical schema cannot represent enterprise architecture.
Weaker: A contradicts the source; B still reduces architecture to technical diagrams; C wrongly replaces the abstraction stack.
Source: pp. 100, 106–108.
Confusion pair: Data Architecture vs Data Modeling & Design.
DA4-005 — A
Why: Business Architecture covers how the enterprise creates value through models, capabilities, processes, services, events, and strategy.
Weaker: B organizes/manages data; C concerns application structure/function; D concerns enabling technology.
Source: pp. 103–104.
Confusion pair: four EA domains.
DA4-006 — B
Why: Enterprise Data Architecture is the domain describing how data should be organized and managed.
Weaker: A focuses value/process; C applications; D physical technology.
Source: pp. 103–104.
Confusion pair: architecture domains.
DA4-007 — C
Why: Chapter 4/Table 6 treats business systems, software packages, and databases as Application Architecture elements.
Weaker: A is infrastructure/platform; B value/process; D data models/definitions/flows rather than application components.
Source: pp. 103–104.
Confusion pair: Application vs Technology Architecture.
DA4-008 — D
Why: An architecture framework is a foundational structure—an “architecture for architecture”—used to develop and organize related architectures.
Weaker: A confuses framework with lifecycle/methodology; B with repository tooling; C with Data Quality measurement.
Source: p. 104.
Confusion pair: framework vs methodology/tool.
DA4-009 — A
Why: Zachman is an ontology/classification of architecture artifacts/perspectives and does not define how to create them.
Weaker: B incorrectly makes it a methodology; C is too narrow; D confuses it with a roadmap.
Source: pp. 104–105.
Confusion pair: Zachman ontology vs methodology.
DA4-010 — B
Why: The six Zachman interrogatives are What, How, Where, Who, When, Why.
Weaker: A, C, and D are unrelated lists, not the six fundamental questions.
Source: p. 105.
Confusion pair: Zachman interrogatives.
DA4-011 — C
Why: Enterprise Data Architecture must pair Enterprise Data Model + Data Flow Design so enterprise meaning and movement fit together.
Weaker: A is too implementation/technical; B are useful but not the named pair; D belongs to neighboring architecture/asset concerns.
Source: p. 106.
Confusion pair: EDM vs Data Flow Design.
DA4-012 — D
Why: EDM is a holistic enterprise-level, implementation-independent conceptual/logical view of key entities, relationships, rules, and critical attributes.
Weaker: A is application-specific implementation; B is network/flow detail; C is roadmap/portfolio content.
Source: p. 106.
Confusion pair: EDM vs project model.
DA4-013 — A
Why: Data Flow Design is the master blueprint for storage, processing, and movement across databases, applications, platforms/networks, and business context.
Weaker: B is glossary semantics only; C modeling technique; D metric.
Source: p. 106.
Confusion pair: EDM vs Flow.
DA4-014 — B
Why: Architecture must represent what exists, the intended future, and intermediate/project states used to move toward that future.
Weaker: A misunderstands state perspectives; C invents role-exclusive usage; D transition state does not replace the roadmap.
Source: p. 106.
Confusion pair: current vs target vs transition.