Fictional worked example · No client data

Modernisation Brief: Project Alder.

This sample shows the shape and decision discipline of a Harten Modernisation Brief. The organisation, systems, figures and recommendations are invented as one coherent composite. They do not describe a real engagement.

Decision horizon
90 days
Evidence confidence
Medium
Brief status
Decision ready

Executive recommendation

Do not rewrite the core. Prove the extraction path first.

Authorise one ten-week slice to extract eligibility decisions from the legacy core, expose them through a governed service and run old and new paths in parallel. Retain the core platform for twelve months while the evidence determines the next move.

Recommended
Fund now
One bounded eligibility workflow
Pause
Whole-platform rewrite and cloud commitment
Retire
Two low-use reporting applications
Decide next
Scale extraction, replace core or retain

01 · The forcing context

Why a decision is required now.

Project Alder is a fictional regulated service provider processing 1.4 million service events each year. A vendor renewal, specialist attrition and rising service incidents create pressure to act, but not evidence for a wholesale rewrite.

9 months Until a core-platform renewal

The proposed contract adds 28% over three years and extends exit restrictions.

1 person Understands the eligibility rules

Critical business logic is split between code, stored procedures and runbooks.

46 Point-to-point integrations

Ownership and failure handling are inconsistent across the estate.

14 apps In the immediate portfolio

Three are critical; five have no current automated regression coverage.

02 · Estate baseline

What exists, why it matters and how well it is understood.

Confidence is shown with the recommendation. Unknowns are not silently converted into certainty.

Component Role Criticality Evidence Initial disposition
CoreServe Case and account system of record Critical Medium Retain and remediate
RulesHost Eligibility and pricing decisions Critical Low Extract incrementally
ConnectHub Batch and event integration High Medium Wrap, then replace patterns
CustomerWeb End-user self-service High High Replatform after API boundary
ReportDesk A/B Duplicated operational reporting Low High Retire

03 · Risk-ranked backlog

The sequence follows service risk, not architectural fashion.

Ranking combines operational impact, time pressure, dependency reach and confidence in the underlying evidence.

  1. 01
    Eligibility-rule concentration

    One specialist, weak tests and mixed implementation locations create an immediate continuity risk.

    20/25
  2. 02
    Renewal and exit exposure

    A decision is required before commercial deadlines remove practical options.

    18/25
  3. 03
    Integration failure handling

    Point-to-point recovery depends on manual reconciliation and local knowledge.

    16/25
  4. 04
    CustomerWeb change friction

    The front end cannot evolve safely until a stable service boundary exists.

    13/25

04 · Controlled first move

A ten-week slice with a reversible boundary.

The slice tests whether the core can be reduced safely. It is not a disguised start to a programme that has already been decided.

In scope

  • One high-volume eligibility workflow
  • Rule inventory and executable characterisation tests
  • Governed service boundary and production-like deployment
  • Parallel execution with automated result reconciliation
  • Operational runbook, ownership and rollback evidence

Explicitly out of scope

  • Whole-core replacement
  • CustomerWeb redesign
  • Cloud-provider commitment for the wider estate
  • Migration of unrelated workflows
  • Decommissioning before parity is proven
Gate 1Rule inventory accepted

Domain owner confirms completeness and unresolved ambiguity.

Gate 2Parity threshold met

Old and new decisions reconcile across agreed production-like cases.

Gate 3Operational readiness accepted

Support, observability, security and rollback are proven before live traffic.

Gate 4Scale decision made

Evidence supports continue, change course, retain or stop.

05 · Measures and stop conditions

Define success and failure before delivery starts.

All values below are fictional and illustrate how a baseline is tied to a decision.

Change lead time15 days → under 5Target after the first live release
Characterisation coverage18% → at least 70%For the extracted workflow only
Decision parityAt least 99.95%Across agreed production-like cases
Manual reconciliation240 → under 80 hrs/monthMeasured after parallel running

Stop or redesign the slice if:

  • Rule ownership cannot be established by the end of week two.
  • Parity remains below 99.95% after agreed defect correction.
  • The new boundary increases recovery time or creates unowned operational work.
  • Required data movement cannot meet the agreed security and residency constraints.

Rollback: route all decisions to the unchanged legacy path, preserve reconciliation evidence and remove the new service from live traffic.

The decision pack

What the sponsor leaves with.

  1. 01
    Evidence-backed estate baseline

    Criticality, ownership, dependency, confidence and unknowns.

  2. 02
    Risk-ranked and fundable backlog

    Sequence linked to service, commercial and delivery pressure.

  3. 03
    Disposition record

    Retire, retain, remediate, replace or move, with rationale.

  4. 04
    First-slice charter

    Scope, controls, measures, stop conditions and rollback.

  5. 05
    Investment decision

    What to fund now, what to pause and what evidence is needed next.

Your estate, not this fictional one

Bring one decision that currently rests on assumption.

The first conversation tests whether a fixed-scope Brief is the right next move.

Discuss a Modernisation Brief