Two teams disagree strongly about where a service boundary should be. How do you run the session that resolves it?

What is being tested

Whether you can run a decision-making session rather than a discussion, and whether you bring evidence to a question that is usually argued on opinion.

Before the session

State the decision to be made in the invitation, precisely. "Decide where the boundary between ordering and fulfilment sits, and who owns the order state." Not "discuss the boundary".

Invite the people who can decide, and no more. A room of twelve makes no decisions.

Bring evidence, circulated in advance. For a boundary question specifically:

• Change correlation from version control — what changes together over the last six months. This is evidence about what the system actually is rather than what anyone intends, and it frequently settles the argument before the meeting.
• Traffic and dependency data — what calls what, how often.
• The last twenty features and which components each touched.

Speak to both teams individually first, to understand the interests rather than the positions. The disagreement is often about ownership, workload or a past incident rather than about the boundary.

During

Separate divergence from convergence. Generate boundary options first — including ones nobody favours, such as merging the components — then evaluate. Mixing them means the first proposal is attacked and alternatives are never offered.

Evaluate against stated criteria, agreed before the options are scored: change correlation, team cognitive load, consistency requirements, deployment independence.

Make the trade-offs visible rather than the preferences. "Option A means fulfilment owns order state, which costs a synchronous call at checkout and buys single ownership." That moves a discussion forward; "I prefer A" does not.

Name the disagreement explicitly if it persists rather than smoothing it. Unspoken disagreement resurfaces during implementation.

Timebox, and state what happens if time runs out — usually that you decide with the information available and record the uncertainty.

Ending

State the decision, the owner and the next action out loud before anyone leaves. Record it within the day with the reasoning and the revisit conditions.

The trap specific to architects

Facilitating and advocating at once. If you have a strong view, say so explicitly and hand facilitation to someone else — otherwise the group correctly suspects the process is steering toward your answer, and the outcome will not be owned by either team.