What to ask your agency about service boundaries

There is no clever trick in this one, just a handful of decisions worth making deliberately. If you are briefing an agency or a freelancer on service boundaries, these questions are worth asking early.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Assume whoever inherits this will have half your context and none of your patience.

Questions worth asking

• Who will actually do this work, and have they done it before?
• How will we know afterwards whether it worked?
• What happens if it needs changing in a year?
• What are you assuming that we have not confirmed?

What a good answer sounds like

The wrong boundary is more expensive than no boundary. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Data ownership is the clearest line to draw. In practice this is a scheduling problem more than a technical one. Check it against what you would want a competitor's site to get wrong.

What this looks like day to day

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Three things worth confirming about service boundaries before you move on:

• Someone can say what the current setup is without going to look
• The wrong boundary is more expensive than no boundary — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.