The Boundary You Did Not Question Is Where the Complexity Lives
Who drew the boundaries that created your complexity?
Most organisations treat complexity as a condition of the domain. The system is complex because the business is complex. Regulatory requirements, legacy integrations, cross-product dependencies. Complexity is the environment. The job is to manage it.
Who drew the boundaries? And what motivated them?
Melvin Conway observed in 1968 that systems mirror the structures of the organisations that build them. That observation describes what happens. This post examines why.
In most large institutions, the cost of boundary decisions drawn for the wrong reason does not appear on any balance sheet. It surfaces years later as remediation programmes, integration rework, and platform consolidation that consume change capacity for years. The institution calls it complexity. In my experience, it is more often a structural liability created by boundaries that were never questioned.
Two modes of thinking
There are two modes of thinking that determine how boundaries get drawn in any technology organisation.
The first is the System SME. Deep knowledge of a specific system, its constraints, its history, its behaviour under load. A System SME inherits the system and iterates on it. They know where it breaks, what it tolerates, and how far it can bend. This knowledge is essential. It is hard-earned. And it is, by definition, scoped to the system they know.
The second is architectural thinking. The wider view. Why does this boundary exist? Does it serve the domain’s need or the org chart’s convenience? What will the downstream consequence be in three years if the boundary stays where it is?
Both modes are necessary. An architect without System SME depth builds abstractions that do not survive contact with reality. A System SME without architectural challenge optimises within boundaries that may be serving the wrong master. The problem surfaces when an organisation defaults to System SME-led boundary decisions without ever applying the second mode.
When the only people shaping a boundary are the people who know the system as it is, the boundary will be drawn around what the system already does. Not around what the domain requires.
Three kinds of boundary
Not all boundaries carry the same risk. But three types appear consistently in large technology estates, and each has a distinct failure pattern when drawn by the wrong hand.
Team boundaries define who builds and who runs. When drawn by function rather than accountability, complexity accumulates at the handoff between them. The team building the system has no stake in its behaviour in production. The team running it has no authority over its design. The seam between them becomes the most expensive point in the architecture.
System boundaries define what a system owns. When a System SME draws this boundary, it will expand to include whatever the system can technically support and contract to exclude whatever requires unfamiliar skills. The system boundary ends up reflecting the team’s comfort zone rather than the domain’s need.
Domain boundaries define which business capabilities belong together. When drawn by the people whose scope is determined by them, the boundary serves the leader’s position rather than the architecture. Proposals for domain mergers that collapse under architectural scrutiny but would expand the proposer’s territory are the clearest symptom.
In each case, the boundary was a decision. Someone made it. The question is whether they made it for the domain or for themselves.
The patterns I keep seeing
I have seen these boundary failures play out more than once, and they follow recognisable shapes.
A System SME in an ETL platform begins embedding business logic into the data movement layer. The ETL layer exists to extract, transform, and move data between systems. It was never designed to own business decisions. But the data is already there, and the transformation is easier to build in the pipeline than in a separate business service. Over time, business rules proliferate across a layer that has no domain authority over them. The business domain loses visibility into its own logic. The ETL system becomes the de facto owner of rules it was never designed to govern.
A System SME responsible for a core system adds non-core capabilities under the argument that one system is simpler. Fewer systems, fewer integration points, less operational overhead. The logic sounds right in principle. But the capabilities do not belong in the core system’s domain. Every additional capability increases coupling, cognitive load, and change risk. The system becomes simple to describe and complex to change.
And the pattern that is hardest to name, because it presents itself as technical reasoning. Proposals surface for merging domains. The arguments are presented with architectural language: shared data models, overlapping functionality, reduced duplication. When you apply genuine architectural scrutiny, the reasoning does not hold. The merger does not simplify the domain model. It expands the scope of the lead proposing it. The argument is circular. It begins with the conclusion.
In each case, the motivation was control, convenience, or scope expansion. Not domain logic. The institution absorbed the structural liability. The boundary was never questioned.
The pragmatic case, and its cost
There is a pragmatic case for System SME-led boundaries. They are faster to draw. They require less organisational negotiation. They match what the team can deliver today rather than what an architect believes the organisation should deliver in three years. In environments where delivery pressure is constant, the pragmatic boundary wins because the alternative, a target-state boundary that requires organisational change before it can be implemented, often does not get built at all.
The cost appears later. The boundary that was pragmatic in year one becomes the structural liability in year five. The institution discovers that what looked like a fast decision was actually a deferred one. And the deferral has been compounding.
What happens when boundaries are redrawn
When a boundary is placed correctly, complexity does not need to be managed. It collapses.
Team boundary: Amazon.
Amazon encountered this two decades ago. Development teams built systems. Operations teams ran them. The boundary between the two was drawn by function. Complexity accumulated at the handoff. Werner Vogels compressed the fix into six words. You build it, you run it. The boundary was redrawn around accountability rather than function. The team that wrote the code carried the full lifecycle. The handoff disappeared. The complexity at the seam disappeared with it.
Domain boundary: EBSCO.
EBSCO Information Services restructured seven years of component-based teams around value streams. The technology was the same. Feature delivery was 26% faster. Dependency blockers dropped by 45%.
System boundary: AWS Lambda networking.
AWS Lambda’s networking team encountered it at the system level, and their case is worth examining because the mechanism is the clearest.
The platform’s firewall configuration had grown to over 125,000 rules in a single central checkpoint. Every virtual machine slot required roughly 30 rules for its own traffic management. At 4,000 slots, all 125,000 rules sat in one place, evaluated in sequence.
Think of it as a building with 4,000 apartments and one security desk in the lobby. Every visitor is checked against the full list: the rules for apartment 1, apartment 2, apartment 3, all the way through to apartment 4,000. A visitor for apartment 1 is cleared almost immediately. A visitor for apartment 3,500 waits while the desk works through 105,000 rules that have nothing to do with them, before reaching the 30 rules that do.
The Lambda networking team did not remove rules. They did not add technology. They moved each apartment’s 30 rules to its own door. The lobby kept 144 building-wide rules that apply to everyone. Now any visitor passes through the same 174 checks: 144 at the lobby, 30 at their apartment. No one waits behind another apartment’s security. No performance gap between slot zero and slot 4,000.
Same rules. Same logic. Different placement.
The cost nobody budgets for
The standard I hold is this. Before accepting any boundary, whether team, system, or domain, ask whether it was drawn by the architecture or by the person whose career scope depends on it.
The structural liability created by misplaced boundaries is invisible until it becomes the dominant line in the change budget. Platform restructuring. Domain separation. Integration rework. These programmes exist because a boundary was drawn to serve someone’s scope rather than the institution’s need. The institution pays to redraw it, often more than once, often years after the original decision.
Complexity accumulates where responsibility was never settled. Someone preferred it that way.
If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.
Further reference material for Lambda example
