A customer walks into an Aldermont branch and applies for a mortgage. From their side it is one action: fill in a form, hand over documents, wait for a decision. Inside the bank, that single request touches almost everything the organization is made of. It invokes a business process someone designed. It reads and writes data whose meaning someone had to define. It runs through software systems someone built or bought. And all of that executes on infrastructure someone provisioned.
Four different kinds of thing, all in play for one mortgage. The reason enterprise architects can reason about an organization at all is that they refuse to treat those four as one blurred mass. They separate them into the four architecture domains, and once you see the estate through that lens, problems that looked tangled resolve into questions with clear owners.
Why four, and why in this order
The four domains are business, data, application, and technology. The grouping is not arbitrary and neither is the order. Each domain describes a distinct kind of thing, and each is served by the one beneath it. The business layer expresses intent. The data layer defines the information that intent operates on. The application layer is the software that manipulates that data. The technology layer is the physical and virtual infrastructure the software runs on.
The core idea: The four domains stack from the abstract to the concrete. Business is why and what. Data is what information. Application is what software. Technology is what it runs on. A decision at any layer constrains every layer below it, and a limitation at any layer eventually surfaces as a problem above it.
The direction of influence runs both ways, which is the part people miss. Business goals push down and shape everything under them. But a rigid mainframe at the technology layer pushes back up and quietly limits what the business is able to do. Aldermont's mortgage process is slow not because anyone wants it slow, but because a constraint two layers down makes it so. You cannot understand that without the layered view.
Business architecture — what the organization does
The business architecture describes what the organization does and how it is structured to do it, entirely independent of technology. Its building blocks are capabilities (the things the business is able to do, like "originate a mortgage" or "detect fraud"), value streams (the end-to-end flows that deliver something of value to a customer), and the organizational structure that carries them out.
The test of whether something belongs in the business layer is simple: would it still exist if the bank ran entirely on paper? "Assess a borrower's creditworthiness" would. It is a thing the business does regardless of whether a human underwriter or a scoring model performs it. "Run the credit-scoring microservice" would not; that is an application-layer concern.
This distinction is what keeps enterprise architecture from collapsing into IT. Aldermont's ability to originate mortgages is a business capability that outlives any particular system. The bank has changed the software behind it three times and will change it again. The capability is stable; its implementation is not. Anchoring on capabilities rather than systems is what lets an architect plan change without the ground shifting under them.
Data architecture — the information it runs on
The data architecture describes the information the organization depends on: what the important entities are, how they are defined, how they relate, and crucially, where the authoritative copy of each one lives. That last point is the one that sinks organizations, and Aldermont is a textbook case.
Ask what a "customer" is at Aldermont and you get three answers, because each of the three cores defines the entity differently. The Calford core keys customers one way, Piedmont another, Northline a third. A single human being who holds a checking account, a business loan, and a wealth account exists as three unrelated records with no shared identifier. There is no system of record for "customer," which is another way of saying the data architecture was never agreed.
The core concepts of the data domain are worth naming. A system of record is the single authoritative source for a given piece of data. A canonical model is an agreed shared definition of an entity that every system maps to, so that "customer" means one thing across the estate. Data lineage is the ability to trace where a piece of data came from and how it was transformed on the way. Aldermont has weak versions of all three, and every downstream problem, from the untrustworthy fraud view to the stalled instant-payments feature, traces back to that.
Application architecture — the software systems
The application architecture is the layer most engineers already live in. It describes the software systems in the estate, what each one is responsible for, and how they integrate. This is where the three cores, the CRMs, the mobile app, the fraud engine, and every integration between them are catalogued and, ideally, governed.
The key idea at this layer is that an application is defined by the business capability it supports, not by its technology. A well-designed application architecture maps cleanly onto the business architecture: each capability is supported by a clear owner rather than smeared across five systems that half-implement it. Aldermont's problem is that a single capability, "maintain a customer relationship," is implemented three times over in three CRMs, none of which is authoritative.
This is also where integration style is decided, and it is where post one's tangle of point-to-point connections lives. Whether systems talk through a shared event backbone, an API layer, or a mess of direct calls is an application-architecture decision. Get it right and adding a system is cheap. Get it wrong, as Aldermont did, and every new connection makes the next one harder.
Technology architecture — the infrastructure underneath
The technology architecture describes the infrastructure that everything above it runs on: compute, storage, networks, data centers, cloud platforms, and the standards that govern them. It is the most concrete layer and the one furthest from the business, which is exactly why its constraints are so easy to underestimate from above.
Aldermont runs a genuine split at this layer. The Calford core sits on an on-premises mainframe, batch-oriented and decades old. The Northline core runs cloud-native on modern managed services. These are not just different technologies; they have different fundamental rhythms. The mainframe settles many transactions in overnight batch windows. The cloud core is real-time. That single technology-layer mismatch is why the mortgage decision, and the instant-payments feature, run slower than anyone wants.
Here is the payoff of the whole layered model. The business wants real-time mortgage decisions. That is a business-layer goal. It is blocked by a technology-layer reality, the overnight batch cycle, several layers down. Without the four-domain view, this looks like "IT is slow." With it, the problem has a precise location and therefore a precise set of options.
Following one mortgage down the stack
Put the four together and a single mortgage application becomes legible at every level. The same request means something different, and is owned by someone different, at each layer.
Trace the failure upward and the diagnosis is exact. The mortgage feels slow at the business layer. The cause is a technology-layer batch window. But the reason the bank cannot simply route around it is a data-layer problem: the customer's full picture is split across three systems of record, so even a fast decision cannot easily see everything it needs. Three domains implicated, each with a different owner and a different fix. That precision is the entire reason the model exists.
Summary
The four domains are not four teams or four documents. They are four lenses on the same organization, ordered from the abstract to the concrete: business intent, the data that intent runs on, the applications that manipulate the data, and the technology it all executes on. Each is served by the layer below and constrained by it in turn.
Their value is diagnostic. When Aldermont's mortgage process drags, "IT is slow" is not an answer anyone can act on. Located in the four-domain model, the same complaint becomes a set of precise, owned questions: a business goal for real-time decisions, a data gap where no system of record owns the customer, an application tangle of point-to-point integrations, and a technology mismatch between batch and real-time. Every later topic in this series, capability maps, portfolio rationalization, governance, is really about getting one or more of these four domains under deliberate control. The domains are the coordinate system the rest of enterprise architecture is drawn on.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.