Twenty-five years of software architecture that works at scale.

Full-stack architecture from domain model to deployment pipeline — high-availability systems handling millions of transactions under real-world pressure. Proven across public transport, multi-platform delivery, and complex data integration at national scale.

See my work Get in touch

About

The long game

I've spent the better part of two decades solving problems that sit at the intersection of complex data, demanding performance requirements and real people trying to get from A to B.

My career has been shaped by public transport - an industry where the systems you build are only as good as their worst day. When a commuter in Edinburgh searches for the fastest route to work at 7:45am on a wet Tuesday, they don't think about the architecture behind the answer. That's the point. The best systems are the ones nobody notices.

I'm a full-stack architect in the truest sense. I've designed the database schemas, modelled the domain, built the APIs, crafted the front-end components, configured the CI/CD pipelines, planned the disaster recovery, and sat in the room when the product decisions were made. That breadth isn't accidental. I believe you can't make good architectural decisions in isolation from the code, the infrastructure, the security model, or the people who use the end product.

Right now, I'm the Chief Software Architect at Naviquate (previously known as Trapeze Group, and part of Modaxo), where I shape the technical direction across multiple product lines serving millions of journey plans. That means long-term technical strategy, vendor evaluation, architecture reviews, cloud cost management, and presenting technical direction to board-level stakeholders — not just drawing diagrams. The systems I've designed run across web, iOS and Android, processing complex public transport data from a patchwork of national and regional standards — NaPTAN, ATCO, GTFS, TransXChange, SIRI — into something fast, reliable and useful. Every system gets the architecture it actually needs, not the one that's fashionable. I believe in choosing the right pattern for the context.

The role has changed beyond recognition over twenty five years - from writing C++ in a small team to setting technical strategy across product lines, markets, and technology stacks. I chose depth over job-hopping, and the result is a level of domain knowledge, institutional understanding, and architectural maturity that you can only build over time. But the skills are entirely transferable. The problems I solve daily - complex multi-source data integration, real-time systems under load, multi-tenancy across operators, regulatory compliance, legacy modernisation - are the same problems faced in healthcare, logistics, financial services, government, and any domain where messy data meets demanding users.

I don't hold a wall of formal certifications. My credibility comes from twenty five years of building things that work in production, at scale, under pressure. I've found that the architects who make the best decisions are the ones who've been close enough to the code to understand the consequences of their choices - and close enough to the business to understand why those choices matter.

I've always had a parallel interest in magic - not as a party trick, but as a discipline. Magic teaches you that the simplest solution, packaged well, is almost always the most effective. It trains you to see problems differently, to question assumptions, and to understand that how something is experienced matters as much as how it's built. The KISS principle isn't just engineering wisdom. Magicians figured it out long before we did.

More recently, I've been embedding AI and agentic tooling into real engineering workflows — not as a novelty, but as a practical force multiplier. I build AI agents and custom skills that solve real problems, grounded in the four Ds of AI fluency: knowing what to delegate, describing it clearly, scrutinising the output, and doing it all responsibly. AI belongs in the architect's kit, not on someone's strategy deck.

"The best illusions are resolved before the audience realises the trick has begun. Great architecture works the same way — the complexity is absorbed in the design room, so the people who depend on it only ever experience the elegance."

Neil Sherman

The Journey

Twenty Five years, one thread

2001 - The Beginning

I wrote my first commercial code in 2001, joining Action Information Management fresh out of Southampton with a Computer Science degree and a dissertation on IPv6 — research that contributed to the broader IPv6 work at the university. I started in C++, building core components of journey planning technology, and quickly introduced the business to Java, XML, and modern web development.

Those early years taught me something that's stayed with me: transport software doesn't forgive sloppy thinking. The data is messy. The standards are fragmented - NaPTAN, ATCO, TransXChange, GTFS, SIRI - each with their own assumptions and edge cases. If your system doesn't handle them gracefully, people miss buses. It sounds mundane until you realise the scale: millions of journey plans served every month, across multiple regions and operators, with the expectation that the answer arrives in milliseconds. That complexity is what first drew me towards domain-driven thinking - modelling the transport domain carefully, establishing clear boundaries between contexts, and building a ubiquitous language that the code, the data, and the team all shared.

