Service Architecture

A Service Can Be Available and Still Not Deliver the Intended Outcome

Technical availability is only one dimension of service health. Customer outcomes also depend on controls, information, suppliers, ownership, operational readiness and governance remaining connected across the end-to-end service.

Technology availability is one of the most familiar measures of service health. Systems are monitored, incidents are counted, response times are measured and availability percentages are reported. If the applications are working and customers can transact, it is tempting to conclude that the service itself is healthy.

But a business service exists to deliver an outcome. That outcome may depend on technology, but it also depends on customer journeys, information, regulatory obligations, operational procedures, suppliers, controls, ownership and the people performing the work.

This distinction becomes increasingly important as organisations undergo significant transformation. Technology estates are becoming more interconnected, customer journeys more automated, regulatory expectations more demanding and suppliers more deeply embedded in service delivery.

Recent publicly available information from Admiral provides a useful illustration of why this wider perspective matters.

Transformation makes the operating environment more important

Admiral Group reported that during 2025 its UK Other Lines businesses completed the migration of More Than policies acquired from RSA while increasing customer numbers by 21%. Admiral also reported that the More Than integration had been completed and was contributing positively to the business. Source: Admiral Group, Full Year 2025 Results.

A migration of this type is more than a movement of policies or data between systems. It potentially touches customer communications, operational processes, technology, product rules, suppliers, support arrangements, controls, reporting and responsibilities.

This is why transition confidence is an architectural concern.

The question is not only whether data has migrated successfully or whether the target system is technically operational. It is whether the complete service can continue to deliver the intended outcome after the change: whether customer journeys still work as expected, operational teams are ready, controls remain effective, information is complete, suppliers understand their responsibilities and recovery arrangements remain viable.

Admiral's 2025 Annual Report reflects this broader view. It identifies transformation and change, technology, information security and cyber, resilience, data management and third-party management among its principal categories of operational risk. Source: Admiral Group Annual Report and Accounts 2025, p.99.

The controls described are similarly wider than conventional technical testing. For technology change, Admiral reports the use of performance and operational testing, rollback planning and business-readiness activities intended to support upgrades and minimise disruption. For material outsourced services, it describes regular risk assessments, supplier relationship management, initial and continuing due diligence, exit-plan testing and integrated business-continuity planning. Source: Admiral Group Annual Report and Accounts 2025, p.99.

These disciplines matter because transformation creates risk at the boundaries between things.

A technically successful change can still create an operational problem if people are not ready for it. A supplier can meet its own contractual target while the overall customer journey fails. A new system can process a transaction correctly while a required communication or control has become disconnected from the process.

Good service architecture provides the line of sight between those elements.

Availability is not the same as successful service delivery

A separate regulatory matter involving EUI Limited and Admiral Insurance Company Limited provides a useful way to consider this distinction.

The Competition and Markets Authority's breach register records that between 4 November 2024 and 3 January 2025, Admiral failed to provide 1,491 customers with the required No Claims Bonus protection statement and information at the point at which NCB protection was offered. The requirement arises from the Private Motor Insurance Market Investigation Order 2015. Source: Competition and Markets Authority, Register of breaches.

The CMA records that Admiral responded by offering refunds of the NCB protection payment to affected customers, introducing weekly management information to give senior management oversight of changes to customer communication scripts and peer reviews of those scripts, and improving procedures governing the scripts used when speaking with customers. The CMA added the matter to its breach register on 24 July 2025. Source: Competition and Markets Authority, Register of breaches.

This should not be interpreted as evidence of defective technology, nor does the public record establish that weaknesses in service architecture caused the issue.

What it does illustrate is that a service does not have to suffer an outage to produce the wrong outcome.

The customer-facing technology might be accessible. A quotation might be generated. An employee might be able to complete the transaction. The underlying infrastructure might report no availability problem at all.

Yet if a required piece of information, regulatory control or customer communication does not operate as intended within that journey, the resulting service outcome can still be incomplete.

Controls are part of the service

Governance controls are sometimes treated as something applied after a service has been designed.

In reality, important controls should form part of the service architecture itself.

If a customer must receive particular information before making a decision, that requirement forms part of the customer journey. The mechanism that provides the information, the data supporting it, the script or interface through which it is communicated, the person or system responsible for performing the action and the assurance mechanism confirming that it occurred are all components of the service.

