I ended a recent post with a line I’m fond of: draw the boundaries where the business already cut them. Ryan Michela replied with the sharpest kind of agreement — the kind that points at the hard part you glossed over:
This is probably the hardest part, because it takes time and patient analysis to assemble a clear and nuanced understanding of how the business fits together. Each stakeholder often knows their tiny part, subtly misunderstands their peers.
He’s right. And — because I’m an architect and constitutionally incapable of a clean “yes” — it depends. Because that line hides an assumption I want to drag into the light: it assumes the business has already made the cut. That there’s a seam out there, real and decided, waiting to be discovered by anyone patient enough to look.
Sometimes there is. Often there isn’t. And the times it isn’t are exactly the times the advice does the most damage.
When the business hasn’t actually decided
Ryan’s “each stakeholder knows their tiny part” is the whole game, and it splits into two different diseases. They look similar from a distance — nobody can tell you where the boundary is — but they need different treatment.
Diffuse ownership. A single process is owned by John, Janet, and Jane all at once. Ask any one of them for the rule and you get a third of it, confidently, plus a wrong guess about the other two thirds. There is no clean cut here because the business never made one — it left the ownership smeared across three people and got on with its day. If you draw the boundary “where the business cut it,” you’ll build a module with three masters, or one bloated module that swallows all three because you couldn’t find the seam. Either way you’ve taken the org’s unresolved ambiguity and cast it in code, where it’s far more expensive to fix than it was in a meeting.
Legacy as oracle. This one’s worse. A process owner can’t describe their own process, because the process lives in a system built years ago that nobody’s touched since. The knowledge got offloaded into the software and the humans quietly stopped holding it — cognitive offloading, but institutional. The map became the territory. The old system is now the only surviving source of truth for how the business works.
Here the trap is precise and seductive: you go looking for the business’s boundary, find only the legacy system’s boundary, and faithfully reproduce it. But that seam was never a business decision. It was an accident of how someone happened to structure their code in 2011. Draw your shiny new modules along it and you’ve promoted a 2011 implementation accident to an architectural decision it never was — given an accidental seam the dignity of a bounded context it never earned.
These are business fixes — mostly
My instinct, and I suspect Ryan’s, is that both of these are really business problems. The fix for diffuse ownership is for someone to own the thing. The fix for legacy-as-oracle is for the business to relearn — or re-decide — its own process. Neither is something an architect can reach in and change. We don’t get to reorg the company or install accountability by drawing a diagram.
That’s true. But “hard to influence” quietly lets us off a hook I don’t think we’re allowed off. Because there’s one move that’s entirely ours, and it’s the one that matters most at a fuzzy boundary: refuse to encode the ambiguity silently.
The architect’s real leverage isn’t fixing the business. It’s making the cost of the business’s indecision legible to the people who can fix it. The architecture becomes a diagnostic instrument — and, better, a forcing function:
- “You’ve asked for this module. Three people own the process and not one can give me the invariant — the rule that’s always true. I can’t draw a boundary around a rule that doesn’t exist. Here’s what the gap costs us, with dates.” That sentence lands a decision the org was comfortably avoiding back on its desk. You haven’t fixed the business; you’ve made avoiding the fix more expensive than making it.
- For legacy-as-oracle: the finding isn’t “here’s the boundary.” It’s “the boundary is unknowable from the people; our only specification is the old code. Do we enshrine that, or do we actually decide?” That reframes a technical task as the business choice it always was.
This is the same instinct as reading the org chart as an architecture diagram: a lot of your design was decided by people who’ve never seen the codebase, and pretending otherwise doesn’t make it less true. The boundary you can’t find is telling you something about the organisation. Don’t muffle it.
When they won’t decide in time
Sometimes you surface the gap, cost it, put it on the right desk — and the business still can’t or won’t resolve it before you have to ship. Fine. You don’t get to stall, and analysis paralysis is its own failure. So you draw a provisional boundary — but you draw it honestly:
- Pick one owner by fiat and say out loud that you’ve done so, so the choice can be challenged.
- Or model the ambiguity explicitly — a shared kernel, an anti-corruption layer, a deliberately thin seam you fully expect to move — rather than hiding it inside a module and hoping.
- Then let reality push back. A provisional boundary is an experiment; run it and the true owner usually reveals themselves, because the pain concentrates wherever you guessed wrong.
The cardinal sin was never drawing the line in the wrong place. Boundaries move; good ones move cheaply. The sin is drawing it in the wrong place invisibly — so the org never confronts the decision it dodged, and nobody ever learns where the line should have been.
Finishing the sentence
So Ryan’s right, and I’ll finish the it-depends the way I always ask other people to. Draw the boundaries where the business already cut them — when the business has made the cut. When it hasn’t, your job isn’t to invent one and pretend you discovered it. It’s to be the one person in the room who won’t let the unmade decision go dark: keep it visible, keep it costed, keep it on someone’s desk.
Patient analysis doesn’t just find the seams. It finds the places where there are no seams yet — and those are the ones worth making a fuss about. That’s not scope creep. That’s the job.