The bank wants to launch a new instant-payments feature in the mobile app. The head of retail digital scopes it out and hits a wall on day one. To move money in real time, the feature needs to read a customer's live balance. But there is no single place that holds "the customer's balance." There are three.
Aldermont Bank runs three core banking systems, one for each bank it used to be. Checking accounts opened before 2008 live on a mainframe inherited from the original Calford Savings. Commercial accounts run on a platform that came with the Piedmont Trust acquisition. Anything opened since 2019 sits on the cloud-native core from Northline Bank. Three systems, three definitions of a customer, three answers to a question that should have one.
The feature is not hard to build. The problem is that no one owns the question of how these three systems are supposed to fit together. That question is what enterprise architecture exists to answer.
What enterprise architecture actually is
Most engineers first meet the phrase "enterprise architecture" attached to a certification course or a set of diagrams no one reads, and quietly file it under bureaucracy. That reputation is earned. Plenty of EA in practice has been exactly that: documentation produced to satisfy an audit, disconnected from anything running in production.
Strip away the baggage and the discipline is about one thing. Enterprise architecture is the practice of managing how an organization's business goals, processes, data, applications, and technology fit together as a whole. Not one system. The whole estate, and the relationships between the parts.
The core idea: Software architecture asks "how should this system be built?" Enterprise architecture asks "how should all our systems, and the business they serve, fit together?" It is architecture one level up, where the unit of design is the organization, not the application.
The distinction matters because problems at that level are invisible from inside any single system. Aldermont's three-cores problem is not a bug in any one core. Each works fine on its own. The problem lives in the space between them, and that space is exactly what enterprise architecture is responsible for.
The problem it solves
Every organization of any size accumulates systems the way a house accumulates clutter: one decision at a time, each reasonable on its own, adding up to something no one designed. A bank like Aldermont is an extreme case because it did not grow one system at a time. It absorbed entire banks, each arriving with a full stack already running.
The result is a familiar pattern. Three different systems can create a customer record, and none of them agrees on what a customer is. The same person shows up as three unrelated records with three IDs. When the fraud team wants a single view of a customer's activity, they discover there is no "single view" to be had; there is a reconciliation job that runs overnight and is wrong often enough that people do not fully trust it.
This is the condition enterprise architecture is meant to prevent, or at least contain. Left alone, an organization's technology estate drifts toward maximum entropy: duplicated capabilities, incompatible data, and a web of point-to-point integrations that no one fully understands.
The following diagram shows what Aldermont's integration landscape looks like without any coordinating architecture. Every system that needs data from another system simply builds a direct connection to it.
The point of the diagram is the tangle itself. Every line is a connection someone built to solve one immediate problem. None of them is wrong. Together they form a system that is impossible to reason about, where changing one core risks breaking integrations no one remembers building.
How it works — the four domains
Enterprise architecture makes the whole estate tractable by refusing to treat it as one undifferentiated mass. It splits the organization into four layers, each describing a different kind of thing, stacked so that each layer is served by the one below it. These are the four architecture domains, and they are the mental model the entire discipline hangs off.
The business architecture describes what the organization does, independent of any technology: its capabilities, processes, and the way it is organized. For Aldermont, "accept a deposit," "originate a mortgage," and "detect fraud" are business capabilities. They would still exist if the bank ran entirely on paper.
The data architecture describes the information the business runs on and how it is structured: what a "customer" is, what an "account" is, where the authoritative copy of each lives. Aldermont's three-cores problem is, at heart, a data architecture failure. There is no agreed definition of a customer, so there are three.
The application architecture describes the software systems themselves and how they relate: the cores, the CRMs, the mobile app, and the integrations between them. This is the layer most engineers already think in.
The technology architecture describes the infrastructure everything runs on: servers, networks, cloud platforms, data centers. The Calford mainframe and the Northline cloud environment are both technology-architecture concerns.
The layering is the whole point. Each domain is served by the one beneath it, and a change in one ripples through the others.
These four domains are worth a post of their own, and they will get one. For now the important thing is that they give the enterprise architect a way to ask precise questions. "Do we have one core or three?" is an application-architecture question. "Do we agree on what a customer is?" is a data-architecture question. Aldermont's instant-payments feature stalls because a business-layer goal collides with an unresolved data-layer question, and no one had been made responsible for that seam.
What the enterprise architect actually does
The job is not to draw diagrams. Diagrams are a byproduct. The real work is making decisions about the shape of the estate over time, and holding the line on them.
The core of it is maintaining two pictures. The first is the current-state architecture: an honest map of what actually exists today, three cores and all. The second is the target-state architecture: a description of where the estate should be in a few years, for example a single consolidated core with one customer definition. The distance between the two is the work, and the plan for crossing it is called a roadmap.
Consider Aldermont's most ordinary kind of conflict. The head of retail digital wants to ship the instant-payments feature this quarter, and the fastest path is to wire it directly to the Northline core and simply ignore the customers whose accounts live on the other two systems. That works, for those customers, this quarter. It also adds one more point-to-point integration to a landscape already drowning in them, and quietly commits the bank to a fourth definition of "balance."
The enterprise architect's job is to see that second-order cost and weigh it against the first-order benefit. Sometimes the answer is to ship the quick version anyway, because speed matters more right now. Sometimes it is to invest in the harder path that serves all customers and moves the estate toward the target state. The value is not in always saying no. It is in making that trade-off deliberately, with someone accountable for the long-term shape of the whole.
Where you will encounter it
You do not need the title "enterprise architect" to run into enterprise architecture. Any engineer at an organization past a certain size is working inside decisions the discipline made, or failed to make.
When a company mandates that all new services authenticate through one identity provider, that is enterprise architecture. When there is a review board you have to present a design to before you can provision infrastructure, that is enterprise architecture governance. When you are told to use the approved managed database rather than spinning up your own, someone made a technology-architecture standard. When a merger is announced and a team is quietly formed to figure out how two entire technology estates will become one, that team is doing enterprise architecture whether or not anyone uses the phrase.
The frameworks you may have heard of, such as TOGAF and the Zachman Framework, are formalizations of this work: structured methods for describing the domains, planning the move from current to target state, and governing the estate along the way. They are tools in service of the underlying job, not the job itself. Later posts in this series take them apart in detail.
Summary
Aldermont's instant-payments feature stalled not because anyone wrote bad code, but because a question no single system could answer had no owner. That is the shape of every enterprise-architecture problem. The failures live in the seams between systems, in the gap between what the business wants and what the estate can currently do.
Enterprise architecture is architecture with the organization as the unit of design. It splits the estate into four domains, business, data, application, and technology, so that whole-organization questions become answerable. It maintains an honest map of the present and a considered picture of the future, and it owns the trade-offs along the way. Done badly, it produces documents no one reads. Done well, it is the difference between a bank that can ship an instant-payments feature to every customer and one that discovers, on day one, that it does not know what a customer is.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.