An architecture proposal often begins with a promise of greater independence. Teams will be able to change their products without waiting for a large release train, and a local improvement will no longer need to travel with unrelated work. That can be a valuable objective. I have also learned to ask which decisions should continue to be shared. A consumer product does not become more coherent simply because its interface has been divided into smaller components. The customer still encounters one commercial relationship, even when several teams and services contribute to it.
For a retail basket, some changes concern presentation, navigation or the explanation of an existing choice. Others alter the meaning of the offer or the conditions under which a customer can commit to it. A product team may be able to change the first category locally while the second requires a coordinated decision. I want that distinction available before we judge an architectural investment by the number of services extracted or the frequency of one team's releases. The useful measure begins with the changes the business needs and the responsibilities those changes cross.
## Start with the change a team needs to make
Our mobile-basket programme grew from a practical constraint: interface work was waiting for the website's six-week release train. Some proposed changes did not require the whole group of systems and teams to move together. We could improve that arrangement. At the same time, the basket relied on a shared calculation and final validation. Allowing a local component to carry its own competing interpretation of the commercial total would have created a different problem. The design needed to remove unnecessary coordination while preserving a clear authoritative boundary before the customer's commitment.
I approved sixteen weeks and €1.6 million for that work. The team separated selected interface concerns and made the shared service contract explicit. This was more than a rearrangement of files. It required an account of who owned the common behaviour, how a proposed change would be examined and what a product team could rely on when planning its own work. A diagram can show a service boundary without answering those questions. I wanted the operating responsibility to be part of the design, because the next difficult change would involve people making decisions as well as software exchanging requests.
The programme reviewed eighteen proposed interface changes. Fourteen could proceed without the full website release train under the new arrangement. Four still needed coordinated backend changes. The numbers described that set of work. They did not establish that the same proportion would hold for every future roadmap, and I did not convert them into a universal productivity improvement. The review nevertheless gave us something useful: a concrete account of the freedom gained and the work that remained dependent. Teams could use it to plan more accurately than they could use a broad declaration of independence.
## Count the changes that still need coordination
The sponsor preferred the simpler statement that the mobile basket was now independent. I wanted the four remaining dependencies in the account because they helped explain the architecture's purpose. Their existence did not invalidate the fourteen changes that could move differently. Equally, the useful progress in those fourteen did not justify pretending the other four were implementation details of no consequence. They represented decisions that crossed the chosen boundary. Recognising them allowed the product team to seek the right participation early instead of discovering the coordination requirement when the release date was already close.
There is a temptation to regard every retained dependency as unfinished transformation. I think that can lead to expensive designs whose apparent autonomy is purchased by duplicating decisions that should remain consistent. A shared calculation may be a deliberate responsibility, not merely a technical inheritance waiting to be removed. The question is whether the boundary serves the commercial product and whether its owner can support the teams relying on it. If a dependency creates recurring delay, we should investigate its cause. The answer might involve capacity, a clearer contract or a different policy, rather than another service split by default.
This is where the CTO's discussion with product leadership matters. A roadmap should distinguish changes that preserve the agreed commercial meaning from those that propose to change it. The latter need the relevant business owner even if the software is easy to alter. Conversely, a presentational change should not acquire unnecessary approval steps merely because it appears near a consequential calculation on the screen. Good boundaries help the organisation make both distinctions. They give teams room to act within an understood responsibility and a clear route when their proposal reaches beyond it.
## Keep ownership inside the design
The shared contract needs to remain useful after the initial programme. A new feature, a different channel or an amended offer can reveal assumptions that were reasonable for the earlier use. The responsible owner must be able to examine those requests without becoming an unexplained queue that product teams learn to evade. I want the review to address the meaning of the change, the affected consumers of the capability and the evidence required before it is introduced. That creates a continuing decision process around the boundary, rather than a document everyone reads once and then works around.
Ownership also includes explaining the cost of maintaining the capability. Product independence does not remove the engineering required to sustain shared behaviour or help teams use it correctly. If that work is omitted from the investment account, the architecture may look less expensive than it is and the responsible group may later struggle to meet its obligations. I ask for continuing capacity and review arrangements to be visible alongside the initial programme. This allows the executive team to judge whether the proposed freedom is supported by an organisation capable of keeping the shared commitments dependable.
For a board, the useful question is what the investment enables and what the company must continue providing to sustain it. Directors do not need to decide the internal service topology. They should be able to understand why management expects a different delivery pattern, which kinds of change remain coordinated and how the continuing obligations affect cost and risk. A short account of fourteen changes released differently and four still requiring shared work can support that conversation more honestly than an ambitious label whose meaning becomes less clear each time it is repeated.
My retrospective improvement is to classify likely contract changes when a product idea first enters discussion. That gives the team more room to decide whether the request belongs within an existing responsibility or needs a wider agreement. It also helps explain why some work can proceed quickly while another apparently small change needs deliberate coordination. I want an architecture to make those differences intelligible. Useful product freedom is the ability to act confidently within a boundary and to recognise when a decision must cross it. The quality of that boundary depends on whether the people responsible can explain and sustain it, long after the diagram has stopped being new.