Case Study 01
Target Architecture Model
Context
A payments company that had grown through multiple acquisitions. Each acquired company brought its own technology stack, engineering practices, and operational maturity. The result was fragmented systems, overlapping applications serving similar functions, and inconsistent delivery pace across the organisation.
The Problem
There was no shared understanding of what "good" looked like. Each team optimised locally. Strategic projects required extensive coordination because there was no common reference architecture. New initiatives couldn't leverage existing capabilities because no one knew what existed or how to integrate with it.
The organisational friction was significant: architecture decisions were negotiated project-by-project rather than guided by a coherent strategy.
The Decision
Define a single Target Architecture Model — a company-wide reference covering four pillars: eliminating application overlaps, creating shared services, elevating engineering standards, and enabling a data-driven organisation.
Rejected alternatives: Bottom-up standardisation (too slow, no coherence), mandate without mapping (lacks buy-in), and ignoring the problem (unsustainable as the company scales).
Why this approach: A top-down framework with bottom-up validation. Start with extensive mapping of the current estate per business domain, then align target states with domain SMEs. This created shared ownership rather than imposed standards.
Trade-offs
Improved: Strategic clarity — teams now have a north star. New projects can reference the target architecture rather than reinventing decisions. Executive alignment on technology direction.
Sacrificed: Speed of initial delivery. The mapping and socialisation phase took time. Some teams felt slowed down by the process.
Risks accepted: The target architecture could become shelfware if not embedded in delivery processes. Mitigation: tied it to focused business cases and upcoming project decisions.
Outcome
Technical: Target architecture documentation per business domain. 20+ company-wide standards for APIs, events, and observability.
Organisational: Common language for architecture discussions. Clear criteria for technology investment decisions.
Business: Focused business cases for cost savings through application consolidation. Internal Developer Platform adoption justified through the framework.
What I'd Do Differently Today
I would have started with a smaller pilot domain rather than attempting company-wide mapping upfront. The comprehensive approach was thorough but slow. A single domain success story would have built momentum faster and created internal advocates earlier in the process.
Case Study 02
Merchant Selection as Optimisation Problem
Context
A marketplace where multiple merchants could fulfil the same order. The platform needed to decide which merchant should ship each item. This decision affected customer experience, merchant satisfaction, shipping costs, and gross profit. The system processed millions of orders annually across a global supply network.
The Problem
The existing algorithm used sequential, rule-based selection — a priority list that couldn't capture profitability and experience trade-offs as the network grew. Operations couldn't predict how rule changes would affect outcomes. Each new business requirement meant engineering work to add another rule, with unclear interactions between rules.
The organisational friction: Product, Operations, and Engineering were constantly negotiating rule changes without shared visibility into impact.
The Decision
Reframe merchant selection as a mathematical optimisation problem. Replace the rule-based approach with a configurable formula where variables (cost, speed, merchant performance) could be weighted and tuned without code changes.
Rejected alternatives: Adding more rules (doesn't scale, interactions become unpredictable), machine learning black box (operations needed explainability), and keeping the status quo (leaving money on the table).
Why this approach: Optimisation gives Operations direct control over trade-offs while keeping the system explainable. The formula-based approach allowed rapid experimentation without engineering bottlenecks.
Trade-offs
Improved: Time to introduce new selection variables dropped from months to roughly one week. Operations could tune trade-offs directly. Clear attribution of outcomes to decisions.
Sacrificed: Simplicity. The optimisation approach required more sophisticated tooling and operational training. Initial learning curve was steep.
Risks accepted: Formula misconfiguration could have significant financial impact. Mitigation: built a Digital Twin for testing changes against historical data before production deployment.
Outcome
Technical: Event-driven system consuming millions of Kafka events with zero user-facing latency. Architecture supporting real-time decision tracking for analytics.
Organisational: Product, Operations, and Engineering trio working from shared dashboards. Team deeply engaged with business outcomes.
Business: Business: Multi-million gross profit uplift in the first year,followed by sustained six-figure operational cost savings across shipping and infrastructure.
What I'd Do Differently Today
I would have invested more in the Digital Twin earlier. We built it as a validation tool, but it became the most valuable artefact for building organisational trust in the system. Starting with simulation capabilities from day one would have accelerated adoption and reduced resistance to change.
Case Study 03
Order Management Platform Redesign
Context
A large e-commerce platform serving millions of customers through a global network of merchants. The Order Management system had grown organically over years, accumulating technical debt and functional limitations. The platform was expanding to support new business models including warehouses and hub-and-spoke fulfilment operations.
The Problem
Legacy applications posed functional limitations and made new developments expensive. The cost to add capabilities was increasing while time-to-market was extending. The system couldn't support the complexity of new fulfilment operations without significant rework.
The organisational friction: Nine product teams were working on related problems without a shared vision. Each team optimised their slice, but the overall system was becoming harder to evolve.
The Decision
Create a new Order Management product vision with modularity and extensibility at its core. Design a reference architecture supporting different order and return fulfilment processes, built on API and event-based microservices.
Rejected alternatives: Incremental refactoring (too slow given business pressure), replatforming to a vendor solution (didn't fit the platform model), and ignoring the problem (would block strategic initiatives).
Why this approach: A clear vision with staged delivery. Benchmarked against order management products and e-commerce platforms to avoid reinventing solved problems. Focused on lowering cost to run rather than adding features.
Trade-offs
Improved: Shared vision across nine teams. Clear architectural boundaries enabling parallel work. Support for new business models without major rework.
Sacrificed: Short-term velocity. Teams needed to align on the vision before accelerating. Some ongoing work was deprioritised to focus on foundational changes.
Risks accepted: Vision might not survive organisational change. Mitigation: secured CTO and CPO buy-in, documented the strategy extensively, and mentored Principal Engineers and Product Managers to become advocates.
Outcome
Technical: Reference architecture for Orders using API and event-based microservices. Expected 94% faster deploy-to-production for Orders applications.
Organisational: Nine teams aligned on a shared roadmap. Principal Engineers and Product Managers mentored on platform thinking.
Business: Support for warehouses and hub-and-spoke fulfilment. Enhanced seller experience. Expected 5% increase in product development throughput.
What I'd Do Differently Today
I would have spent more time on migration path clarity. The vision was compelling, but teams needed more concrete guidance on how to get there from their current state. Early wins matter for maintaining momentum, and I underestimated the importance of visible, quick victories in sustaining organisational commitment.