Here is a question this series has been circling for eight posts without ever answering properly. Aldermont has three core banking systems because it acquired three banks. Fine. But the last of those acquisitions closed in 2019, and the one before it in 2008. The bank has had years, in one case nearly two decades, and enormous financial incentive to consolidate. Every architect who has passed through has flagged it. So why are there still three?
The usual answers are unsatisfying. It is expensive, yes, but so is running three cores. It is risky, yes, but so is the status quo. Nobody prioritized it, but everyone knew. The proximate answers all fail to explain the sheer durability of the problem.
The real explanation is uncomfortable, and it was published in 1968 by a computer scientist named Melvin Conway. The three cores persist because, in every way that matters, Aldermont is still three banks.
What Conway's Law says
Conway's original observation is deceptively plain. Organizations design systems that mirror their own communication structures. The shape of the software you build will come to match the shape of the organization that built it, because the interfaces in the system reflect the interfaces between the people.
The mechanism is not mystical. It is almost boring. Two engineers sitting together, talking constantly, will build tightly integrated code, because coordinating is cheap for them. Two teams in different divisions, meeting monthly through their managers, will build systems with a formal, thin, carefully specified interface between them, because that is the only kind of coordination available. The communication cost between the people becomes the coupling cost between the components. You do not decide this; it happens to you.
The core idea: System boundaries form where communication is expensive. If two groups of people find it hard to talk, the software they build will have a hard boundary between it. Your architecture is a fossil record of your organization chart, and it will keep reforming into that shape no matter how many times you redraw the target architecture.
Stated that way, Conway's Law stops being a wry aphorism and becomes something with teeth for an enterprise architect. It says the target architecture is not a free choice. It is constrained, and the constraint is the org chart. Which is precisely why Aldermont still has three cores.
Why Aldermont really has three cores
Trace it through and the durability of the three-cores problem stops being mysterious.
Each acquisition brought an entire bank: not just a core system, but the people who built it, the teams who ran it, the managers who owned it, and the reporting lines that connected them. Aldermont merged the legal entities and the balance sheets. It did not truly merge the organizations. The Piedmont people still largely work with Piedmont people. The Northline engineers still form a distinct group with their own practices and their own leadership chain. Communication within each legacy group is cheap and constant; communication across them is expensive, formal, and rare.
Conway's Law then makes the outcome inevitable. Three organizations with weak communication between them will maintain three systems with hard boundaries between them, because that is the only architecture their communication structure can sustain. Every attempt to consolidate the cores has been an attempt to build a single tightly integrated system using an organization that has no cheap communication path across the seams. The architecture keeps snapping back to three because the org is still three.
This reframes every consolidation attempt the bank has made. Those programs were treated as technology programs: choose a target core, migrate the data, retire the rest. Conway's Law says a technology program alone cannot succeed here, because the force that produced three systems is still fully intact and will reproduce the separation in whatever new architecture gets built. You can merge the databases and still end up with three de facto systems inside one nominal platform, each maintained by its own group, diverging quietly.
Conway's Law as an architectural constraint
The reason this matters for enterprise architecture specifically is that it demolishes a comfortable assumption baked into the frameworks. The whole apparatus of target-state architecture, TOGAF's phases, the beautifully modeled future estate, implicitly assumes the architect is free to design any target they can justify. Conway's Law says the space of achievable architectures is bounded by the organization's communication structure, and no amount of modeling escapes that boundary.
Put bluntly: you cannot build an architecture your organization is not shaped to sustain. An organization split into rigid silos will not successfully build a tightly integrated platform, no matter how elegant the target architecture. It will build something that looks integrated on the diagram and is siloed in practice, with the seams falling exactly where the org's seams fall. The diagram will be a lie, and everyone will slowly discover this over the course of the program.
This is why an enterprise architect who ignores organizational structure is missing half the problem. Every target architecture is implicitly a claim about how people will communicate. If that claim is false, the architecture will not hold, and it will fail in a way that looks like a series of unrelated delivery problems rather than the single structural cause it actually is.
The Inverse Conway Maneuver
If the organization determines the architecture, then a genuinely powerful move becomes available. Instead of fighting the org structure to force through an architecture it cannot sustain, change the org structure to produce the architecture you want. This is the Inverse Conway Maneuver, and it is the point at which Conway's Law turns from a diagnosis into a tool.
The logic is direct. If system boundaries form where communication is expensive, and you want a system boundary to disappear, then make communication across that boundary cheap. Merge the teams. Put them under one leader, in one reporting line, with shared goals and shared incentives. Do that, and the hard boundary in the software becomes possible to dissolve, because the organizational force holding it in place is gone.
For Aldermont, this changes what the consolidation program even is. The program's first move should not be choosing a target core. It should be genuinely merging the three engineering organizations: one core banking group, one leadership chain, mixed teams drawn from all three legacy banks, shared objectives, shared on-call. Only once that organization exists does building a single core become achievable, because only then does the bank have a communication structure capable of sustaining one tightly integrated system. Reorganize first, then architect. The reverse order has been tried, twice, and it is why there are still three cores.
Where this shows up beyond banks
Once you know to look for it, Conway's Law is everywhere in the systems you already work on, and it explains a lot of otherwise baffling design.
The most cited modern instance is the relationship between microservices and team structure. The reason "two-pizza teams" and service-per-team models are so often paired is straight Conway: if you want independently deployable services with clean boundaries, you need independent teams with clean boundaries and low coordination needs. Organizations that adopt microservices while keeping a monolithic, tightly-coupled org structure tend to produce what is sometimes called a distributed monolith, all the operational cost of many services with none of the independence, because the teams still have to coordinate on every change. The architecture diagram says microservices; the communication structure says monolith; the communication structure wins.
It shows up in integration seams. If your company's frontend and backend are separate departments with separate managers, the API between them will be formal, versioned, and negotiated, and changing it will take weeks. If they are one team, the same boundary will be fluid and casual. The technology is identical in both cases; the org produced the difference.
And it explains the persistence of legacy generally. A system that a single isolated team owns, and that nobody outside that team understands, is protected by exactly the communication barrier that produced it. The system and the silo hold each other in place, which is the general form of Aldermont's specific problem.
Summary
Conway's Law states that organizations build systems that mirror their communication structures, and the mechanism is mundane: system boundaries form where communication between people is expensive. For enterprise architecture, this is not a curiosity but a hard constraint. The space of architectures an organization can actually build and sustain is bounded by the shape of the organization itself, which means a target architecture is always, implicitly, a claim about how people will talk to each other. When that claim is false, the architecture fails, and it fails in ways that look like unrelated delivery problems rather than the single structural cause they share.
That is the honest answer to the question this series opened with. Aldermont does not have three cores because three acquisitions happened to leave three systems lying around. It has three cores because it is still, in its communication structure, three banks, and three weakly-connected organizations cannot sustain one tightly integrated platform no matter how good the migration plan is. Every consolidation attempt that treated this as a technology problem was fighting a force it never named.
The Inverse Conway Maneuver is what turns the law from an explanation into a lever. If the organization determines the architecture, then reshaping the organization is an architectural act, arguably the most powerful one available. Merging the three engineering groups into one genuine organization is not a precondition for the consolidation program; it is the first phase of it. This is also why enterprise architecture cannot be a purely technical discipline, and why the enterprise architect's most consequential recommendation is sometimes about reporting lines rather than systems. The org chart is not context surrounding the architecture. It is part of the architecture, and it is the part that will quietly overrule every diagram it disagrees with.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.