Integrated Capstone — “Draw the Future-State Diagram”
Case
A diversified company has: - inconsistent Customer and Product definitions, - duplicated data across systems, - undocumented interfaces, - old and pilot technologies mixed together, - Agile teams that rarely consult enterprise architects, - a CEO demanding a new digital service within 12 months.
Leadership asks the Data Architecture team to “draw the future-state diagram.”
Question 1 — What should the team do beyond drawing a target picture?
A strong source-aligned answer is a connected architecture program:
- Evaluate the current specifications — determine what actually exists and where documentation is inaccurate/incomplete.
- Clarify enterprise data needs created by the business strategy/new digital service.
- Build/refresh the EDM for enterprise meaning and relationships.
- Build/refresh Data Flow Design for origin, movement, transformation, stores, roles, and dependencies.
- Classify lifecycle status so pilots, preferred platforms, containment candidates, and retirement targets are explicit.
- Define target and transition states rather than pretending the company can jump instantly to the future.
- Create a pragmatic roadmap tied to business capabilities, data dependencies, resources, costs, and urgency.
- Embed architecture in projects across scope, requirements, design, and buy/reuse/build decisions—including Agile delivery.
- Align with Enterprise Architecture and Data Governance so standards, decision rights, exceptions, stewards, and portfolio priorities reinforce the architecture.
- Measure three things: architecture compliance, implementation/evolution trends, and business value.
Why “just draw the target” is insufficient
Chapter 4 defines the discipline through artifacts + activities + behavior. A future-state diagram is an artifact. By itself it does not manage: - trusted current state, - migration/transition, - project execution, - enterprise reuse, - lifecycle intent, - governance, - adoption, - business value.
Question 2 — Which architecture framework is automatically correct?
None from the facts given.
Chapter 4 says a framework should fit the business and support useful stakeholder communication. Zachman is a major source example, but the chapter does not mandate it for all enterprises.
Question 3 — What evidence would show the architecture practice is working?
Look for a balanced evidence set:
Compliance
- projects engage architecture at the intended points,
- standards are followed or exceptions are governed.
Implementation trends
- shared structures/services are reused,
- duplication decreases,
- preferred/containment/retirement directions are actually reflected in the estate,
- project execution improves.
Business value
- digital capabilities launch more coherently,
- integration and correction costs fall,
- quality/agility/risk outcomes improve.
Capstone decision check
A complete Chapter 4 answer starts with enterprise need + trusted current state, combines EDM + Flow, defines target + transitions, creates a dependency-aware roadmap, embeds architecture in projects, manages lifecycle and governance, and measures compliance + implementation + value.