Lesson 1 — The Architecture Mental Model
Source focus: DMBOK Chapter 4, pp. 99–103.
1. “Architecture” is not one thing
The same word can refer to several different things:
| Sense | Meaning |
|---|---|
| Current-state architecture | A description of what exists now. |
| Target/future architecture | An intentional design of where the enterprise wants to go. |
| Architecture practice | The discipline and activities of designing and maintaining enterprise direction. |
| Architecture artifacts | Models, definitions, flows, standards, roadmaps, and related documentation. |
| Architecture team | The people performing and coordinating the work. |
On the exam, first ask which sense the stem is using. “The architecture shows five current Customer databases” is a present-state description. “Establish an architecture capability” is a practice question. “The target architecture” is an intentional future-state design.
2. Data Architecture definition
Data Architecture identifies enterprise data needs and designs and maintains master blueprints to meet those needs. The blueprints guide integration, help control data assets, and align data investment with business strategy.
The word master matters. One project can design one database; Data Architecture asks whether all projects together are building a coherent enterprise environment.
Example: four locally successful projects
A retailer launches a loyalty program, marketplace, mobile app, and analytics platform. Each project meets its deadline, but each creates a different Customer identifier and Product hierarchy. Every project can be “successful” while enterprise architecture deteriorates.
Architecture supplies shared enterprise requirements, meaning, standards, flows, and target-state direction so project success does not become enterprise inconsistency.
3. The strategy-to-execution bridge
Chapter 4’s central business purpose is:
Business Strategy → Data Architecture → Technology Execution
Business strategy might say: - become a subscription business, - create a 360-degree customer experience, - enter a new market, - shorten product-launch cycles, - monetize operational data.
Architecture translates that intent into questions such as: - What enterprise data is required? - What concepts and relationships must be shared? - Where will data originate? - Where must it move and transform? - Which authoritative sources and standards apply? - What target capability is needed? - Which changes and dependencies should be sequenced first?
Technology execution then implements the capabilities. The arrows do not mean a one-time handoff. Architects remain engaged as projects refine and implement the enterprise intent.
Concrete example: “uptime as a service”
A manufacturer shifts from selling equipment to selling uptime. That strategic change creates data needs for Equipment, Customer, Entitlement, Telemetry, Service History, Performance Thresholds, Billing, and Support. Architecture turns the business model into an enterprise data capability story before software selections accidentally define it.
4. Three essential components: outcomes, activities, behavior
| Component | What it means | Failure pattern |
|---|---|---|
| Outcomes / artifacts | Models, definitions, flows, standards, roadmaps, master design documents. | “Architecture is just diagrams.” |
| Activities | Work that creates, maintains, applies, reviews, and evolves architecture. | “We drew the blueprint, so the work is done.” |
| Behavior | Collaboration, mindset, skills, adoption, decision patterns. | “The model is excellent, but projects ignore it.” |
A city-planning analogy works well: maps are artifacts; planning/review processes are activities; developers and officials actually following the planning system is behavior. A perfect zoning map in a drawer is not an operating planning practice.
Stop and check
A project team says, “Our solution works, so the architecture is fine.” What enterprise question is missing?
The missing question is whether the local design aligns with shared enterprise data requirements, standards, target state, integration needs, reuse opportunities, and long-term roadmap. Local technical success is not the same as enterprise architectural coherence.
An organization has a sophisticated EDM, but projects do not know it exists and no review process uses it. What is failing?
The artifact exists; activities and behavior are failing.
Memory rule
Architecture creates enterprise coherence by connecting business intent, durable blueprints, project decisions, and organizational behavior.