Enterprise Architecture Domains: How to Visualize Domains in an Architecture Blueprint

Before the internet, Google, and generative AI, there was the home encyclopedia. For many of us, it was the first place we learned to visualize complex systems.

For some topics, we could flip through acetate sheets to see a machine or biological system deconstructed into its constituent parts.

Seeing the Whole Through Layers

Viewing an entire system at once is often too complex to be useful, but understanding it as a whole still matters. Layering provides that abstraction.

This compositional model carries forward into architecture blueprints, where domains help interpret and govern what the blueprint shows.

Building on the Baseline Architecture Blueprint

In Constructing the Baseline Architecture Blueprint, we examined an archetypical system diagram that was intentionally high-level, but with enough structural detail to support the exercise.

Now we continue building the blueprint, focusing on architecture domains, or, using the acetate sheets, so to speak, to look more closely at the system’s layered components.

Before applying them, though, we need to be precise about what an architecture domain is and what it is not.

What Are Enterprise Architecture Domains (and What They Are Not)

A domain in enterprise architecture is a bounded area of architectural significance. It stratifies assets so oversight can be applied across large groupings. It also brings together asset ownership and architectural ownership.

These domains are overlays that attach to assets regardless of where they appear in the architecture blueprint.

This may sound straightforward, but most architecture approaches get it wrong by treating architecture domains as part of the structure.

But an architecture domain is not a box on a diagram, a layer in a stack, or a region of containment. Those belong to the blueprint.

Architecture domains also overlap. This overlap becomes clear when we look at how domains apply to individual assets.

Multiple Domains, One Asset

An asset rarely fits within only one architecture domain.

Remember from the article Enterprise Architecture Begins Where Responsibility Is Defined, that each asset must have a specific owner, the individual who is responsible for the work that is done on that asset, likely a technical lead, a manager, or an architect.

We also said that where there is overlap, we want to be pragmatic in the determination. This becomes more concrete when we look at a few examples.

Examples of Enterprise Architecture Domains in Practice

So far, we’ve identified assets and indicated their type (e.g., AP, IN), establishing a specific classification. This classification represents the primary domain for each asset.

Firewalls, for example, are typically infrastructure assets based on ownership. Much of the work, however, is defined by cybersecurity (e.g., firewall rules), often by a security engineering function.

Applications, as another example, primarily fit within the application domain. But they are also materially influenced by other architecture domains: 

• The data domain, because applications store or process information.
• The security domain, because applications expose access and risk.
• The infrastructure domain, because applications must run somewhere.

Each domain brings its own rules and constraints. Together, they define what is permissible.

At this point, it becomes easy to treat domains as structural elements or to introduce new domains based on how assets are described. This is where most approaches begin to drift.

Where Enterprise Architecture Domains Are Often Misapplied

These misapplications stem from treating domains as structure rather than as overlays of governance.

To address this, we apply a method of secondary attribution that visualizes domains without altering the underlying blueprint. It preserves the structural integrity of the blueprint while making domain governance explicit.

Using Secondary Domain Attribution in the Architecture Blueprint

Secondary attribution uses annotations to show where additional domains apply beyond an asset’s primary classification.

Secondary domains attach directly to assets and appear consistently across all instances, revealing relationships not immediately obvious from the primary asset type.

To make this visible in the blueprint, we introduce a small set of domain markers.

Domain Markers for Enterprise Architecture Domains

Figure 1 introduces domain markers for the four architecture domains used for secondary attribution.

The system domain is an aggregation of assets and would be redundant if used for secondary attribution.

And technology assets are lower-level building blocks within the structural hierarchy and do not introduce a separate layer of governance, so they do not require secondary domain attribution.

With these markers defined, we can now apply them to the blueprint.

Applying Enterprise Architecture Domains to the Blueprint

Figure 2 shows this additional level of attribution on the blueprint, allowing secondary domains to be applied to assets.

The blueprint now presents a layered view by primary and secondary architecture domains. This allows the same structure to be interpreted through different domain perspectives without being redrawn.

Decomposing Architecture Assets Within the Blueprint

We will cover the mechanics of creating architecture blueprints using common diagramming tools in the article Creating Architecture Blueprints Using Common Diagramming Tools.

But before we do that, we need to take the blueprint method to a deeper level. Architecture assets do not stop at a single level of abstraction. They often require further decomposition, but not all at once and not everywhere.

The next step is to introduce modules as logical groupings within an asset and components as the specific elements that implement those modules.

This allows the blueprint to move from a single level of structure to a layered model while preserving clarity, which we will cover in the article Extending the Architecture Blueprint: Modules, Components, and Architectural Decomposition.

Notes:
1. Headline image generated by Gemini and ChatGPT.