Technology change is often judged by whether the technology itself works. A new platform has been implemented, a supplier has delivered its scope, testing has completed and the project has reached its planned milestones. Yet none of those things necessarily mean that the resulting service is ready to operate, capable of delivering the expected business value or sufficiently resilient once the project team steps away.
That distinction sits at the heart of my work.
I design the operating model behind technology-enabled business services, turning strategic intent and technical change into something that can be owned, supported, governed and transitioned into live operation with confidence.
My focus is not on implementing the technology itself. It is on ensuring that the organisation surrounding that technology is capable of operating it successfully and protecting the investment that has been made in it.
Technology delivery is not operational readiness
That means looking across the whole service environment. Who owns the service? Who supports it? What happens outside normal working hours? Which suppliers are involved and what are they actually committed to provide? What dependencies could prevent recovery? What does the business expect in terms of availability and resilience? Are those expectations consistent with supplier capability? Who takes control during a major incident? What evidence demonstrates that the organisation is genuinely ready to accept responsibility?
These questions are often distributed across project plans, contracts, architecture diagrams, spreadsheets, emails and conversations. Sometimes the answers exist but are inconsistent. Sometimes responsibility has been assumed rather than agreed. Sometimes a service appears ready until somebody compares a business recovery objective with a supplier commitment and discovers that they do not align.
A documentation gap can become an operational and commercial risk
That is not simply a documentation problem. It is an operational and commercial risk.
A technology programme may represent several million pounds of investment, but the value of that investment is exposed if the resulting service cannot be supported, recovered, governed or managed effectively. A technically successful implementation can still result in delayed transition, unexpected operating cost, supplier disputes, emergency remediation or a service that fails to deliver the business outcome originally expected.
My role is to bring those separate elements together and design a coherent operating model around the technology.
Technology, people, suppliers, processes, responsibilities, governance, support arrangements and resilience all need to work as a whole. A service can be technically sound and still be operationally fragile. The purpose of the work is to identify that fragility before it becomes expensive.
Bring operational thinking forward
One of the biggest opportunities is to bring operational thinking much earlier into technology change.
Too often, the question of how something will actually be run is left until late in delivery. The project has momentum, contracts have been agreed, technical decisions have already been made and the planned go-live date is approaching. At that point, organisations can find themselves trying to close operational gaps under considerable time pressure.
A better approach is to treat operational viability as part of the design from the outset.
That allows difficult questions to be asked while there is still time to do something about the answers. If the business requires a two-hour recovery time but a critical supplier can only recover within four hours, the issue should be exposed before go-live. If a service has no clearly accountable owner, no workable escalation route or insufficient evidence of operational readiness, those conditions should be visible before responsibility transfers into BAU.
This improves transition confidence because the decision to proceed is based on evidence rather than assumption.
Strengthening supplier accountability
It can also strengthen supplier accountability.
Modern services are frequently dependent on multiple external providers, cloud platforms and managed services. Each supplier may be performing exactly to its own contract while the end-to-end business service still fails to meet what the organisation requires.
Looking at suppliers individually is therefore not enough.
Their commitments need to be understood in the context of the complete service. Recovery obligations, support hours, escalation arrangements, dependencies and responsibilities need to align with the business outcome. Where they do not, the organisation needs to understand the exposure and decide whether to remediate it, renegotiate it or consciously accept the risk.
This is where service architecture creates commercial value. It provides a way of connecting technology decisions, supplier commitments and operational capability back to the business requirement they are meant to support.
From document-led design to a structured operating model
My approach also differs from traditional document-led methods.
A substantial design document may describe a service in considerable detail, but the existence of the document does not prove that the design is complete, internally consistent or operationally viable. Important facts can be repeated in several places, become out of date or contradict one another without anybody noticing.
I increasingly treat the operating model as structured information that can be tested.
That thinking led me to develop ServiceDriven, a platform I use to support my service architecture work. It allows ownership, suppliers, dependencies, support models, resilience requirements, readiness evidence and other design information to be captured once and reused throughout the service model.
The purpose is not to replace professional judgement with software. It is to make that judgement more consistent, evidence-based and repeatable.
If there is a conflict between a business recovery requirement and a supplier commitment, the discrepancy should be visible. If ownership is unclear, the gap should be visible. If transition is approaching but key operational evidence is missing, that should be visible too.
The technology helps expose those conditions. The value comes from understanding what they mean in terms of risk, cost, accountability and business impact.
It also changes the nature of the traditional Service Design Package.
Rather than repeatedly asking people to enter the same information into different sections, the underlying service model becomes the source of truth. Information about suppliers, resilience, support, ownership and dependencies can flow through the design automatically. The resulting package becomes an output of a structured design process rather than the process itself.
Protecting value realisation
For organisations, this can create greater clarity and better decision-making.
Projects gain a clearer definition of what needs to exist before transition. Operational teams receive a service that has been designed with their needs considered rather than simply handed over when technical delivery finishes. Suppliers can be assessed against business requirements rather than viewed in isolation. Service owners gain greater visibility of the responsibilities they are accepting. Governance forums have evidence upon which to base approval decisions.
There is also a direct value-realisation dimension.
Technology investment only creates value when the resulting capability can be absorbed into the organisation and operated effectively. If a new platform repeatedly fails, cannot be recovered within business expectations, requires unplanned manual intervention or depends on responsibilities that nobody has accepted, the expected value of the investment is diminished.
Good operating-model design protects that value by addressing the conditions required for successful operation before they become expensive problems.
It does not guarantee that incidents will never occur. No design can do that. What it can do is improve the likelihood that ownership is understood, escalation routes exist, recovery assumptions are realistic, supplier obligations are visible and operational teams know how the service is intended to work.
A design that survives go-live
There is also a longer-term benefit.
Once a service has been properly modelled, the design should not disappear into an archive after go-live. It can become a controlled baseline against which future change is assessed.
A supplier change, architectural alteration, new dependency or revised recovery requirement can then be compared with the approved operating model to understand its wider impact. This allows organisations to ask not simply whether a proposed technical change can be implemented, but whether it changes the operational or commercial characteristics of the service.
That becomes increasingly important as technology environments become more complex.
Cloud services, managed platforms, interconnected suppliers and AI or agentic services can introduce new dependencies, ownership questions and operational risks. The technology may evolve quickly, but the fundamental management questions remain familiar: who is accountable, how is the service supported, what happens when it fails, what does it depend upon, and can the organisation live with the risk it is accepting?
My proposition is therefore relatively straightforward.
I help organisations make technology change operable.
I do that by designing the operating model around the technology, challenging assumptions, connecting technical and operational perspectives, testing supplier and resilience commitments, identifying gaps and conflicts, and providing a structured basis for approval and transition.
The outcome is not simply a better document.
It is greater confidence that technology investment can move from project delivery into sustainable operation without avoidable surprises, that suppliers and internal teams understand their responsibilities, and that decision-makers can see the operational and commercial risks before they accept them.
That is ultimately where service architecture earns its value: not in describing technology, but in helping an organisation protect its investment, realise the intended value and successfully live with what it has built.