Count every party that owns a piece: internal teams, vendors, the integrator, the hardware supplier. Topology matters because a hub-and-spoke program has far fewer real boundaries than a mesh where everybody integrates with everybody.
Three questions per boundary, and the honest answers are usually much lower than the intuition. Count only the ones where you could name the document, name the person, and point at the comparison.
| Property | Covered | Share | Gap |
|---|---|---|---|
| Boundaries in the program | 15 | ||
| What crosses is written down | 2 | 13% | 13 not |
| One party owns the agreement | 1 | 7% | 14 unowned |
| Sent is compared against received | 1 | 7% | 14 blind |
Boundaries by party count and topology
How the surface grows. A chain adds one boundary per party; a mesh adds one for every party already present. The final column is what the next party costs you, and it is the number worth having in the room when somebody proposes adding a specialist to a program that is already struggling.
| Parties | Chain or hub | Mesh | Next party adds (mesh) |
|---|---|---|---|
| 2 | 1 | 1 | +2 |
| 3 | 2 | 3 | +3 |
| 4 | 3 | 6 | +4 |
| 5 | 4 | 10 | +5 |
| 6 | 5 | 15 | +6 |
| 8 | 7 | 28 | +8 |
| 10 | 9 | 45 | +10 |
| 12 | 11 | 66 | +12 |
Most real programs are between the two columns: not everybody integrates with everybody, but far more pairs exchange something than the architecture diagram admits. Count the pairs that actually exchange data rather than assuming the diagram.
A worked example
A device program with six parties: the model team, the platform team, the firmware vendor, the hardware supplier, the integrator and the customer's own IT group. Not a full mesh, but eight pairs genuinely exchange something, so there are eight boundaries.
Asked how many have a written record of what crosses them, with units, ranges, timing and partial-success behaviour, the honest answer is two. Asked how many have one party accountable for the agreement rather than for their own side, the answer is one. Asked how many compare what was sent against what was received, mechanically, the answer is also one, and it is not the same boundary.
So seven of eight boundaries are both unowned and blind. Every one of them is a place where two competent investigations will end at the same line from opposite directions, each correct, and where the program will spend weeks establishing what is true before anybody can start fixing anything.
The proposal on the table is to add a specialist for the perception stack. That would take it to nine parties and add more boundaries to a program whose failures are already in boundaries. The cheaper move is to write down what crosses the two suspect seams and put one name against each, which costs a week and no headcount.
The arithmetic, so you can check it
A chain or hub has n - 1 boundaries. A full mesh has n (n - 1) / 2, so the next party adds n more. Coverage is the share of boundaries that are documented, owned and instrumented, counted on the strictest of the three rather than the average, because a boundary that is documented and unowned is still one nobody will fix.
Counting seams tells you where failures can live, not where they do. A program with many well-run boundaries is healthier than one with three chaotic ones, and this arithmetic cannot see the difference. Use the count to decide where to look and what adding a party would cost, and use the register itself, filled in separately by both sides, to find the disagreement.
The five signs a failure is in the seams are in signs the failure is in the seams, not the model, and the procurement consequence in the third option.
Questions
It depends on the shape. A chain or a hub-and-spoke arrangement has one fewer boundary than it has parties. A mesh where everybody integrates with everybody has n times n minus one, over two, which grows quadratically. Six parties in a mesh is fifteen boundaries, and adding a seventh creates six more.
Because each party added creates boundaries with everyone already present, and cross-team failures live in boundaries rather than inside components. Past a certain point, resourcing the components adds surface to exactly the place the problem is. The org chart looks stronger every quarter while the number of places two assumptions can silently disagree grows faster than the depth anywhere.
One party accountable for the agreement between the two components rather than for either component, with the authority to change both sides. Where that does not exist, the boundary is defended from both directions and improved by neither, and both investigations end politely at the line with two correct partial answers.
Capturing what one side sent and what the other received and diffing them mechanically. Two logs read side by side does not count, because that is how the disagreement stays hidden. The comparison is the instrument, and its absence is why failures at that boundary survive longest.
No. It makes the hand-offs internal rather than removing them, so the same boundaries exist and you can no longer see them. The breadth is real on the org chart and the seams are still there, which is why a program can look better resourced and behave worse.