2006 - Senior Engineer

I progressed through the ranks - junior to mid, mid to senior - and the company evolved too, eventually becoming part of Trapeze Group. By 2006 I was operating as a Senior Software Engineer, and the work had shifted to Java and Spring. I was driving the adoption of practices that felt cutting-edge at the time: test-driven development, continuous integration, pair programming. I took on a lead role in defining stories, working with QA and stakeholders on acceptance criteria, and mentoring developers ranging from graduate hires to outsource teams.

2017 - Architecture

The bigger transition came when I moved into architecture. It wasn't a sudden shift - it rarely is. I'd been the person making the technical calls for years before the title caught up. When it did, the scope expanded. I became responsible for the full stack: Java and Spring Boot on the backend, .NET Core for specific platform components, Angular and Ionic on the front end, Azure for cloud infrastructure. But the scope also expanded beyond code into the cross-cutting concerns that define real architecture - security, data protection, disaster recovery, accessibility, capacity planning, and the governance of how decisions get made and documented. The products I architect serve operators across multiple UK regions and beyond.

The architecture style varies deliberately by product and context. Some products are well-served by a layered monolithic design — clean separation of concerns, dependency injection throughout, repository patterns for data access, but deployed as a coherent unit. Others have evolved towards more distributed designs: event-driven messaging via queues, CQRS where read and write models have materially different requirements, and API gateway patterns to manage external integration. I've applied the Strangler Fig pattern more than once to progressively modernise legacy components without the risk and disruption of a rewrite. The thread that connects all of this is pragmatism: choosing the right architectural style for the actual problem, not the one that looks best on a whiteboard.

One project that captures how I work is the gazetteer search engine. The gazetteer is at the heart of any journey planning system - it's what turns a user's typed query into a usable location, and it's also used internally whenever the system needs to resolve related data. The legacy implementation was a bottleneck. I evaluated the options - Elasticsearch (powerful but operationally heavy for this use case), database-native full-text search (insufficient ranking control), off-the-shelf geocoding services (too generic for UK transport data). The conclusion was that a bespoke Apache Lucene implementation would give us the control we needed. I engineered it down to around 4 millisecond lookup times with significantly improved result ranking. That's the kind of work I find most satisfying: understanding a problem deeply enough to know when the standard answer isn't the right one.

Along the way, I've also been the person who built the engineering culture around the code. I introduced CI/CD pipelines — first with Bamboo and BitBucket, later migrating to Azure DevOps — implemented static analysis with SonarQube, stood up private Docker registries and NuGet/NPM repositories, and introduced feature flags for progressive rollout of changes. I've delivered internal training courses on Angular, Ionic, SOLID principles, dependency injection, and secure development practices. I've led teams of varying sizes, managed outsource partnerships, run code reviews, and been a key part of the hiring process.

Present - Chief Architect

Today, my role spans product architecture, technology roadmapping, vendor evaluation, and the cross-cutting concerns that hold everything together. I contribute to long-term technical strategy, conduct architecture reviews across product lines, help identify and prioritise technical debt, influence cloud spend, and present technical direction to senior leadership. I work across multiple markets and products as part of a wider team, helping to shape the standards and governance that give teams the framework to make good decisions autonomously. What defines this journey isn't any single technology or pattern. It's the combination of depth and breadth, built over twenty five years of staying close enough to the code to make honest architectural decisions, and close enough to the business to make relevant ones.

"The architect's job is not to steer — it is to read the terrain ahead while others navigate the road beneath them. The decisions that matter most are the ones made before the journey begins."

Neil Sherman

Capabilities

What I Do

Full-Stack Architecture & System Design

I work across the entire stack - not because I can't specialise, but because architecture done well requires it. My systems follow layered patterns with clear separation between presentation, business logic, and data access, built on dependency injection and inversion of control throughout. I design database schemas in MySQL and SQL Server, build APIs in Spring Boot and .NET Core using repository and service patterns, craft front-ends in Angular and Ionic following component-based MVVM, and deploy the lot on Azure.

