60-Second Rapid Recall — R1–R27
Answer each prompt before opening the key below it.
R1. Define Data Architecture.
Key: Identify enterprise data needs and design/maintain master blueprints to meet them, guiding integration, control, and data investment.
Source: pp. 101–103.
R2. Name the three components used to view Data Architecture.
Key: Outcomes/artifacts; activities; behavior.
Source: p. 100.
R3. Name five business-driver roles of the Data Architect.
Key: Prepare for emerging opportunities; translate business needs; manage data delivery; align Business/IT; act as change/agility agents.
Source: p. 101.
R4. Name the four Enterprise Architecture domains.
Key: Business, Data, Application, Technology.
Source: pp. 103–104.
R5. What does Zachman classify, and what does it not prescribe?
Key: It classifies architecture artifacts/relationships across interrogatives and perspectives; it does not prescribe how to create them or the work sequence.
Source: pp. 104–105.
R6. Name the six Zachman interrogatives.
Key: What, How, Where, Who, When, Why.
Source: p. 105.
R7. What two specifications must Enterprise Data Architecture include?
Key: Enterprise Data Model (EDM) and Data Flow Design.
Source: p. 106.
R8. Define EDM in one sentence.
Key: A holistic enterprise-level, implementation-independent conceptual/logical view of key data entities, relationships, rules, and selected critical attributes.
Source: p. 106.
R9. Define Data Flow Design in one sentence.
Key: A master blueprint for storage, processing, and movement across databases, applications, platforms/networks, and business context.
Source: p. 106.
R10. Distinguish vertical and horizontal model linkage.
Key: Vertical = across abstraction levels/model lineage. Horizontal = same-level cross-model/Subject Area relationships.
Source: pp. 107–108.
R11. Top-down vs bottom-up EDM: what does each start from?
Key: Top-down starts from Subject Areas; bottom-up starts from existing data models.
Source: p. 108.
R12. Name five contexts data flows can map data to.
Key: Applications/processes, data stores/databases, network segments, CRUD roles, locations.
Source: p. 109.
R13. Quality-oriented vs innovation-oriented architecture.
Key: Quality prevents deterioration and promotes standardization/reuse/long-term improvement; innovation supports transformation, emerging opportunities, and disruptive technology/data use.
Source: p. 111.
R14. Name the five architecture-practice work streams.
Key: Strategy; acceptance & culture; organization; working methods; results.
Source: pp. 111–112.
R15. What should be done to existing architecture specifications?
Key: Identify them, assess accuracy/completeness/detail, and update them to match current reality.
Source: p. 112.
R16. How long a development path does the roadmap describe?
Key: Roughly 3–5 years.
Source: p. 112.
R17. What dependency logic can guide a business-data-driven roadmap?
Key: Begin with lower-dependency/data-originating capabilities and resolve dependencies toward more-dependent consumers, while retaining business-priority judgment.
Source: p. 113.
R18. Name the four project activity groups and one architecture question for each.
Key: Scope—alignment/reuse/dependencies; Requirements—entities/sources/availability/quality/value; Design—enterprise constructs/standards/target specifications; Implement—Buy/Reuse/Build and mappings/gaps.
Source: pp. 114–115.
R19. Name the three implementation modes inside Implement.
Key: Buy, Reuse, Build.
Source: p. 115.
R20. How should architecture work differ across Waterfall, incremental, and Agile methods?
Key: Waterfall can use phases/tollgates; incremental still needs enough comprehensive design early; Agile still needs data specifications and close architect/developer collaboration while implementation evolves iteratively.
Source: p. 115.
R21. Name the three tool categories.
Key: Data modeling tools/repositories; asset management software; graphical design applications.
Source: p. 116.
R22. Name all eight lifecycle projection statuses.
Key: Current; Deployment Period; Strategic Period; Retirement; Preferred; Containment; Emerging; Reviewed.
Source: pp. 116–117.
R23. Name four diagramming-clarity rules.
Key: Any four: consistent legend; objects match legend; consistent direction; clear crossings; meaningful visual attributes; linear symmetry/readable layout.
Source: p. 117.
R24. Name four implementation components that can be launched in parallel combinations.
Key: Teams/forums; initial artifacts; project ways of working; organizational awareness.
Source: pp. 117–118.
R25. Name three readiness/cultural risks.
Key: Any three source examples: lack of management support; no proven accomplishment; apprehensive sponsor; counterproductive executive decisions; culture shock; inexperienced project leader; dominance of a one-dimensional view.
Source: pp. 118–120.
R26. Name four Data Architecture governance activities.
Key: Oversee projects; manage designs/lifecycle/tools; define standards; create data-related artifacts.
Source: p. 120.
R27. Name the three metric families.
Key: Architecture-standard compliance; implementation trends; business value.
Source: pp. 120–121.