The Four Architecture Domains (BDAT)

Enterprise Architecture is organized into four complementary views of the same organization — Business, Data, Application, and Technology (BDAT).

At a glance

• What it is: Four domains/lenses on the same organization — Business, Data, Application, Technology.
• Why it matters: Working through the domains in order keeps technology choices traceable back to an actual business need, instead of “technology-first” design.
• For developers: if you’re asked to justify a technology choice, expect the first questions back to be about the business capability and data it serves — walk in with those already answered.
• When to use it: Structuring any EA analysis, review, or the phases of a framework like TOGAF’s ADM.
• When not to use it: For a narrowly-scoped implementation decision where the business and data context is already well understood.
• Prerequisites: Introduction to Enterprise Architecture.

Mental model

graph TD
    B["Business Architecture<br/>strategy, capabilities, processes"] --> D["Data Architecture<br/>structure & meaning of information"]
    D --> A["Application Architecture<br/>systems that automate & manage data"]
    A --> T["Technology Architecture<br/>infrastructure the applications run on"]

Each domain is a different lens on the same organization, not a separate organization. A single capability like “Process a Claim” has a view in every layer: the steps and rules (Business), what a “claim” record contains (Data), which systems handle it (Application), and what that software runs on (Technology). In practice, architects revisit all four domains iteratively as understanding deepens — the diagram shows a typical entry sequence, not a one-way pipeline walked once and never retraced.

Step-by-step walkthrough

1. Start with Business: identify the capability or process in question.
2. Define Data: what information/entities that capability depends on.
3. Define Application: which systems automate the process and manage that data.
4. Define Technology: what infrastructure those applications run on.
5. Check traceability — every technology choice should trace back to a business need through the chain above.

Worked example

For the capability “Process a Claim”:

• Business view: intake, triage, adjudication, and payout steps and rules.
• Data view: what fields a “claim” record contains (claimant, policy, incident, amount).
• Application view: the claims system and document management platform that handle it.
• Technology view: the cloud platform and database engine that software runs on.

Common use cases

Use case	When to use	Notes
Structuring a new analysis	Starting any architecture initiative	Work Business → Data → Application → Technology, in that order
Framework methodology	Following TOGAF’s ADM	Each domain has its own ADM phase (Business, Information Systems split into Data/Application, Technology)
Architecture review	Checking a proposal for completeness	Confirm all four domains were addressed, not just the technology one

Advanced details

• Artifacts per domain: capability maps and process models (Business); conceptual/logical data models (Data); application portfolios and integration diagrams (Application); infrastructure and platform standards (Technology).
• Common failure mode: jumping straight to Technology — picking a cloud platform or database — without first understanding the Business and Data views, which produces the wrong thing built very efficiently.
• Framework mapping: TOGAF’s ADM structures its phases around moving through these domains in sequence; review boards commonly check a proposal touches all four.

Quick reference

Domain	Primary question	Typical artifacts
Business	What does the business do, and how?	Capability maps, process models
Data	What information does the business rely on?	Conceptual/logical data models
Application	Which systems automate the process?	Application portfolios, integration diagrams
Technology	What infrastructure supports the applications?	Infrastructure/platform standards

Troubleshooting

Symptom	Likely cause	Fix
Design keeps changing after a platform is chosen	Technology was picked before Business/Data was understood	Back up and document the Business and Data views first
Review board keeps sending a proposal back	Only the Technology domain was addressed	Add capability, data, and application views before resubmitting

Check your understanding

• Why can a single capability have four different “views” without those being four different things?
• Pick a system you know and describe its Business, Data, Application, and Technology views in one sentence each.

Related pages

Part of Introduction to Enterprise Architecture. See Business Capability Mapping for the Business Architecture artifact this domain produces first, EA Frameworks for how TOGAF and Zachman apply these domains, and the Glossary for term definitions.