Search & Data Performance

Search is deceptively hard, and it's been a thread through most of my career. I've spent years working with Apache Lucene to build fast, intelligent search systems that handle noisy input, inconsistent data sources, and the expectation of instant results. My approach combines domain-driven modelling with careful attention to indexing strategy, query analysis, and caching at multiple levels. The gazetteer engine I built delivers results in around 4 milliseconds - performance that comes from understanding both the data and the infrastructure.

Cloud Infrastructure & API Design

I've designed and maintained Azure-based infrastructure including VMs, App Services, Function Apps, API gateways, queues, and containerised deployments. The API gateway layer manages external integrations, rate limiting, and security policies. I think about infrastructure as architecture, not afterthought - the deployment pipeline, monitoring, failover strategy, and cost profile are all part of the design. CI/CD pipelines built from the ground up, with feature flags enabling progressive rollout and blue-green deployment strategies.

Mobile & Cross-Platform Delivery

Using Ionic and Capacitor, I've delivered cross-platform applications for iOS and Android from shared Angular codebases. The reality of mobile is full of platform-specific edge cases - splash screen behaviour on Android 14, native plugin compatibility, App Store submission quirks - and I've navigated all of it in production. A single codebase serving multiple platforms reduces time-to-market and ongoing maintenance cost without compromising the user experience.

Resilience, Security & Non-Functional Architecture

The systems I build serve public-facing transport infrastructure, so they need to be resilient, secure, and available. I design for failure - circuit breaker patterns to prevent cascading failures, bulkhead isolation between critical and non-critical paths, retry policies with exponential backoff. I've been hands-on with security architecture and data protection in public sector contexts, designed disaster recovery strategies, and ensured accessibility compliance. When things go wrong, I run blameless post-mortems focused on systemic improvement.

Event-Driven & Distributed Systems

Where the problem demands it, I design event-driven architectures using message queues for asynchronous communication. I've implemented CQRS patterns where read and write models have fundamentally different performance characteristics or scaling requirements. I'm a pragmatist about distributed systems - the operational complexity is real, and I only introduce it when the benefits clearly outweigh the costs. Sometimes a well-structured monolith is the right architecture, and knowing when is as important as knowing how to decompose.

Team Leadership & Mentoring

I've led teams of different sizes, including outsource partnerships, through code reviews, training programmes, talent development, and hiring. I've delivered internal courses on Angular, Ionic, SOLID principles, design patterns, secure coding, and broader engineering best practices. Architecture doesn't happen in isolation - the quality of the system is ultimately bounded by the quality and confidence of the team building it.

Working with Product

The relationship between architecture and product management is where most difficult trade-offs live. I work closely with product managers to balance technical investment against feature delivery, negotiate space for addressing technical debt within a commercial roadmap, and ensure architectural decisions are informed by real product priorities. Sometimes I'm advocating for investment with no visible feature output - a platform migration, a resilience improvement - and the skill is making the business case clearly enough to get prioritised.

Technical Strategy & Roadmapping

At Chief Architect level, the work extends well beyond individual system design. I define multi-year technology roadmaps, evaluate and select vendor technologies, conduct build-vs-buy analyses, and present technical strategy to senior leadership and board-level stakeholders. I translate architectural decisions into the language the business understands - risk, cost, time-to-market, competitive advantage - because a strategy that only makes sense to engineers isn't a strategy, it's a wish list.

Architecture Governance & Standards

I set coding standards and architectural guidelines across multiple product lines, conduct design reviews and provide technical sign-off before significant work begins. I've established governance processes that allow teams to move quickly within a coherent framework rather than reinventing decisions for every project. This includes managing technical debt deliberately - identifying it, quantifying it, prioritising it against feature work, and communicating it to non-technical stakeholders as a business risk with measurable cost.

Cost Management & Commercial Awareness

