AMOS
End-to-end migration of the EMS Operations platform's financial core — from a 63-sheet Excel legacy workflow to a production full-stack system with database-level integrity guarantees.
ORGANIZATION
CAPGEMINI ENGINEERING
PERIOD
MAR 2026 — PRESENT
ROLE
SOFTWARE ENGINEER — PFE · LEADING THE MIGRATION
STACK
DJANGO · DRF · POSTGRESQL · REACT · UML
Excel sheets replaced by one platform
Project records recovered in audit
Missing missions uncovered
01 — THE BRIEF
Capgemini's Operations Services ran its financial reference data — rate cards, exchange rates, profile grids, iSOW flows — across 63 interlinked Excel sheets. Formulas encoded undocumented business logic; history was overwritable; nothing was auditable.
The mission: audit the legacy workflow, recover what it silently lost, design a schema that makes corruption impossible, and ship the platform's financial backbone (admin_v1) as production software. The audit alone recovered 96 project records and uncovered 21 missions the spreadsheets had lost track of.
02 — OPERATING CONSTRAINTS
- Financial reference data — every change needs an owner, a timestamp, and a reason (full audit trail).
- Rate-card cost logic existed only as undocumented Excel formulas — it had to be reverse-engineered, not reinvented.
- Temporal data (rates, grids) must have complete annual coverage with zero overlapping periods.
- Sensitive edits require double-validation — no single user can silently change a financial reference.
- Excel remains the ingestion format for the business — imports must be gated and audited, not trusted.
- Corporate delivery: specs and UML first, shipped through a Git review workflow. All work under NDA.
03 — SYSTEM STRUCTURE
REACT ADMIN (admin_v1)
Reference-data administration: rate cards, FX rates, profile grids, iSOW flows.
DRF REST SERVICES — VERSIONED
Reverse-engineered rate-card cost logic as tested, versioned endpoints. Double-validation locking on sensitive writes.
AUDITED XLSM IMPORT GATE
Excel stays the business's input format — every import is validated, logged, and attributable.
POSTGRESQL — INTEGRITY LAYER
GIST exclusion constraints guarantee non-overlapping temporal history; complete audit trail on every mutation.
04 — KEY DECISIONS
DECISION 01
Enforce temporal integrity in the database, not the application
PostgreSQL GIST exclusion constraints make overlapping rate periods impossible at the storage layer — a guarantee no application bug, script, or manual edit can bypass.
DECISION 02
Reverse-engineer the Excel formulas into tested, versioned REST services
The cost logic was the business's real asset, hidden in formulas. Extracting it into versioned services made it testable, reviewable, and safe to evolve.
DECISION 03
Gate Excel imports instead of banning them
The business works in Excel. An audited XLSM import gate keeps their workflow while making every ingestion validated and traceable.
DECISION 04
Double-validation locking on financial references
Four-eyes principle enforced by the system: sensitive changes lock until a second validator confirms them.
05 — OUTCOME
Scattered, overwritable Excel reference data became a controlled, traceable financial referential — with recovered history the spreadsheets had already lost.
- · Currently leading development of the platform's notification engine.
- · Full walkthrough available in interviews — structure only here, per NDA.
CROSS-EXAMINATION
The full walkthrough — code, schema, trade-offs — happens live. Fifteen minutes, no slides.
NEXT EXHIBIT
NXRISEUP →