The website agency is ready to proceed, the customer relationship management (CRM) supplier has proposed an integration and the payment provider has confirmed that its standard service is available. Each answer sounds reasonable.
The decision still cannot safely be made.
Nobody has established which system owns a person’s identity, what happens when a payment succeeds but the CRM update fails, or which supplier must investigate an incident that crosses two contracts. The organisation has bought capable parts, but the decisions between them remain unowned.
This is the architectural gap in an outsourced estate. It is not solved by asking suppliers to collaborate more closely. Suppliers should own their products and delivery. The organisation must own how those products combine to support its service, manage risk and remain changeable.
Architecture is a client decision function
Many membership and qualifications organisations do not need a full-time Chief Technology Officer or a permanent team of architects. Buying established platforms and specialist delivery can be entirely proportionate.
But buying the parts does not remove the need to decide how the whole will work.
Architecture, in this context, is not primarily a technical diagram. It is a continuing client-side function that connects organisational outcomes to technology choices, sets boundaries for identity, data, integration and security and resolves trade-offs spanning suppliers or departments. It makes support and change responsibilities explicit, records why material decisions were made and assures leaders that the resulting service is operable and supportable.
A supplier can advise on all of these matters. It cannot accept the organisation’s operational risk, decide its priorities or balance competing interests without clear client authority.
In project reviews, the architecture is often described as supplier-owned because one supplier drew the most complete system diagram. The diagram may be useful, but authorship is not ownership. Ownership sits with whoever has authority to decide, can explain the consequences and remains accountable after the supplier’s work ends.
Outsourcing changes who delivers the technology. It does not change who owns the consequences.
The decisions that fall between contracts
The costly gaps are rarely confined to one product. They appear where several reasonable local decisions produce an unreliable overall service.
Consider a membership renewal. The public website explains the offer. The portal authenticates the member. The CRM applies status and pricing rules. A payment service takes money. Finance reconciles it. Support must understand any failure.
Each component can work to specification while the renewal still fails. A duplicate identity might create the wrong price. A delayed callback might leave a successful payment marked unpaid. A manual correction might fix the CRM without reaching finance.
The organisation must decide how a person is matched across services and who resolves ambiguity, which system owns each important fact and how information moves between them. It must set access across the complete journey and make failure visible enough to recover.
The decisions continue into operation: who leads diagnosis before the source of a problem is known, who assesses a supplier change across the estate and who can accept the whole journey as ready.
It is common to find a detailed responsibility matrix for build activities but no owner for these decisions. The gap becomes visible late because delivery can continue for some time on assumptions.
The Client Architecture Function
A proportionate model starts with one named client-side role and a clear decision function. The role can be held by a suitably experienced internal leader, a fractional technology lead or an independent architect retained by the client. What matters is authority and continuity, not the employment model.
Its purpose is to bring specialist advice together, expose the consequences and ensure cross-service decisions reach an authorised conclusion.
The function connects the organisation to its delivery and operating partners:
| Function question | What a usable answer contains |
|---|---|
| What outcomes are protected? | The critical journeys, information and operating capabilities that decisions must support |
| Which decisions belong here? | Cross-system design, data ownership, integration, security, support boundaries and material exceptions |
| What may suppliers decide? | Product and delivery choices within agreed constraints, with escalation triggers |
| What evidence is maintained? | Current service map, decision record, dependency register, material risks and assurance results |
| When is escalation required? | A trade-off affecting outcomes, risk, cost, contractual boundaries or future flexibility |
| How does the role continue? | Named cover through procurement, delivery, transition, operation and major change |
If the function cannot identify an authorised decision-maker, it is only an advisory arrangement. Advice can improve a choice, but somebody on the client side still has to make it.
The Client-Control Test then checks whether this ownership is operating in practice across outcomes, priorities, decisions, evidence and acceptance.
Distinguish coordination from ownership
Project managers coordinate plans, actions, budgets and meetings. Service managers coordinate incidents and suppliers. Both roles are valuable. Neither automatically owns architectural decisions.
The distinction becomes clear when two suppliers disagree. A coordinator can obtain both views, arrange a workshop and track an action. The architecture owner must determine what evidence is needed, assess the organisation-wide consequences and make or route the decision.
Asking one supplier to act as lead integrator can help, provided its authority, commercial incentives and boundaries are explicit. The client still needs to assure the integrator’s recommendations and retain decisions that affect business risk or long-term control.
A pattern we often see is that the most technically confident supplier becomes the de facto decision-maker. This is rarely a deliberate transfer of authority. That supplier simply has the clearest view and the quickest route through ambiguity. Other teams begin to treat its assumptions as settled facts.
Good client ownership is not hostile to suppliers. It gives them stable constraints, timely answers and a route for resolving issues outside their remit. Capable suppliers generally perform better when they are not expected to make unowned business decisions.
Test whether the function is real
An organisation chart can name an owner without creating a working decision function. Use six recent or imminent decisions to test the arrangement:
- Which system holds the authoritative contact and membership status?
- Who owns recovery when a cross-system transaction partly completes?
- Who approves a design that reduces cost but increases manual support?
- Who assesses whether a supplier release could affect another platform?
- Who decides that an end-to-end journey has enough evidence for release?
- Who can explain the future exit route for data and integrations?
For each decision, record the accountable client owner, supplier advisers, options, evidence, consequence and date required. A blank owner exposes a governance gap. A named person without time or authority exposes a capacity gap. Six different unconnected owners may expose the absence of a whole-service view.
Another reliable sign is the decision log. Troubled projects can contain hundreds of delivery tickets while recording almost no architectural decisions. The decisions have still been made; they are simply hidden in workshops, email and configuration.
A service can be fully outsourced. Accountability cannot be.
Keep ownership through operation
Architectural ownership often receives attention during procurement and fades after launch. Yet operation creates new decisions: product releases, security changes, support failures, new services, contract renewals and requests to share data differently.
After launch, the architecture pack can remain with the closed project while service teams reconstruct the same dependencies during incidents and change requests.
The architecture owner should therefore maintain a small, current body of evidence rather than a large set of static documents: a service and dependency map that operational teams recognise, a record of material decisions and assumptions, named owners for authoritative data and cross-service support, known constraints and supplier boundaries and a forward view of changes that could affect more than one part of the service.
This material should be usable in a supplier meeting or incident, not only in an assurance review. If nobody can show how a failed journey crosses the estate, support will be negotiated during the incident.
Put the next decision through the function
Choose one material decision due in the next month, such as an integration design, a portal release or a contract commitment. Do not begin by asking which supplier owns it.
The revealing moment comes when everybody can name the suppliers involved but nobody can name the client who is authorised to settle the consequence.
Ask which organisational outcome is affected, who has authority to decide, which suppliers must advise, what cross-service evidence is needed and who will live with the consequence. Record the answer within the Client Architecture Function.
If that process cannot reach a clear client decision, the organisation does not yet own its architecture. It has suppliers, diagrams and coordination, but not the function that makes the complete service governable.
Where that ownership is needed on a continuing but part-time basis, our fractional technology leadership service provides a senior client-side function.