Architecture decisions have financial consequences, and I treat cloud spend and operational cost as first-class architectural concerns. I influence Azure infrastructure costs, identify opportunities for savings, make deliberate trade-offs between build cost and running cost, and evaluate whether a vendor solution or bespoke implementation delivers better long-term value. The gazetteer search engine is a good example: a bespoke Lucene solution had higher upfront cost, but the ongoing operational cost and performance made it the commercially smarter choice.

Observability & Operational Maturity

You can't manage what you can't see. I define observability strategy across the products I oversee - logging, monitoring, alerting, and performance dashboards that give both engineering teams and business stakeholders visibility into system health. This feeds directly into capacity planning, incident response, and the confidence to deploy frequently. High availability isn't just about designing resilient systems; it's about knowing, in real time, that they're behaving as designed.

AI & Agentic Engineering

I'm actively building with AI in my day-to-day workflow. I design agentic systems and custom skills that plug into real engineering processes — from planning and analysis through to development and monitoring. This isn't about novelty — it's about recognising that AI is going to fundamentally change how architecture teams operate, and making sure I'm ahead of that curve.

"You cannot step into the same river twice."

Heraclitus

Your codebase is never the same system twice. Every deployment, every dependency update, every data migration changes the ground beneath it. Architecture is not a document you file and revisit — it is a living current. The architect's discipline is not to freeze it, but to understand its direction and ensure it keeps flowing the right way.

Philosophy

How I Think About Architecture

I'm sometimes asked about my architecture methodology. The honest answer is that after twenty five years, it's less about following a named framework and more about a set of principles that have proven themselves over and over in production.

Start with the domain, not the technology

The best architectural decisions come from understanding the problem domain deeply. I use domain-driven design concepts - bounded contexts, ubiquitous language, careful modelling of the core domain - to make sure the architecture reflects the reality of the business, not just the preferences of the team. In public transport, this means understanding that a "stop" in NaPTAN is not the same concept as a "stop" in GTFS, and that the architecture needs to handle that distinction cleanly rather than papering over it.

Choose the right style for the context

I've built layered monoliths, modular monoliths, service-oriented systems, and event-driven architectures. None of them is universally right. A well-structured monolith with clean dependency injection, repository patterns, and clear layer separation is often the best choice for a focused product with a small team. A distributed architecture with CQRS, event-driven messaging, and an API gateway makes sense when you have genuinely independent scaling requirements, multiple integration consumers, or teams that need to deploy independently. The mistake I see most often is architects choosing a style because it's fashionable rather than because it fits. I choose based on the actual requirements: team size, deployment frequency, data consistency needs, scaling profile, and operational maturity.

Design for failure

Systems fail. Networks partition. Services go down. The question isn't whether it'll happen but how the system behaves when it does. I use circuit breaker patterns to prevent cascading failures, bulkhead isolation to contain blast radius, retry policies with backoff for transient faults, and feature flags to control progressive rollout. I design disaster recovery plans and test them. Resilience isn't an add-on; it's a design constraint from day one.

Learn from failure honestly

When incidents happen, I run blameless post-mortems focused on what the system allowed to go wrong, not who made a mistake. The findings feed back into architectural decisions, operational runbooks, and monitoring improvements. The organisations that improve fastest are the ones that treat failure as data, not as blame. I've found that a consistent post-mortem culture does more for system reliability than any individual technical decision.

Simplicity over cleverness

This is the principle I come back to most. The simplest design that meets the requirements is almost always the one that ages best. It's cheaper to maintain, easier to onboard new developers onto, and more predictable under load. My interest in magic reinforces this constantly - the most impressive tricks are almost always the simplest methods, packaged beautifully. Architecture works the same way.

Modernise incrementally

I've used the Strangler Fig pattern multiple times to progressively replace legacy components with modern implementations. The approach is simple: wrap the legacy system, route new functionality to new code, and gradually migrate until the old component can be retired. It's slower than a rewrite but dramatically less risky, and it means you're delivering value throughout the migration rather than asking the business to wait for a big-bang switch.

Stay close to the code

