Technology programmes are created to deliver value. They may reduce operating cost, improve customer experience, enable growth, replace ageing platforms or introduce capabilities that were previously impossible. Yet delivering the technology is only part of the investment.
The organisation must still be able to operate what has been built.
That requires clarity over ownership, support, suppliers, dependencies, resilience, recovery expectations and the risks being accepted. It also requires sufficient evidence to determine whether the organisation is genuinely ready to take responsibility for the resulting service.
These activities can sometimes be perceived as governance surrounding technology delivery rather than part of the investment itself. The evidence suggests otherwise. Weaknesses in operational readiness, supplier assurance, service architecture and transition governance can have direct and substantial financial consequences.
Technical delivery is not the same as operational readiness
One of the clearest UK examples is TSB's 2018 technology migration.
The migration transferred TSB's corporate and customer services onto a new technology platform. The FCA and PRA reported that, while the data migration itself succeeded, the platform immediately experienced technical failures. All TSB branches and a significant proportion of its 5.2 million customers were affected by the initial disruption, and some customers continued to experience issues until December 2018. Source: Financial Conduct Authority, December 2022.
The financial impact was substantial. TSB reported £330.2 million of post-migration costs and foregone income in 2018, comprising £125.2 million of customer redress, rectification and associated remediation costs, £49.1 million of fraud and operational losses, £122.4 million of additional resource and advisory costs, and £33.5 million of foregone income. The bank reported a statutory loss before tax of £105.4 million in 2018, compared with a profit of £162.7 million in 2017. Source: TSB Bank, 2018 full-year results.
The FCA and PRA subsequently imposed combined penalties of £48.65 million for operational risk management and governance failures, including the management of outsourcing risks associated with the migration programme. The regulators said TSB had failed to organise and control the programme adequately and had failed to manage operational risks arising from its IT outsourcing arrangements with a critical third-party supplier. Source: Bank of England / PRA, December 2022.
The PRA later fined TSB's former Chief Information Officer £81,620. Its findings included a failure to ensure that TSB had obtained sufficient assurance from the key supplier about its readiness to operate the new platform before assurance was given to the TSB Board. Source: Prudential Regulation Authority, April 2023.
The significance is not that a Service Design Package, an Architecture Decision Record or any individual artefact would have prevented the failure. It is that supplier readiness, operational assurance and the evidence supporting a transition decision can have material commercial consequences.
Resilience is a business concern
This principle is increasingly reflected in UK regulation.
The FCA defines operational resilience as the ability of firms and financial-market infrastructure to prevent, adapt and respond to, recover from and learn from operational disruption. Firms within scope of its operational resilience rules had until 31 March 2025 to ensure that they could operate their important business services within their impact tolerances. Source: Financial Conduct Authority, operational resilience guidance.
In its March 2026 observations, the FCA said firms must identify and document the people, processes, technology, facilities and information needed to deliver each important business service, including third-party relationships that could threaten their ability to remain within impact tolerance. It also highlighted clear ownership and accountability for mapping data and the need to identify and remediate third-party vulnerabilities. Source: Financial Conduct Authority, March 2026.
The important point is the focus on the business service rather than on individual technology components.
A business service may depend on people, processes, applications, infrastructure, data and external suppliers. Each individual component may appear adequately managed while the end-to-end service remains exposed.
A supplier may meet its contractual target while the complete service fails the recovery requirement expected by the business. A database may be technically available while customers are still unable to complete a transaction. A single external dependency may support several supposedly independent services.
Good service architecture provides the context needed to understand those relationships.
Smaller businesses are exposed too
The absolute financial consequences of failure are naturally greater for large banks, airlines or financial institutions, but dependency on digital services is widespread among smaller organisations.
The UK Business Data Survey 2026 found that 59% of businesses handling digitised data stored or processed data away from their premises. Among those businesses, 20% said they had been affected by a server or cloud outage or downtime during the previous twelve months. The proportion was 27% among micro businesses, 31% among small businesses, 28% among medium-sized businesses and 58% among large businesses. Source: UK Business Data Survey 2026.
The same survey found that 31% of businesses handling digitised data used a public cloud provider and 22% used a third party through software or a web solution. Reliance on externally provided technology is therefore not confined to large enterprises. Source: UK Business Data Survey 2026.
A small organisation does not need the same level of governance as a major bank. The approach should be proportionate. The underlying operational questions, however, remain the same.
What does the business depend upon? What happens when that dependency fails? Who owns the response? What does the supplier provide? How long can the business tolerate disruption? Are the expectations realistic?
For a smaller organisation, the financial impact of an outage may be lower in absolute terms, but disruption can still consume scarce management time, interrupt revenue-generating work and expose a greater proportion of the organisation's available capacity.
Governance can protect the investment itself
There is also evidence that stronger challenge and governance around technology expenditure can create measurable financial value.
The National Audit Office reported in 2017 that Government Digital Service controls over technology spending and service design were estimated by GDS to have reduced government IT expenditure by £1.3 billion over the five years to April 2016. The same report noted mixed results across transformation programmes: in a 2015 lessons-learned exercise, GDS identified positive net present value for only 12 of the 22 programmes for which data were available. Source: National Audit Office, Digital Transformation in Government, 2017.
The £1.3 billion figure cannot reasonably be attributed to service design alone. Spending controls, procurement approaches and wider governance contributed. The broader point is more important: disciplined challenge around technology investment can affect both what organisations spend and the value they obtain from that spending.
Technology investment does not become valuable simply because a programme reaches completion.
The organisation still needs to understand whether what has been created is economically sensible, operationally viable and capable of delivering the outcome for which the investment was approved.
Current GOV.UK service-design guidance reflects this end-to-end perspective. It says that, before building or improving a service, teams should understand it from beginning to end, including work done by external suppliers, and from front to back, including the internal processes, software, data and policies behind the user-facing service. Source: GOV.UK Service Manual.
That is a fundamentally different proposition from completing operational documentation shortly before go-live.
Many serious outages may be avoidable
International research reinforces the case.
Uptime Institute's Global Data Center Survey 2025 reported that 87% of respondents who had experienced an impactful outage in the previous three years said it could have been avoided through better management, processes or configuration. The figure was based on 98 respondents who had experienced a significant, serious or severe outage. Source: Uptime Institute Global Data Center Survey 2025.
The same Uptime research illustrates the financial scale of the incidents in that sample. Among 94 respondents estimating the cost of their most impactful significant, serious or severe outage, 37% placed the cost between $100,000 and $1 million and 18% placed it above $1 million. Source: Uptime Institute, 2025 outage survey summary.
This does not imply that disruption can be eliminated. Complex technology will fail, suppliers will experience problems and unexpected events will occur.
What it suggests is that the severity of many failures is influenced by the quality of the operating environment surrounding the technology.
Clear responsibilities, tested recovery arrangements, effective change control, realistic supplier commitments, known dependencies and appropriate escalation routes can all affect whether a technical problem remains manageable or becomes a major business event.
That is where architecture, design and assurance become economically relevant. They create opportunities to expose weaknesses while the organisation still has choices.
Failure becomes expensive when weaknesses remain hidden
The experience of US trading firm Knight Capital provides an extreme example.
In August 2012, a software deployment problem caused Knight's automated routing system to send more than four million orders into the market while attempting to fill 212 customer orders. During approximately 45 minutes, Knight traded more than 397 million shares, accumulated several billion dollars of unwanted positions and ultimately suffered a loss of more than $460 million. Source: US Securities and Exchange Commission, October 2013.
The SEC's order identified deficiencies in controls and procedures around automated market access. Its public statement also recorded that 97 automated emails were generated before the market opened, referencing the router and identifying an error associated with the deployment failure, but were not acted upon that day. Source: US Securities and Exchange Commission, October 2013.
The commercial lesson is not confined to financial trading.
Technology exists within a wider operating system of governance, testing, responsibilities, escalation and controls. Weaknesses within that surrounding environment can determine whether a technical fault is quickly contained or allowed to develop into a serious financial and operational event.
The timing of risk matters
This is perhaps the strongest economic argument for good service architecture.
Its value is not based on making failure impossible. It comes from discovering contradictions, gaps and unrealistic assumptions while they are still comparatively inexpensive to address.
A recovery requirement that cannot be met is cheaper to discover during design than during an outage. An unclear ownership model is easier to resolve before transition than during a major incident. An undocumented critical dependency is more useful when identified before a change than after it has caused another service to fail.
The same principle applies to important design decisions.
An organisation may deliberately choose a lower-cost supplier despite a weaker recovery commitment. It may accept a particular architectural constraint because improving it would require disproportionate investment. It may decide that a particular residual risk is commercially acceptable.
Those can all be legitimate decisions.
The problem arises when the rationale is not recorded, the consequences are not understood or the assumptions supporting the decision subsequently change without the original choice being reconsidered.
This is where Architecture Decision Records, controlled service baselines, dependency models and evidence-based approval can provide value. Their purpose is not to generate additional paperwork. It is to make significant decisions and compromises visible to the people accepting their consequences.
Service architecture has an economic purpose
It is difficult to assign a universal return on investment to service architecture, and it would be misleading to claim one.
The financial value depends on the organisation, the service, the scale of the investment and the risks involved.
For one programme, the value may come from avoiding several weeks of expensive remediation after a delayed transition. For another, it may come from identifying an incompatible supplier commitment before a long-term contract is signed. Elsewhere, it may mean recognising that a service lacks an accountable owner, workable support model or credible recovery arrangement before responsibility transfers into live operation.
The evidence does, however, support a consistent conclusion. Operational failure can carry substantial financial consequences, weaknesses in governance and supplier assurance have featured in documented failures, organisations of all sizes are increasingly dependent on interconnected technology, and industry research indicates that many impactful outages are considered avoidable through better management, processes or configuration.
Good service architecture therefore creates an opportunity to identify those weaknesses while the organisation still has choices.
A recovery requirement that cannot be achieved, an unowned service, an undocumented dependency or an unsupported supplier assumption is far less expensive to discover during design than after customers, revenue and operations depend upon it.
This is why service architecture should not be regarded simply as documentation surrounding technology delivery. It is part of protecting the investment itself.
The purpose is ultimately straightforward: to establish, before responsibility transfers into live operation, whether the resulting service can genuinely be owned, supported, governed, recovered and operated as the business expects.
The most expensive point at which to discover that it cannot is after go-live.