Seen this way, regulatory requirements stop being separate compliance activities and become service requirements.

This changes the design conversation.

Instead of asking whether a policy exists requiring something to happen, service architecture asks where in the service it happens, who or what performs it, which information it depends upon, what evidence proves that it happened and what detects the situation when it does not.

The corrective actions recorded by the CMA are relevant in this respect. Greater oversight of scripts, peer review and management information create stronger visibility around whether the intended control continues to operate. Source: Competition and Markets Authority, Register of breaches.

The broader lesson is not specific to insurance. It applies wherever an organisation relies on regulatory disclosures, approval steps, customer communications, safety checks or other mandatory activities.

Service health needs a wider definition

Traditional technology dashboards are extremely useful. Availability, response time, transaction volumes, error rates and capacity all tell us important things.

But they do not necessarily tell us whether customers received the right information, whether a supplier performed an important control, whether a regulatory obligation was fulfilled or whether the expected benefit of the service is being realised.

A broader view of service health therefore considers whether the service can operate, whether people and suppliers can support it effectively, whether it produces the intended outcome and whether important controls continue to work as designed.

These dimensions become especially important during transformation because change can alter relationships that previously worked without anybody consciously thinking about them.

A new platform may change how a script is presented. A migrated product may use different data. Automation may remove a manual checkpoint. A supplier change may move responsibility for an important action. AI may introduce another decision point into a customer journey.

None of those changes is inherently problematic.

But each can alter the architecture of the service.

Governance should provide line of sight from requirement to outcome

This is where good service governance adds value.

Governance is sometimes associated with committees, approvals and documentation. Those mechanisms have their place, but its more commercially useful purpose is to maintain confidence that important decisions, controls and responsibilities remain connected to the service outcome.

There should be a clear line from a business or regulatory requirement to the design of the service, from that design to operational ownership, from ownership to an effective control and from that control to evidence that it continues to work.

Where that line becomes fragmented, an organisation can end up with individually sensible activities that no longer combine to deliver the intended end-to-end outcome.

This becomes particularly important where several teams or suppliers participate in the same service.

Each party may perform its own responsibilities correctly while an important hand-off between them remains unclear. The customer does not experience those organisational boundaries. They experience one service.

Good governance therefore needs to follow the service across those boundaries rather than stopping where departmental or supplier responsibilities change.

Transformation is ultimately about protecting the investment

Major migrations, new platforms, acquisitions, automation programmes and AI initiatives represent substantial investment. Their value is not realised when the technology goes live. It is realised when the resulting service can be operated successfully and continues to deliver the intended business outcome.

Admiral's reporting illustrates many of the disciplines associated with protecting that transition. Its Annual Report also states that the Board received updates during 2025 on work to enhance third-party risk management, including supplier due diligence, establishment of a third-party risk management forum and development of an enterprise-wide risk framework intended to support consistent application across the Group. Source: Admiral Group Annual Report and Accounts 2025, p.95.

These activities can sometimes appear less visible than the technology programme itself, but they are part of protecting the investment made in that technology.

They help answer commercially important questions.

Can the organisation operate the new service? Can it recover it? Can it change suppliers? Can it identify when an important control stops working? Does somebody own the end-to-end customer outcome? And can management see enough of the service to make informed decisions about it?

Those questions are not obstacles to transformation.

They are part of making transformation sustainable.

The service is more than the systems supporting it

The wider lesson is straightforward.

A healthy service cannot be defined solely by whether its systems are online.

Good service architecture connects technology with people, processes, suppliers, information, controls and customer outcomes. Good service design turns those relationships into something that can actually operate. Good governance provides continuing assurance that the assumptions made during design remain valid as the organisation changes.

The objective is not to create more governance around technology. It is to ensure that technology investment becomes a service that can be owned, operated, controlled, changed and relied upon.

A green technology dashboard is valuable.

But the more important question is whether the service behind it is still delivering what the organisation, its customers and its regulators expect.

Turn insight into action

Could the way your business works be simpler and clearer?

I provide an independent view of roles, workflows, systems, external partners and the structural issues that make a growing business harder to run than it should be.