I read code, I write code, I review code. Not because I don't trust my teams - but because architectural decisions that aren't informed by implementation reality tend to be architectural decisions that get quietly worked around. The gap between the diagram and the deployed system is where most architectural failures live.

Document decisions, not just designs

Every significant architectural decision should be explainable - why this approach, what alternatives were considered, what trade-offs were accepted. I don't maintain formal Architecture Decision Records in the textbook sense, but the principle matters: decisions should be documented, reviewable, and revisitable. When I chose a bespoke Lucene implementation over Elasticsearch for a specific search problem, I can walk you through the reasoning, the constraints, and what would need to change for that decision to be revisited.

Treat technical debt as a business risk

Every codebase accumulates debt. The question is whether you manage it deliberately or let it compound until it becomes a crisis. I identify technical debt systematically, quantify its impact in terms a non-technical stakeholder can understand - increased maintenance cost, slower feature delivery, higher operational risk - and prioritise it against feature work as part of the roadmap, not as a separate engineering side-project. Technical debt that isn't visible to the business is technical debt that never gets addressed.

Know the cost of your decisions

Architecture has a price tag. Cloud spend, operational overhead, developer time, vendor licensing, opportunity cost - these are all consequences of architectural choices. I evaluate build-vs-buy decisions with long-term total cost of ownership in mind, manage cloud budgets actively, and make sure the organisation understands the commercial trade-offs inherent in different approaches. An elegant architecture that the business can't afford to run is a failed architecture.

Govern with frameworks, not gatekeeping

Good governance enables speed rather than blocking it. I set architectural standards and guidelines that give teams the confidence to make decisions autonomously within a coherent framework. Design reviews and technical sign-off exist to catch misalignment early, not to centralise every decision. The goal is an organisation where architectural consistency emerges from shared principles rather than top-down control.

"Only when the tide goes out do you discover who's been swimming naked."

Warren Buffett

The same is true of software. Deadlines compress everything — corners get rounded, decisions get deferred, shortcuts get rationalised. While the pressure is on, the system holds its shape through sheer force of will. It is only when a project concludes, when the releases slow and the retrospectives begin, that the true quality of what was built becomes visible. Good architecture is what remains standing when the urgency has gone. That is the standard I hold myself to — not how it looks under the spotlight, but how it reads in the quiet that follows.

Value

Where I Add Value

After twenty five years, I know what I'm good at and where I make the biggest difference. I thrive in Chief or Principal Architect roles where I can shape technical strategy, get my hands into the code when it matters, and help build something that works at scale.

I'm at my best when there are real engineering problems to solve — whether that's a greenfield platform that needs careful domain modelling and the right architectural style from the start, or a legacy estate that needs someone who knows how to modernise incrementally without breaking what works. Both of those challenges energise me.

The technical work has to connect to real business outcomes: reducing operational risk, shortening time-to-market, enabling growth, or making systems more efficient and less expensive to run.

AI is reshaping how software teams operate, and I'm actively part of that shift. Not in an abstract way, but practically: building the tooling, defining the patterns, and showing what's possible when experienced architects take AI seriously as part of their workflow.

What matters most to me is the calibre of the team, the ambition of the product, and whether the organisation values deep, cross-cutting technical leadership.

"Happiness is the activity of the soul in accordance with virtue."

Aristotle — Nicomachean Ethics

Resilience patterns embedded from design stage: circuit breakers, bulkhead isolation, retry with exponential backoff. Security architecture aligned to regulatory and data protection requirements. Disaster recovery and failover planning tested and documented. Accessibility compliance (WCAG) across web and mobile. Capacity planning built into ongoing governance.

The Result

High-availability services meeting security and accessibility standards. Reduced organisational risk through deliberate architectural choices rather than reactive patching.

"Technical expertise is not the sum of what you know. It is the quality of judgement you have built from everything you have been wrong about — and the intellectual discipline to keep updating it."

Neil Sherman

Technical Expertise

The toolkit

Architectural Patterns & Approaches

