In its second year the fictional Magaliesberg Provincial Supplier Desk was given money for a second team. The province wanted a supplier development capability: training sessions, mentorship matching and readiness checks for small suppliers before they bid. The vendor who had drawn the original eleven-service slide came back with an updated version. "Now that you have two teams," the proposal said, "you can finally move to microservices so that each team works independently."
Thabo Molefe put two numbers on the whiteboard: 2 teams, 13 services. Then a third: about 6.5 services per team, each needing a pipeline, an on-call rotation, alerts, a budget line and someone who understands it at 02:00. "This does not make the teams independent," he said. "It makes each of them responsible for more things than they can hold in their heads."
The Magaliesberg Provincial Supplier Desk is a fictional provincial supplier-support platform. Its people, systems and figures are illustrative. This part argues that a service boundary is an organisational decision first and a technical one second.
Systems take the shape of the organisations that build them
In 1968 Melvin Conway published a paper in Datamation, How Do Committees Invent?, whose conclusion is now known as Conway's law: organisations that design systems "are constrained to produce designs which are copies of the communication structures of these organizations". The observation cuts both ways. If two teams must constantly coordinate to change one service, the service boundary is in the wrong place. If one team owns many services, those services will tend to be changed together, because that is how the team works, and the boundaries between them will add cost without adding independence.
The practical reading for architects is simple: before drawing service boundaries, draw the teams. A boundary that does not match a real, durable owner is decoration that has to be operated.
What owning a service actually means
Teams often say they "own" a service when they mean they wrote most of its code. Running a service in production is a much larger commitment.
Every line on that card is work that recurs. Some of it, like pipelines and dashboards, can be provided by a platform. The rest, like understanding the service's failure modes, deciding on its contract changes and answering for its cost, cannot be delegated without losing the ownership itself. Microsoft's microservices architecture guide (checked on 5 November 2026) describes the target as services small enough that "a single feature team can build, test, and deploy" each one, and warns that the style requires a mature DevOps culture and the right skills. Both conditions are about people.
Count owners before you count services
The Supplier Desk team now uses a rough arithmetic before any discussion of service boundaries. It is CloudNala analysis, not an industry standard, but it makes a hidden constraint visible, in the spirit of Small teams need better decision systems, not more tools.
- Owners. How many durable teams exist, funded for at least the next two years?
- On-call capacity. How many people can share a rotation without burning out? Seven people cannot staff seven separate rotations.
- Cognitive budget. How many distinct production components can one team understand well enough to diagnose at night?
The book Team Topologies, by Matthew Skelton and Manuel Pais, made the last point central. Its authors' key concepts (checked on 5 November 2026) treat cognitive load as a limit on team effectiveness: every added tool, responsibility or domain uses up capacity, and overloaded teams decide worse and move more slowly. A service count that exceeds the cognitive budget of its owners does not create autonomy. It creates teams that are always half-familiar with the thing that is failing.
For the Supplier Desk, two teams of six and seven people, sharing one on-call rotation, can sensibly own a small number of deployable units. Thirteen would leave each person on call for components they had never changed.
Align module and service boundaries with durable teams
The team's answer to the vendor was not "no services". It was "boundaries that follow the teams".
- The new team owns a new module. Supplier development is a distinct capability with its own vocabulary, users and rules. It became a module in the existing application, with its own contract and schema, owned entirely by the new team.
- Ownership was made explicit for every existing module. The original team kept registration, documents, verification, cases and reporting. Notifications, already a separate service after Part 3, was assigned to the original team, with a named primary owner.
- The shared release was measured, not assumed to be a problem. For three months, the teams recorded how often one team's release waited for the other's testing. If that wait became material, the evidence gate from Part 1 would decide whether supplier development should become its own deployable unit.
After three months the measurement showed two short delays, both resolved by moving a shared test suite into each module. The teams had autonomy over their code, their schemas and their contracts without a network hop between them.
Coordination costs move, they do not disappear
Splitting a system into services is often presented as removing coordination. In practice, it changes the kind of coordination needed.
| Inside one deployable | Across services |
|---|---|
| Teams coordinate releases | Teams coordinate contract versions |
| A breaking change fails the build | A breaking change fails in production unless contracts are tested |
| One trace shows the whole request | Tracing must be propagated and correlated across services |
| Refactoring across a boundary is one pull request | Refactoring across a boundary is a migration with versions and deadlines |
| One on-call rota knows the whole system | Several rotas must agree who owns an incident |
Neither column is free. The question is which kind of coordination your organisation is better at, and which one the problem actually requires. A team that coordinates releases badly will not necessarily coordinate contract versions any better. Our article on why multi-agent is an organisational choice makes the same point about splitting AI agents: each split adds a boundary that someone must coordinate.
Platform capability is a prerequisite, not a consequence
Many organisations plan to build a platform after moving to microservices, once the pain makes the case. The order is usually wrong. If each new service needs a hand-built pipeline, hand-written alerts and a fresh set of secrets, the cost of every boundary is paid in full by the team that owns it.
Before the Supplier Desk would consider more than three deployable units, it set three platform prerequisites: a standard pipeline template that a new service can adopt in a day, a shared observability setup that propagates traces and dashboards by default, and a single way to issue and rotate service credentials. None of these needed a large platform team. They needed one person's sustained attention for a few months. Our articles on the case for platform engineering and graduating an internal developer platform set out how to build that capability deliberately.
Ownership must outlast contracts and reorganisations
In the public sector, and in many private organisations, the people who build a system are not always the people who will run it. Development is often contracted, contracts end, and the team that inherits the system may be smaller and less familiar with it. A design that was manageable for the builders can become unmanageable for the operators.
The Supplier Desk treats ownership durability as an architectural constraint. Each deployable unit must have an owner inside the department, not only inside a supplier's team, with documentation and runbooks the department holds. When the province reviews the development contract, the number of deployable units is part of the handover risk, because every additional service is something the next team must learn before it can safely change anything.
This is CloudNala analysis rather than a rule from any framework, but it follows directly from Conway's observation: if the organisation that runs the system will be smaller than the one that built it, the system should be shaped for the smaller organisation.
Questions for the next service proposal
- Which durable team will own this service for the next two years, and who is its named primary owner?
- Does that team have the on-call capacity and cognitive budget for one more production component?
- Which kind of coordination will the split replace, and which kind will it add?
- Is the team boundary itself stable, or is a reorganisation likely?
- Does the platform make the new service cheap to build, observe and secure, or will the team pay for all of that itself?
If the answers are weak, a new module with a clear owner gives most of the benefit at a fraction of the cost.
Key points
- A service boundary is a promise about who builds, runs, pays for and answers for a piece of software.
- Conway's law cuts both ways: boundaries that do not match durable teams create coordination, not independence.
- Count owners, on-call capacity and cognitive budget before counting services.
- Splitting into services changes the kind of coordination needed; it does not remove it.
- Platform capability is a prerequisite for many services, not something to build after the pain arrives.
Previous: Part 4, One database does not mean shared ownership. Next: Part 6, The distributed-systems tax nobody put in the business case. All parts are on the series page.
How CloudNala can help
CloudNala helps organisations align architecture with the teams that will run it. We map current and planned teams, on-call capacity and ownership against your modules and services, identify boundaries that have no durable owner, and set the platform prerequisites and evidence a new service must meet, so that your service count matches what your people can actually operate.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Complexity Review or write to us at consult@cloudnala.co.za