Business before technology
A system exists to serve a business capability. Understand the domain, the constraints and who pays the cost of change before opening the technology catalog.
Senior Software Architect
enterprise modernization · ai-assisted engineering · distributed systems · technical leadership
I started as a .NET developer inside large enterprises, on the kind of systems nobody writes blog posts about: poorly documented, business-critical, and older than some of the people maintaining them. Reading those systems — reverse-engineering what they did and why — turned out to be the most useful education I could have asked for, and it is where I fell in love with architecture.
That path led to an internal promotion to Software Architect, and today I help organizations modernize enterprise software: understanding the business problem first, then choosing technology. I believe architecture is about making trade-offs explicit rather than chasing trends, and I have stayed deliberately hands-on — I still enjoy coding, and I still build small things for fun.
Away from the keyboard I am a proud father of a 3-year-old, and most of my time outside work belongs to her. The rest goes to music, cricket, table tennis, volleyball, photography and travel — some of which you can see in the photos below.
Written the way architects record decisions — as ADRs. These have survived contact with banking mainframes, healthcare platforms and everything in between.
A system exists to serve a business capability. Understand the domain, the constraints and who pays the cost of change before opening the technology catalog.
There are no best practices, only fitting ones. The architect's job is to make trade-offs explicit, choose deliberately, and write the reasoning down.
Big-bang rewrites of running businesses fail quietly and expensively. Strangle legacy at the seams — anti-corruption layers, parallel runs, reversible steps.
AI tooling is a force multiplier for reverse engineering, documentation and migration — in the hands of engineers who can judge the output. It replaces toil, not thinking.
Complexity is the real legacy. The systems that survive decades are the ones a new engineer can reason about in a week — design for that engineer.
Architecture handed down as a diagram dies in the first sprint. It works when the teams building the system understand, challenge and own the decisions.
Taking systems that have quietly run a business for twenty or thirty years — mainframe estates, aging platforms — and moving them forward without stopping the business. Discovery, reverse engineering, target-state design, and a migration path measured in reversible steps.
Designing distributed systems and the boundaries between them. Architecture governance, reviews and decision records; making sure the important trade-offs are made on purpose, by the people who will live with them.
Putting AI to work on the unglamorous middle of modernization: understanding undocumented code, generating first-draft documentation and tests, accelerating migration. Grounded in engineering judgment, not demos.
Leading two to three engineering teams at a time — mentoring, running architecture workshops, reviewing designs and code, and doing the technical discovery and pre-sales work that shapes an engagement before it starts.
Modernization practice — enterprise banking modernization for a major financial institution.
R&D, healthcare content services — promoted internally from developer to architect.
Financial analytics — product engineering on fixed income analytics.
Full-stack work on a nationwide examination delivery platform.
The day job, described without the confidential parts — and the things I build on my own time, because I still enjoy building software.
Luxoft · banking & capital management
Hyland · healthcare R&D
FactSet · financial analytics
Cognizant · assessment industry
A small Firebase-backed app where people write down gratitude towards others. Built to learn, kept because it is nice.

A single-file HTML toy: enter the event horizon. Proof that architects still write code for fun.
I write about architecture, modernization and engineering practice — on Medium and on my blog.
Longer-form pieces on enterprise architecture, modernization and the craft of software engineering.
read on medium ↗Shorter, rougher notes — experiments, how-tos and things I want to remember.
read the blog ↗Travel, family and friends — the parts of life that do not fit in an ADR.
Grouped by capability, because the capability matters more than the logo.
I enjoy discussing enterprise architecture, modernization and difficult engineering problems. If you're building or modernizing large software systems, I'd be happy to connect.