Stage 1 summary. Foundations

Gartner's glossary separates the first two cleanly. Digitisation converts something from analogue into digital form. Digitalisation uses digital technologies to change a business model and create new revenue and value opportunities. Digital transformation is the larger move in which the operating model, the proposition and often the organisation's identity change together. The three sit in a ladder, and each rung has an evidence test you can apply without asking the sponsor what they intended.

The tests are behavioural. If the artefact changed format but the process, the roles and the decisions stayed as they were, that is digitisation. If the process itself was redesigned around what digital data makes possible, so that work is done differently and by different people, that is digitalisation. If the answer to what the organisation sells, or who it serves, or how it makes money has moved, the change is transformational. Applying the tests to the British Library, HMRC and Ocado gives three organisations at three different rungs, which is why the cases are taught together.

AI adoption is not a fourth rung. It is an accelerant that operates at each of the three levels, speeding up conversion, redesign and reinvention alike, and it changes the pace rather than the taxonomy. Maturity models are a related trap: choose a frame that answers the question being asked, rather than defaulting to the one vendor model you happen to know, because a maturity score computed from the wrong frame produces confident and useless direction.

Drivers come in families rather than as a list: regulatory pressure, cost and productivity pressure, customer and citizen expectation, capability supply as tooling and models become cheap, and competitive or ecosystem pressure from platforms that already operate this way. Each family needs its own evidence for the organisation in front of you, because a driver that is decisive in a regulated utility may be irrelevant to a subscription retailer.

COVID-19 belongs in the history. It compressed adoption timelines that were already moving, and McKinsey's tipping-point work documents how far and how fast. What it does not do is explain a 2026 investment decision, and a business case that leans on it is leaning on a driver that has already been spent. The current drivers are the post-2023 ones, which is why the stage insists on dating the evidence.

A specific discipline attaches to failure statistics. Headline claims that most digital transformations fail circulate without their definitions attached, and the honest question is always what the study counted as a transformation, what it counted as failure, over what period, and who paid for the research. PESTEL is the structured way to assemble the picture for one organisation, and its value comes from filling the rows with dated 2026 evidence rather than with generalities.

Underneath any digital service sits a small set of block classes: compute and hosting, data storage and movement, integration, identity and access, the presentation and channel layer, and the observability that tells you whether any of it is working. Naming the classes matters more than naming products, because products churn and classes do not, and a design conversation held in classes survives the next procurement.

Cloud is best described on the NIST definitions in SP 800-145, which set out the essential characteristics and the three service models. Infrastructure as a service supplies the raw compute and storage, platform as a service supplies a managed runtime, and software as a service supplies the finished application, with the boundary between what the provider operates and what you remain accountable for shifting at each step. The 2026 additions to the list are foundation models, which have become a purchasable block rather than a research artefact, and identity wallets, which turn verified attributes into something a service can consume.

DevOps is deliberately excluded from the block list. It is the connective practice that determines how quickly and how safely the blocks can be assembled and changed, and treating it as a block invites the mistake of buying a tool and declaring the practice adopted. The same reasoning applies to platform choices, where the build, buy and partner decision is a question about which blocks you want to own the consequences of.

The argument for data standards is not aesthetic. Two systems that describe the same real-world thing with different identifiers, units or code lists cannot be joined without a reconciliation exercise that costs money every time it runs, and interoperability failures are where that cost becomes visible. The UK position is set out in the Open Standards Principles and carried into practice by the Data Standards Authority, and the point of both is that a standard chosen once removes a translation cost paid forever.

Open and proprietary formats differ in their exit cost rather than in their quality. An open format has a published specification anyone may implement, so the data outlives the tool that produced it. A proprietary format ties readability to a supplier relationship, and the consequence appears years later when the supplier is replaced or withdraws the product. Master data management governs the entities the organisation shares across systems, such as customers, sites and assets, while reference data management governs the controlled lists those entities are described with, and the two need different owners because they fail in different ways.

Standardised data is now a legal expectation rather than good practice. The Data (Use and Access) Act 2025 creates the machinery for smart data schemes in which regulated holders must release customer and business data to authorised third parties, and in the European Union the Data Act, in force since January 2024 and applying from 12 September 2025, gives users a right of access to the data their connected products generate and sets the framework for switching between data-processing services.

A platform business does not primarily produce value itself. It reduces the cost of an interaction between two or more groups and takes a position in that interaction, which is why its economics improve as participation grows and why its defensibility comes from the network rather than the software. Network effects are directional, and a platform whose value only rises for one side has a growth problem the technology cannot fix.

Journey mapping is the practical instrument. Laying out what a person is actually trying to achieve, step by step, exposes the handovers where a service asks the user to carry information between systems that should have exchanged it themselves, and every one of those handovers is an API touchpoint waiting to be designed. API-first design means the interface contract is agreed before the implementation, so consumers can build against it, and the gateway pattern gives a single place to enforce authentication, apply rate limits and observe traffic without scattering that logic through every service.

The GOV.UK Service Standard connects the two halves. Point 13 requires teams to use and contribute to common standards, components and patterns rather than rebuilding them, and point 14 requires the service to be operated reliably once it is live. Read together they say that a journey is only designed when the shared components it depends on and the operational commitment behind it have both been decided.

A digital risk taxonomy is the starting artefact because it forces the organisation to say what it is exposed to before it argues about controls. The usual families are delivery risk, operational and resilience risk, security risk, data protection risk, supplier and concentration risk, and the regulatory risk that sits across all of them. Naming them separately stops a single risk register entry from absorbing everything and hiding it.

The three governance domains are often collapsed into one committee and should not be. IT governance decides how technology assets are run and funded, with ISO/IEC 38500:2024 giving the principles for governing IT at board level. Data governance decides who owns which data, what quality it must meet and on what basis it may be used. Digital governance decides which services exist, who is accountable for their outcomes, and how investment is prioritised. Boards remain accountable throughout, and the three-lines model separates the people who own and manage risk, the people who oversee it, and the people who provide independent assurance.

Two duties are design-time and legal rather than best-effort. Data protection by design and by default is an obligation under the UK GDPR, which means privacy has to be settled while the service is being specified. Accessibility is set by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which require public sector sites and apps to meet WCAG 2.2 level AA and to publish an accessibility statement. Neither can be retrofitted cheaply, which is why both belong in the governance conversation at the start.