Skip to content

Portfolio

Working code behind the positioning, in three areas: deciding and modelling the target, moving an estate onto it, and running the platform underneath. Every repository here is public, runs end to end, and says in its own README where the demo stops and production would begin.

Working code, and what it proves

Data architecture & modelling

Deciding what the target looks like, and what crosses the boundary to get there.

  1. 1Model one domain four ways

    enterprise-data-model-lab

    Working — runs end-to-endMIT

    What it proves

    One retail domain modelled four ways: glossary, conceptual, logical, then two physical targets from identical staging, Kimball dimensional and a Data Vault 2.0 raw vault. Fourteen assertions guard every build, and the trade-off is measured: 1 join and 0.79 ms against 3 joins and 302 ms, at 3× the rows stored. Runs with `make demo`.

    View repository
  2. 2Decide what crosses the SAP↔cloud boundary

    sap-bdc-snowflake-blueprint

    Working — runs end-to-endMIT

    What it proves

    A one-page SAP → Business Data Cloud/Datasphere → Snowflake reference architecture with the decision attached. Nine ordered rules assign each of 24 objects a mode (share, replicate, federate, split, or keep it in SAP); residency and SLOs eliminate first, and cost chooses among what survives. A local DuckDB simulation runs the modes. Runs with `make demo`.

    View repository
  3. 3Decide where a Synapse estate goes

    azure-lakehouse-decision

    Working — runs end-to-endMIT

    What it proves

    Microsoft Fabric or Databricks-on-Azure for a 20-workload Synapse estate, decided per workload. Nine ordered rules: residency, streaming semantics and ML lifecycle eliminate, and cost chooses among what survives. A Fabric workload has no standalone price; one more costs nothing until the pre-paid capacity saturates, and then costs a whole rung. Runs with `make demo`, no Azure subscription.

    View repository
  4. 4Decide what 'active customer' means

    ai-first-bi-platform

    Working — runs end-to-endMIT

    What it proves

    Three defensible definitions of “active customer” (Operations’, Analytics’ and Finance’s), built in a real dbt project, returning 953, 900 and 881 on the same estate on the same date. Nobody is wrong, and no dashboard says which one it is showing. The finding underneath: the operational table cannot answer the question at all, because its `status` column is overwritten in place. Runs with `make demo`.

    View repository

Modernization & migration

Moving a live estate wave by wave, with parity gates instead of a big-bang weekend.

  1. 1Move a warehouse wave by wave

    legacy-dwh-migration

    Working — runs end-to-endMIT

    What it proves

    A legacy warehouse migrated wave by wave, with the programme artefacts as code. The assessment is crawled from the estate itself; it finds 36% of objects never queried, and separates what can be retired from what is dormant but still depended on. Cutover is gated by a parity harness with one defect injected to prove the gate catches it. Runs with `make demo`.

    View repository
  2. 2Modernize legacy live, wave by wave

    oracle-to-spring-strangler

    Working — runs end-to-endMIT

    What it proves

    A working legacy-modernization lab: an Oracle PL/SQL + ORDS system migrated live to Spring Boot + PostgreSQL by the strangler fig pattern. Per-endpoint cutover waves in an nginx router, where a wave is a PR and rollback is a git revert, with golden-master parity gates as wave exit criteria. Runs with `docker compose up`.

    View repository

Integration & platform services

The self-service platform the teams downstream run day to day.

  1. 1Stream & integrate events at platform scale

    event-integration-platform

    Working — runs end-to-endMIT

    What it proves

    A Kafka-native, multi-tenant event-streaming and integration platform: REST→Kafka ingest, managed JSONata transforms with DLQ and replay, Kafka Connect sinks, a control-plane API and a drag-and-drop pipeline UI, all under workspace-scoped observability. The self-service platform an integration team runs day to day. Runs with `docker compose up`.

    View repository
  2. 2Own identity across products

    identity-service

    Working — runs end-to-endMIT

    What it proves

    A working self-hosted identity provider: OAuth 2.0 + OIDC token issuance (RS256, published JWKS), a headless TypeScript SDK and a drop-in React `<Login/>`. Its audited management plane speaks both HTTP and MCP, so agents operate it under the same contract as people. Authentication only; products keep their own authorization. Runs with `docker compose up`.

    View repository
  3. 3Keep the model outside the runtime

    skills-coach

    Working — runs end-to-endMIT

    What it proves

    A pack-driven training platform that ships no model client at all: the runtime owns the packs, deterministic grading, spaced-repetition gating and a durable model of what a learner keeps getting wrong. Generation and correction sit behind a versioned coach API, so the caller can be a person today and a model API later. Runs with `make up`.

    View repository

All of these run end to end; clone any of them and bring it up. Two caveats. They run on synthetic data, so the claim is the architecture and the mechanics, and every README says where real data would go instead. And the three blueprint-style repositories are documents first: what runs is the decision engine, the cost model and the simulation behind the document. None of them is a production system.