Stage 3 summary. Strategy, trust and sector
Strategy, trust and sector raises the same engineering questions to the level where they are decided by money, law and other organisations. A roadmap is a set of promises about sequence that a finance director will hold you to. An operating model decides which teams can move without asking permission. A data-sharing arrangement between organisations is a legal instrument before it is a pipeline. And in a regulated sector, what good looks like is written down by somebody else.
The stage closes on the GB energy system, the worked example of every earlier idea at once: a regulator setting data expectations, licensed companies publishing plans against them, a shared infrastructure being built between them, and an industry-wide settlement migration running underneath.
What you carry out of this stage
- Choose a strategy frame fit for the question, build a roadmap whose dependencies are honest, and construct a business case with benefits a finance director will accept
- Explain the project-to-product shift and its funding consequence, and apply the four team types and three interaction modes to a real organisation chart
- Navigate the UK data governance landscape after the Data (Use and Access) Act 2025, including when recognised legitimate interests is and is not available
- Determine which cyber, resilience, safety, accessibility and identity regimes apply to a described organisation, and use the Cyber Assessment Framework as an assessment frame
- Assess lock-in risk, design an exit before it is needed, and apply the Digital Markets Act and Data Act switching rights to vendor strategy
- Measure transformation value with benefits realisation discipline, quantify legacy risk, and handle failure statistics by saying what each one actually measured
- Describe the GB energy digitalisation governance stack, apply the presumed-open triage to a dataset, and walk market-wide half-hourly settlement as an industry-wide data migration
Digitalisation course visual spine
The three stages name the parts, then build and run the systems, then decide what to build and with whom, which puts strategy last and makes it reachable only once the distinctions and the operating disciplines are in hand.
Foundations names the things. Applied builds and runs them. Strategy decides what to build, with whom, and how value is realised. The spine is the route a learner takes through the course.
A roadmap is a sequence argument, and the business case is where it becomes accountable
Strategy frames are instruments, not identities. A frame that maps competitive position answers a different question from one that maps capability gaps or customer jobs, and the failure mode is reaching for whichever frame you know rather than the one that fits. The now, next and later structure works because it separates commitments from intentions: now is funded and staffed, next has a stated dependency that must clear first, and later is a direction that has not yet earned a date.
Honest dependencies are what make a roadmap survive. Most roadmap failures are sequencing failures rather than estimation failures, where two items were drawn in parallel that could not run in parallel, or a foundational item was pushed right because it had no visible customer. The business case is where this gets tested, because a finance director asks who is accountable for the benefit and when it lands in a budget line. Benefits that nobody owns in a budget are not benefits.
Change does not end at go-live. The Government Digital Service story is instructive because it was not a single delivery: GOV.UK launched in October 2012 in place of Directgov and Business Link, and the durable output was a standard and a way of working, in the Service Standard and the Technology Code of Practice, that outlasted any individual service.
12 month roadmap with dependencies
Each bar ends in a gate naming its evidence, quality SLAs live, two services migrated, auth and limits enforced, and dashed arrows chain only some, data foundations to platform v1 to the gateway and self-service, then legacy retirement, so a slipped gate moves the bars behind.
A roadmap is sequenced commitments with evidence gates, not a list of wishes. Each bar's right edge is the next bar's left edge for a reason. GOV.UK Service Manual; Kotter (2012); DORA.
Product funding, four team types, and a platform that has to be worth choosing
The project-to-product shift is a funding change disguised as a delivery change. Projects fund a scope for a period and disband the team, so knowledge leaves and what was built becomes somebody else's maintenance problem. Product funding sustains a team against an outcome and re-decides the level each planning cycle. The consequence lands on finance and governance rather than engineering, which is why the shift stalls when only engineering is asked to change.
Team Topologies gives four team types and three interaction modes. Stream-aligned teams follow a flow of work from a segment of the business domain and do most of the delivery. Enabling teams help them over obstacles and detect missing capability. Complicated-subsystem teams exist where deep specialist expertise is genuinely required. Platform teams provide an internal product that accelerates the stream-aligned teams. The modes are collaboration for a bounded period of discovery, x-as-a-service where one team consumes what another provides, and facilitation where one team mentors another. Applied to a real organisation chart, the model usually reveals permanent collaboration where an x-as-a-service relationship should have formed.
Platform engineering follows from that. An internal platform is a product with users who can decline to use it, which is the distinction between a platform and a portal: a portal is a place to find things, while a platform provides paved paths that are genuinely faster than the alternative. That quality is where AI value comes from, because the returns follow the surrounding system rather than the tools. Skills frameworks such as SFIA name the capabilities an operating model needs rather than leaving them implied in job titles.
Lawful basis first, sharing structure second, and recognised legitimate interests is narrower than it sounds
The Data (Use and Access) Act 2025 reshaped the UK landscape without replacing the UK GDPR, so the discipline is still to choose a lawful basis before designing anything, and to choose it for the specific processing rather than for the organisation. The Act adds recognised legitimate interests as a further basis alongside the six in the UK GDPR, and its scope is the point: it applies to a defined list of purposes, and where it applies the balancing test is not required, while everything outside that list still runs on ordinary legitimate interests with the balancing test intact. Treating it as a general shortcut is the error the ICO guidance is written to prevent.
Sharing structures answer a different question, which is who holds the data and who decides. A data trust puts an independent trustee between the holders and the users, bound to a stated purpose. A data cooperative gives the people the data is about collective control over its use. Federated analysis moves the computation to the data, which is often the only workable answer when the barrier is legal rather than technical. Each needs a data-sharing agreement naming controllers, purposes, retention and the exit.
Two parallel tracks are making sharing an obligation rather than an option. In the UK, smart data schemes under the 2025 Act let government require regulated holders to release customer and business data to authorised third parties, sector by sector. In the European Union, the Data Act has applied since 12 September 2025, giving users access to the data their connected products generate. On enforcement, attribution matters: UK data protection penalties come from the ICO while headline European fines are issued by named national supervisory authorities, and citing the wrong one discredits an otherwise sound argument.
Cross-organisation data-sharing trust model
Trust here is only what both parties can check: a key pair, a use-case register, a consent record, a schema and an immutable log, one for each of the five pillars, published and verified before any data crosses rather than asserted by one side.
A trusted data exchange is a governance system, not a file transfer. Five pillars (identity, purpose, consent, data model, audit) need an artefact each party publishes. UK Digital Identity and Attributes Trust Framework (identity-scoped); Ofgem Data Best Practice; W3C DIDs.
Which trust regimes bite depends on what the organisation is, not on how digital it feels
The regimes are separate and their triggers differ. The Cyber Security and Resilience Bill, introduced to Parliament on 12 November 2025, reforms the UK Network and Information Systems Regulations 2018 to cover essential and digital services more widely. It is a reform of the UK regime, not an implementation of the European Union's NIS2, so its notification clocks and penalty levels have to be read from the Bill and its published factsheets rather than assumed from the European text.
The NCSC Cyber Assessment Framework is the assessment instrument sitting under the UK regime, currently at version 4.0, organised around managing security risk, protecting against cyber attack, detecting cyber security events and minimising the impact of incidents, with basic and enhanced profiles that set the target according to the threat an organisation faces. Used properly it produces an evidenced position and a gap list rather than a score to report upwards.
Three further regimes complete the picture. The European Union's Digital Operational Resilience Act governs operational resilience for financial entities and their critical technology providers, and shares nothing but an acronym with the DevOps research programme from Stage 2. The Online Safety Act 2023 places duties on user-to-user and search services, enforced by Ofcom and brought into force in phases. Accessibility binds public sector sites and apps to WCAG 2.2 level AA under the 2018 regulations. Digital identity is the trust infrastructure underneath: the UK digital verification services trust framework sets the rules a provider is certified against, so a relying party can accept a verified attribute without running its own checks.
Lock-in is a cost you agree to at signature and discover at exit
Ecosystem roles are worth naming before economics are argued: the orchestrator that sets the rules, the complementors that build on them, the customers whose participation makes the network worth joining, and the enablers who supply the underlying capability. Value accrues to whoever controls the point of interaction, which is why the interesting question about a partnership is who owns the customer relationship and the data it generates rather than what it costs.
Lock-in has three components that need pricing separately. Data lock-in is whether your data leaves in a form another system can read. Operational lock-in is whether your processes have been shaped around one supplier's model. Contractual lock-in is what the agreement says about notice, egress charges and transition assistance. An exit written at signature costs a negotiation; one written after the relationship breaks down costs a programme.
Regulation has moved in the buyer's favour and should be used. The Digital Markets Act, Regulation (EU) 2022/1925, imposes obligations on designated gatekeepers in core platform services, and the Data Act sets the framework for switching between providers of data-processing services. Build, buy and partner decisions then turn on which capability is genuinely differentiating, and sovereignty questions about where data rests and which jurisdiction can reach it belong in the same decision rather than in a later compliance review.
Vendor lock-in and exit strategy
Each of the five surfaces carries a status badge and the next ask in negotiation, and Evidence alone reads OPEN while cost is the one CLOSED, so the exit-cost cap leads the renegotiation and portability, capability and switching time each still carry an ask of their own.
A good vendor strategy tests portability, evidence, cost, capability, and switching time per surface. Any red surface is the next term to renegotiate. Open Group; ISO 19770; CCS.
Benefits have owners, legacy has a quantifiable risk, and failure statistics have definitions
Benefits realisation tracks a claimed benefit past the point where the programme closes. That requires a baseline measured before the change, a named owner in a budget line, a date, and a review that happens after the delivery team has moved on. Most claimed value evaporates not because the change failed but because nobody was accountable for collecting it once attention moved elsewhere.
Technical debt becomes useful when it is quantified, and Fowler's framing separates deliberate debt taken for a reason from the accidental kind. The quantities that matter are the interest payments: additional effort per change, incident rate attributable to the component, and the number of people who can safely work on it, which is often the sharpest legacy risk of all. The strangler approach, routing slices of traffic to a new implementation while the old one keeps running, is the migration pattern that lets you stop halfway, and governing a migration means deciding in advance what would make you stop.
Cost and carbon belong in the same measurement conversation as delivery, because cloud spend and energy consumption are both consequences of architecture decisions that stay invisible until someone reports them per service. Failure statistics need the discipline from Foundations: when a claim about transformation failure rates appears, say what that study counted as a transformation, what it counted as failure, and over what period, because the honest version is almost always narrower and more useful than the headline.
Legacy migration with a strangler path
The middle snapshot runs legacy and replacement at the same time, and the criteria band puts an explicit retirement criterion on every slice, so without one the migration stops at that middle picture with both bands still funded.
A strangler approach retires legacy slice by slice. Each slice needs ownership, tests, rollback, and retirement criteria; without the retirement criterion legacy stays alive for years. Fowler (2004); Newman (2019).
The GB energy stack: a regulator sets the expectation, licensees publish the plan, the sector builds the pipes
The GB governance stack has clear layers. Government sets direction through the Energy Digitalisation Framework. Ofgem sets licence expectations through Data Best Practice guidance and Digitalisation Strategy and Action Plan guidance. Licensed network companies and the system operator publish their own plans against that guidance, with NESO's Sector Digitalisation Plan and its Digitalisation Strategy and Action Plan showing what the output looks like. Knowing which layer a requirement comes from stops a licence obligation being argued as if it were a preference.
Data Best Practice puts the burden of proof on withholding. A dataset is presumed open, and any restriction has to be justified against a stated harm such as personal data, security or genuine commercial sensitivity, applied to the narrowest part of the dataset that carries the harm rather than to the whole file. Assessing an action plan against the guidance means checking that the presumption was applied, that the catalogue is discoverable, and that the commitments carry dates. The Data Sharing Infrastructure is the sector-level answer to discovery and exchange between parties who do not share systems, delivered incrementally rather than as a single switch-on.
Market-wide half-hourly settlement makes all of this concrete. It moves electricity settlement onto actual half-hourly consumption data, and its milestone ladder runs from central systems readiness through long migration windows for different meter types to full migration and then the switch to the new settlement timetable, at which point the settlement runs compress. Ofgem's final impact assessment estimated net consumer benefits of between 1.5 billion and 4.5 billion pounds by 2045. Digital twins and flexibility markets sit on the same data foundation, which is why sequencing matters: settlement-quality data first, then the applications that assume it.
The traps this stage warns against
Drawing a now, next and later roadmap where next and later are simply the items that did not fit into now.
Instead: Each item beyond now needs a stated dependency that must clear before it starts. A roadmap without dependencies is a wish list sorted by preference.
Announcing a move from projects to products while leaving annual scope-based funding untouched.
Instead: Product operating models are a funding change. If money is still allocated to a scope for a period, teams will still disband when the scope is delivered, whatever they are called.
Reaching for recognised legitimate interests because it removes the balancing test.
Instead: It applies only to the defined list of purposes in the Data (Use and Access) Act 2025. Outside that list you are on ordinary legitimate interests and the balancing test still applies.
Reading the Cyber Security and Resilience Bill as the UK version of NIS2 and importing its clocks and penalties.
Instead: The Bill reforms the UK Network and Information Systems Regulations 2018 on its own terms. Take notification timings and penalty levels from the Bill and its factsheets, not from the European regime.
Negotiating an exit clause when the supplier relationship has already failed.
Instead: Price data, operational and contractual lock-in at signature and write the exit then, while you still have commercial leverage and the supplier still wants the deal.
Publishing a dataset only after proving it is safe to release, so nothing is ever published.
Instead: Data Best Practice presumes openness. Justify each restriction against a named harm and apply it to the narrowest part of the dataset that carries that harm.
Core distinctions
- Now is funded and staffed, next is gated on a stated dependency, and later is a direction that has not earned a date
- Project funding buys a scope and disbands the team; product funding sustains a team against an outcome and re-decides the level each cycle
- A platform is an internal product that has to be worth choosing; a portal is a place to find things, and calling a portal a platform changes nothing
- Recognised legitimate interests removes the balancing test only for the purposes the Data (Use and Access) Act 2025 lists; everything else keeps it
- The Cyber Security and Resilience Bill reforms the UK Network and Information Systems Regulations 2018 and is not an implementation of NIS2
- The Digital Operational Resilience Act is European Union financial-sector law and shares only an acronym with the DevOps delivery research
- Under Data Best Practice a dataset is presumed open and each restriction must be justified against a named harm, applied as narrowly as the harm allows
Strategy, trust and sector leaves you able to sequence a roadmap that finance will fund, design an operating model that lets teams move, share data on a defensible lawful basis, work out which trust regimes apply to a described organisation, price lock-in before signing, hold benefits to an owner, and read the GB energy stack from government direction down to a settlement migration. The scenario practice now puts those calls into situations where the regimes overlap and the evidence is incomplete.
Sources and further reading
- GOV.UK Service Standard and the Technology Code of PracticeThe durable output of the Government Digital Service story used in the strategy section.
- Team Topologies key conceptsThe four fundamental team types and the three interaction modes applied in the operating models section.
- ICO, Recognised legitimate interestThe scope of the further lawful basis added by the Data (Use and Access) Act 2025 and when the balancing test still applies.
- Cyber Security and Resilience BillIntroduced to Parliament on 12 November 2025 as a reform of the UK Network and Information Systems Regulations 2018.
- NCSC Cyber Assessment FrameworkVersion 4.0, with the four objectives and the basic and enhanced profiles used as the assessment frame.
- UK digital verification services trust frameworkThe rules and standards a digital identity provider is independently certified against.
- Regulation (EU) 2022/1925, the Digital Markets ActThe gatekeeper obligations applied to vendor and ecosystem strategy.
- Ofgem Data Best Practice GuidanceThe presumed-open triage and the licence expectations behind the GB energy digitalisation stack.
- MHHS ProgrammeThe market-wide half-hourly settlement milestone ladder and Ofgem's final impact assessment benefit range to 2045.