EA Domains

Definition

Enterprise architecture is conventionally divided into four domains:

• Business architecture — capabilities, processes, value streams, organisation.
• Data architecture — the information the enterprise holds, its meaning, ownership and flow.
• Application architecture — the applications, their responsibilities and their relationships.
• Technology architecture — the infrastructure, platforms and standards underneath.

What each domain is genuinely for

Business answers "what does the organisation do, and where should it invest". It is the only domain an executive audience will engage with directly, which makes it the entry point for every conversation that needs funding.

Data answers "what do we know, who owns it, and can we trust it". In practice this is where the most valuable enterprise work sits, because data ownership and definition problems cross every boundary and nobody else is positioned to resolve them.

Application answers "what systems exist, what do they do, and what duplicates what". Its main output is a portfolio view that reveals redundancy and gaps.

Technology answers "what do we run on, and what are the standards". Least interesting to the business and most immediately actionable for engineering.

The usual failure across all four

Producing models nobody uses. The four-domain frame is a way of ensuring nothing is overlooked, not a mandate to document everything in each. An enterprise architecture practice that produces comprehensive models of all four domains has usually spent its budget on documentation rather than on decisions.

The corrective question for any artefact: which decision does this inform, and who is making it? If there is no answer, do not produce it.

Where the domains interact, which is where the value is

The interesting findings are almost always at intersections: a capability implemented by four applications; a data entity owned by nobody and written by six systems; a technology standard that makes a required capability uneconomic.

Those are visible only if the domains are related to each other, which is the actual reason to have the frame.

Failure scenarios

• Each domain documented in isolation, so the intersections are never examined.
• Models produced as deliverables rather than as inputs to decisions.
• Data architecture reduced to a schema catalogue, missing ownership and meaning — which is where the value was.
• Business architecture written by architects without the business, so it is an engineering interpretation.

Interview question

"Which enterprise architecture domain produces the most value in practice, and why?"