Lesson 2 — Enterprise Architecture Domains & Frameworks
Source focus: DMBOK Chapter 4, pp. 103–105.
1. Data Architecture lives inside Enterprise Architecture
The four domains are different views of one enterprise, not competing owners of the same problem.
| Domain | Primary question | Typical elements |
|---|---|---|
| Business Architecture | How does the enterprise create value and operate? | Business models, capabilities, processes, services, events, strategies, vocabulary. |
| Data Architecture | How should enterprise data be organized and managed? | Data models, definitions, mappings, flows, structured data interfaces/APIs, standards. |
| Application Architecture | Which applications provide which structure/function? | Business systems, software packages, databases, application portfolios. |
| Technology Architecture | What physical technology enables the applications? | Platforms, networks, infrastructure, security, integration technologies. |
One business change viewed four ways
Suppose the enterprise introduces a Subscription Management capability.
- Business Architecture describes the capability, process, events, and value proposition.
- Data Architecture identifies Subscription, Customer, Product, Entitlement, Billing Schedule, their relationships, and data movement.
- Application Architecture determines which systems support subscription operations.
- Technology Architecture determines which platforms and technical services host/connect those applications.
The domains constrain one another. A business capability can require data that is not captured. An application choice can create integration constraints. A technical platform can restrict how sensitive data moves.
Exam discriminator
Classify by the object of concern, not by the fact that technology is involved.
- value/capability/process → Business
- data organization/meaning/flow → Data
- application structure/function → Application
- platform/infrastructure → Technology
2. Architecture frameworks organize the thinking
An architecture framework is a foundational structure for developing and organizing related architectures—an “architecture for architecture.”
It helps stakeholders ask whether the needed perspectives and descriptions are represented. It is not automatically: - a project lifecycle, - a modeling notation, - a roadmap, - a repository tool.
3. Zachman: ontology, not methodology
Chapter 4 uses the Zachman Framework as its major example. Think of a 6 × 6 classification matrix.
Six interrogatives
What | How | Where | Who | When | Why
The rows represent increasingly concrete stakeholder/perspective views, moving from high-level/contextual understanding toward implementation and operation.
Each cell represents a distinctive kind of architecture description/artifact.
The trap
Because the matrix has rows and columns, it can look procedural. But Chapter 4 describes Zachman as an ontology: it classifies the kinds of descriptions that can exist and how perspectives relate.
It does not tell you: - which modeling step to do first, - how to normalize a model, - which sprint comes next, - what year to retire a platform, - how to sequence an implementation roadmap.
Framework vs roadmap vs model
| Concept | Question it answers |
|---|---|
| Framework | How do we organize the architecture viewpoints/descriptions? |
| Roadmap | How do we move from current toward target over time? |
| Model | How do we represent a particular aspect of the enterprise? |
The EDM is an architecture artifact family. It is not the framework. The roadmap sequences evolution. It is not the framework either.
Stop and check
Leadership selects Zachman. Has it now selected the exact method and sequence for creating Data Architecture?
No. It has selected a way to classify and check architecture perspectives/artifacts. A work method and transformation roadmap are separate decisions.
Which domain should define how Customer, Product, and Subscription data are organized and related?
Enterprise Data Architecture, because the concern is data meaning and organization, not application functionality or physical infrastructure.
Memory hooks
- Business = value/process
- Data = meaning/organization/flow
- Application = software function
- Technology = physical enablement
- Zachman catalogs; it does not conduct.