Lesson 4 — States, Roadmap & the Architecture Practice
Source focus: DMBOK Chapter 4, pp. 111–114.
1. Architecture must balance quality and innovation
Chapter 4 describes two orientations.
Quality-oriented architecture
Focuses on improving execution and preventing deterioration: - redundant data, - uncontrolled copies, - incompatible interfaces, - duplicated capabilities, - growing “spaghetti” dependencies.
It favors standardization, reuse, governance, lifecycle management, trusted current-state knowledge, and incremental improvement.
Innovation-oriented architecture
Focuses on transformation and new opportunity: - new business models, - new partners, - digital products, - emerging technologies, - disruptive data uses.
The architect must be able to explore, not merely enforce yesterday’s standard.
The correct relationship
These are not mutually exclusive. Too much control can block justified innovation; pure experimentation can create a new generation of silos. Mature architecture enables innovation within an enterprise coherence system.
2. Five work streams establish an architecture practice
- Strategy — choose appropriate frameworks, representation approaches, and a roadmap for the capability.
- Acceptance & culture — build understanding and motivation; prevent architecture from being perceived as late-stage bureaucracy.
- Organization — assign accountabilities and responsibilities among architects, modelers, stewards, EA, projects, governance.
- Working methods — integrate architecture into development and portfolio processes.
- Results — produce useful models, flows, standards, lifecycle views, roadmaps, and project guidance.
Chapter 4’s deeper lesson is that hiring an architect is not the same as establishing a practice.
3. Launch artifacts, activities, and behavior together
The source recommends launching at least two implementation components in parallel—for example: - architecture teams/forums, - initial artifacts such as EDM/flows/roadmaps, - project ways of working, - organizational awareness.
Why? Each dimension reinforces the others.
- Artifacts without activities go stale.
- Reviews without good artifacts become subjective.
- Behavior messaging without working methods tells people to change without telling them how.
Early architecture-aware projects can require extra funding because reusable enterprise assets do not yet exist. Later projects should benefit from those shared assets.
4. Current state → target state → transition states
Current state
What actually exists now, including imperfect systems, flows, interfaces, and duplicated structures.
Target state
The intentional future design aligned to business strategy, desired capabilities, architecture principles, and realistic maturity.
Transition state
An intermediate architecture created while the enterprise migrates. Old and new systems may coexist; data can be synchronized; capabilities can move at different times.
Target = destination. Transition = stepping-stone.
5. Evaluate the current state before planning from it
Most organizations already have architecture documentation. Chapter 4 does not say to discard it automatically.
First: - identify what exists, - test accuracy, - test completeness, - test level of detail, - update it to reflect reality.
A roadmap built on an imaginary baseline will underestimate dependencies and migration cost.
6. The implementation roadmap
The Data Architecture roadmap is a pragmatic roughly 3–5 year development path. It connects actual conditions to the target architecture through: - milestones, - dependencies, - capabilities/work streams, - resources, - costs, - priorities, - transition work.
It should integrate with the larger Enterprise Architecture roadmap.
Business-data dependency sequencing
The chapter’s example sequences lower-dependency/data-originating capabilities before capabilities that depend on their data. If Customer Management is authoritative for Customer identity and five downstream capabilities depend on it, improving that upstream capability can reduce later rework.
But this is not a universal project-management law. Business urgency, regulatory deadlines, funding, actual conditions, and technical constraints still matter.
7. Architecture and portfolio management influence each other
Architecture should help reveal which investments: - move the enterprise toward target architecture, - enable shared capabilities, - duplicate an existing service, - create new architecture debt.
Portfolio decisions also constrain the roadmap because funded business priorities are real. This is a two-way relationship, not architecture issuing a detached master plan after funding is already decided.
Stop and check
Target architecture exists, but projects have no dependency sequence or migration states. What is missing?
A roadmap with transition-state and dependency planning.
Current diagrams are four years old. Build the roadmap now?
No. Evaluate/update the current-state specifications first.
A company refuses every new pattern because it is not already standard. Which orientation is neglected?
Innovation-oriented architecture.