Synthetic worked example · No client data

Project Alder: reconstruct before you rewrite.

This example shows how Harten is intended to connect source evidence, system relationships, risk and a bounded transformation decision.

The organisation, systems, source findings, figures and recommendations below are invented. They do not describe a real engagement.

Estate type
Mixed legacy
Evidence confidence
Medium
Decision horizon
90 days

Executive decision

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

The evidence suggests that eligibility logic is the highest-value boundary to isolate. Authorise one reversible slice, run old and new paths in parallel and decide the wider target architecture only after parity is demonstrated.

Synthetic recommendation
Fund
One bounded eligibility workflow
Pause
Whole-platform rewrite
Retire
Two duplicated reporting tools
Decide next
Scale extraction, retain or replace

01 · Synthetic source estate

The repository tells only part of the story.

Project Alder deliberately mixes application code, database logic, integration dependencies and incomplete tests to represent the kind of estate where simple file-by-file analysis is insufficient.

1.2MLines of mixed source

.NET Framework, Java, T-SQL and Classic ASP.

41External integration points

REST, SOAP, files, queues and batch interfaces.

63%Business rules outside service code

Stored procedures, configuration and older web layers carry material logic.

5Critical components without regression coverage

Change risk is driven by evidence gaps as much as technology age.

02 · Source facts

Deterministic findings establish the baseline.

Each finding is intended to retain the source location, analysis method and confidence needed to challenge it later.

FindingEvidenceRiskConfidence
Eligibility logic split across service and databaseCall graph + stored procedure referencesChange and parity riskHigh
Shared authentication helper used by 7 applicationsStatic dependency graphBlast radiusHigh
Legacy reporting reads operational tables directlySQL dependency analysisCoupling and performanceMedium
Three batch interfaces have unclear ownershipConfiguration + technical recordsOperational continuityLow

03 · Software graph

Relationships expose why the first move matters.

The graph connects code, database logic, interfaces and risk so the recommendation is based on system structure rather than age alone.

  1. 01
    Eligibility-rule concentration

    Critical logic spans application and database layers while regression evidence is weak.

    20/25
  2. 02
    Shared authentication dependency

    Seven applications depend on one aging component, increasing blast radius and sequencing complexity.

    18/25
  3. 03
    Direct reporting-table coupling

    Operational and reporting concerns are tightly coupled through database access.

    16/25
  4. 04
    Unowned batch integrations

    Low-confidence ownership evidence creates operational uncertainty before transformation begins.

    14/25

04 · Controlled transformation slice

Extract one rule boundary and prove parity.

The objective is not to begin a disguised rewrite. It is to test whether the evidence supports a safe reduction of the legacy core.

In scope

  • Eligibility rule inventory
  • Executable characterization tests
  • New service boundary
  • Parallel execution and result reconciliation
  • Observability, rollback and decision evidence

Out of scope

  • Whole-core replacement
  • UI redesign
  • Cloud-provider commitment
  • Unrelated workflow migration
  • Decommissioning before parity is proven
Gate 1Rule inventory accepted

Evidence owner confirms coverage and unresolved ambiguity.

Gate 2Parity threshold met

Old and new paths reconcile across agreed synthetic and production-like cases.

Gate 3Operational controls proven

Security, support, observability and rollback are accepted.

Gate 4Scale decision made

Continue, change course, retain or stop based on evidence.

05 · Evidence chain

The decision remains connected to the change.

A governed transformation should preserve enough provenance to explain what was changed, why, how it was validated and who approved it.

01

Intent

The bounded problem and acceptance conditions.

02

Implementation

The branch, code and transformation evidence.

03

Validation

Build, tests, security checks and reconciliation.

04

Decision

Approval, risk acceptance, rollback and next action.

Synthetic by design

The stronger proof is reproducible evidence, not a confidential case study.

Future public Harten benchmarks are intended to use purpose-built legacy applications whose source, findings and expected outcomes can be inspected.

Inspect the evidence model