Layered / N-tier architectureModular monolithMicroservicesEvent-driven architectureCQRSDomain-driven designStrangler Fig patternAPI gatewayCircuit breakerBulkheadRetry with backoffRepository patternDependency injection / IoCMVCMVVMFeature flags / progressive rolloutCaching strategiesRESTful API designMessage-driven async processingMulti-tenant architectureBlameless post-mortems

Backend & API Design

JavaSpring BootSpring BatchSpring SecurityHibernateApache LuceneMessage QueuesProtocol BuffersSOAP / WSDLREST API design.NET CoreEntity FrameworkDapper

Frontend & Mobile

AngularIonicCapacitorTypeScriptJavaScriptHTML5CSS3Responsive designPrimeNGNG-ZorroProgressive web applicationsCross-platform mobile delivery

Cloud & Infrastructure

Microsoft AzureVMsApp ServicesFunction AppsAPI ManagementQueuesTable StorageDockerContainerised builds & deploymentsInfrastructure cost optimisation

Data & Databases

MySQLMicrosoft SQL ServerAzure Table StorageDatabase designQuery optimisationFull-text search with Apache LuceneData migrationETL processes

DevOps & Delivery

CI/CD pipeline designBambooBitBucket PipelinesSonarQubeGitDocker registriesPrivate NuGet & NPM hostingJUnitMockitoxUnitKarmaProtractorRelease managementFeature flag management

Security & Resilience

Security architectureData protection (public sector)Disaster recovery planningFailover strategyCapacity planningPerformance testingHigh-availability system designResilience patternsIncident managementBlameless post-mortemsMulti-tenant architecture

Accessibility & Compliance

WCAG accessibility standardsAccessible design (web & mobile)Public sector compliance

Domain Expertise

Public transport technologyJourney planning systemsReal-time passenger informationNaPTANATCOGTFSTransXChangeSIRIMulti-modal transport data integrationGeospatial data (WGS84, OSGB36)

AI & Tooling

Large language model integrationAgentic workflow designAI-assisted code analysisAI-driven market researchModel Context Protocol (MCP)Prompt engineeringStructured AI skill development

Leadership & Governance

Technical strategyMulti-year technology roadmappingArchitecture governanceDesign review & sign-offArchitecture decision documentationCoding standards across product linesTeam leadershipDeveloper mentoringCode review cultureOutsource team managementStakeholder engagementTechnical training deliveryInterview processes

Strategic & Commercial

Technology roadmap definitionVendor evaluation & selectionBuild-vs-buy analysisCloud cost management & optimisationTechnical debt identification & prioritisationBoard & senior leadership presentationTranslating technical risk into business languageCross-product architectural influenceObservability strategyCapacity planning

"Writing is not an administrative burden layered on top of real work. It is the work — the moment where thinking becomes communicable, decisions become defensible, and individual expertise becomes team capability."

Neil Sherman

Writing

Practitioner notes

Occasional writing on software architecture, engineering practices, and the tools that are changing how we build. These are practitioner notes, not thought leadership - things I've learned, built, or figured out the hard way.

AI & EngineeringMarch 2026

Lessons from the Two LLMs in Our House

What my children accidentally taught me about prompt engineering. Ambiguous prompts, context, chain-of-thought reasoning, and why feedback shapes behaviour — whether the system is an AI model or a three-year-old.

Domain-Driven DesignMarch 2026

What Public Transport Data Teaches You About Architecture

Integrating NaPTAN, ATCO, GTFS, TransXChange, SIRI. Messy data, conflicting standards, domain-driven design in practice.

Architectural PatternsFebruary 2026

Monolith, Microservices, or Something In Between

A practitioner's honest take on choosing architectural styles. When a monolith is the right call. When to introduce event-driven patterns. The real cost of distributed systems.

View all articles

Contact

Let's talk

Whether you're hiring for a senior architecture role, exploring a collaboration, or just want to talk about software architecture, legacy modernisation, or how AI is changing the way we build - I'd like to hear from you.

Based in the South West UK. Available for remote, hybrid and on-site collaboration.

Connect on LinkedIn