Essays on enterprise architecture, cloud strategy, governance, and the quieter discipline of making complex technology decisions calmly.
After more than two decades working in technology, I have learned that the most valuable lessons rarely come from textbooks, certifications, vendor presentations, or conference stages.
They come from people.
The infrastructure engineer troubleshooting a critical issue long after everyone else has gone home. The architect thinking through second- and third-order consequences before a decision is made. The operator carrying a system for years after the project team has moved on. The project manager holding together competing priorities under impossible deadlines. The mentor who takes time to explain not just what works, but why it works.
Most technology writing focuses on products, platforms, frameworks, and tools. This site focuses on the thinking behind them.
Many of the ideas shared here were shaped by conversations, projects, successes, failures, reviews, incidents, migrations, and lessons learned alongside talented colleagues over more than twenty years in the industry.
The articles on this site are not intended to provide definitive answers. They are reflections on architecture, infrastructure, cloud, governance, operations, and the practical realities of building technology that must work in the real world.
If these essays are useful, the credit belongs in large part to the many professionals whose experience, guidance, and example helped shape how I think. This collection of writing is simply my attempt to pass some of those lessons forward.
The writing falls into four lines of thought. Start with Architecture & Decisions for the strategic essays. Cloud & Migration goes deeper into datacenter exit, identity, and landing-zone work. Governance & Practice is about how architects actually operate. Infrastructure Fundamentals covers the operational layer everything else depends on.
Architecture · Cloud · Governance · InfrastructureCost, security, accessibility, scalability, and compliance never improve together. The moment a solution crosses borders they start trading against one another — and the industry you are in decides which one wins.
The other four forces trade against each other. Compliance does not trade — it deletes. A deeper cut on the only force that removes options from the table before the design even begins.
The same decision costs almost nothing when it is made early, and can cost a programme when it is made late. The mechanism behind it — explained clearly enough that you can use it in your next planning meeting.
Good architecture is not a set of diagrams. It is a set of decisions that are clear enough to be acted on, stable enough to be depended upon, and honest enough to acknowledge what they do not cover.
Architecture fails when it becomes a documentation exercise. The real work happens in the conversations that never make it into any slide deck — and in decisions made before the pressure arrives.
The organisations that age well technologically are not the ones that chose the most sophisticated architecture. They are the ones that chose the most honest one.
The same request, two systems, two outcomes. Calm architecture is not fewer features. It is fewer paths a request can take.
The cloud-native purist view has cost mid-market organisations more in stalled migrations than any technical failure ever did. A measured defence of rigorous lift-and-shift — and a closer look at which workloads actually deserve to be re-architected.
Most exits do not fail during the migration. They fail eighteen months later, when the platform that was meant to be simpler turns out to be more fragile than what it replaced. The three patterns behind year-two failure.
The layer everyone agrees is important is almost never the one anybody sequences first. Most organisations discover what identity actually was only after the migration is done. One decision upstream, four consequences down.
Multi-cloud is not a strategy. It is a posture. The organisations that get it right decide on portability before they decide on providers — and resist the urge to optimise too early.
A branch office does not need a server room. Three things on site, an honest answer to a fourth, and the tunnel home should be shrinking every year.
Most architecture review processes cover every decision lightly and protect none of them. The narrower version — strict about a few things, indifferent about the rest — is harder to design and easier to live with. A three-question triage and the discipline that follows from it.
An Enterprise Architect sees the whole. A Solution Architect solves the immediate. An Enterprise Solution Architect does both — and that difference matters more than most job descriptions capture.
AI readiness is not about buying the right tool. It is about having the data, governance, and architectural foundations that let you adopt AI sensibly — without destabilising what works.
Architecture does not fail in the data centre. It fails in the meeting room — where the right questions were not asked, and the wrong decisions were made.
Enterprise IT does not usually fail dramatically. It slows down — gradually, quietly — until the organisation realises it cannot move at the speed the business needs.
Infrastructure architecture is not about keeping the lights on. It is about building the foundation everything else depends on — quietly, correctly, long before anyone notices it matters.
The systems that hold up under pressure are not the ones built for heroics. They are the ones built to be boring — predictable, observable, designed to fail gracefully rather than spectacularly.
Noisy infrastructure does not become quiet at scale. It becomes louder. The teams that handle growth well built for predictability long before they needed it.
Most businesses think they have a backup. What they have is a copy — and the difference only becomes clear at the worst possible moment.
Cheap IT support is not cheap. The real cost shows up in hours lost, problems that keep recurring, and decisions made without enough expertise to make them well.
Waiting for things to break before fixing them is not a support model. It is a risk transfer — from your vendor onto your business, your staff, and your customers.
Five-to-fifteen people. One office. No server room. The whole stack fits in five items, and there is no second page.
Most small businesses do not have a technology problem. They have a reliability problem. And the solution is almost never the tool being sold to them.
A personal note on creating Little Architect Lab — a playful learning project that helps kids, students, and beginners understand servers, networks, cloud, cybersecurity, data centers, and AI infrastructure through simple card games.
A playful educational card game for kids, students, and beginners to learn basic technology ideas like servers, networks, cloud, security, data, backup, monitoring, and updates.
If these essays are useful, the best way to follow new writing is via LinkedIn — where I share shorter notes alongside longer articles.