cpdeol
← Back to Projects
Enterprise Architecture + Transformation

Banking Platform Modernisation — Service Decomposition

Replaced a fragile monolith with 12 independently deployable domains — achieving 99.99% SLA and 10× faster deployments.

99.99%

SLA (was 98%)

10×

faster feature deployments

12

independently deployable domains

100k+

concurrent users supported

Role

Lead Business Systems Analyst — Platform Transformation

Timeline

Q4 2021–Q2 2022 · 7 months

Delivery context

Enterprise ArchitectureAPI IntegrationSQLSalesforceAgile

The Problem

A monolithic banking platform was tightly coupled — one issue took down the entire system. Feature delivery required coordinating across all teams simultaneously, making velocity very slow. The organisation needed a clear map of data ownership before any technical decomposition could safely begin.

My Contribution

I facilitated the service decomposition workshops with each product domain, documenting current-state system dependencies and defining future-state bounded contexts based on data ownership and business capability. I authored BRDs for each of the 12 service domains, managed stakeholder alignment across eight engineering and product teams, and defined the integration acceptance criteria for every service interface. I also led the data migration requirements for each service that required its own data store, ensuring traceability from business requirement to technical implementation throughout the programme.

The Solution

Requirements-led decomposition: current-state dependency mapping, bounded context definition by data ownership, BRDs for all 12 domains, integration contract specifications, cross-team stakeholder alignment, and phased sign-off before any service was independently deployed.

Results

  • 99.99% SLA achieved (up from 98%)
  • <50ms p99 latency on critical paths
  • 10× faster feature deployments
  • 12 services with independent deploy cadence
  • Scales to 100k+ concurrent users
Key learning
Service decomposition succeeds or fails on data ownership, not code structure. Every cross-team conflict during the programme traced back to a database table with unclear ownership. Resolving those in requirements workshops — before any service boundaries were drawn in code — made the second half of the programme dramatically smoother.

Tech Stack

Platforms

SalesforceBanking APIsMuleSoft

Integration

RESTful APIsSOAPAPI Management

Tools

JIRAConfluenceVisioSharePoint

Methodology

Agile/ScrumBRD/TDDUATUML

Related

How this project connects to the rest of my work.