Deep technical essays and executive frameworks for CTOs, CIOs, and engineering leaders navigating AI, data, cloud, and platform decisions. Written from 19+ years of making technology and engineering decisions at scale.
All Essays & Frameworks
12 articles
RAG, fine-tuning, and the architectural decisions that separate pilots from production.
Most GenAI pilots never reach production. The gap is not model quality — it is architecture. Retrieval-augmented generation, fine-tuning, and prompt engineering each solve different problems. Choosing the wrong one is the most common and most expensive mistake in enterprise AI.
A clear-eyed assessment of the most over-hyped pattern in modern data engineering.
Lakehouse architecture solves real problems. It also creates new ones. The organisations that benefit from it made a deliberate choice based on their data volume, query patterns, and team capability — not because a vendor told them it was the future.
FinOps is a decision-making discipline. The organisations that solve cloud cost do so by changing how decisions are made.
Most cloud cost problems are not engineering problems — they are accountability problems. The organisations that solve them do so by changing how decisions are made, not by buying another cost management platform. This is a leadership intervention, not a tooling problem.
The organisations that understand this ship faster. The ones that don't keep hiring.
Platform engineering is a product discipline — the customer is the engineering team. When it is treated as infrastructure, it optimises for the wrong outcomes: uptime over developer velocity, stability over capability, cost over leverage. The distinction matters enormously at scale.
A structured diagnostic for technology leaders who need to know where they actually stand before committing to an AI investment.
Every organisation believes it is ready for AI. Very few are. Readiness is not about having a data science team or a cloud environment. It is about data quality, governance, and the organisational alignment to turn a model into a business outcome. This framework surfaces the gaps before the investment is made.
The technology is the easy part. The domain ownership model is where most implementations stall.
Data Mesh is an organisational pattern, not a technology pattern. The teams that succeed with it invest heavily in domain ownership, data contracts, and federated governance before they write a single line of infrastructure code. The teams that fail treat it as a platform migration.
Monitoring tells you when something is wrong. Observability tells you why.
The shift from monitoring to observability is not a tooling upgrade — it is an architectural philosophy. Systems designed for observability emit structured telemetry as a first-class concern. Systems that have monitoring bolted on are permanently reactive. The difference compounds at scale.
An illustrative scenario examining what happens when technology investment is decoupled from business outcome.
Illustrative Scenario. A global enterprise invested $40M in a modern data platform over three years. At the end of year three, the platform was technically impressive and business-irrelevant. The failure was not in the engineering — it was in the framing of the problem from day one.
Autonomous agents are not a feature. They are a new class of system that requires a new class of architecture.
Agentic AI systems — models that plan, use tools, and act autonomously — introduce failure modes that traditional software engineering has no playbook for. The organisations that deploy them safely will have made deliberate architectural choices about orchestration, memory, tool access, and human oversight.
Most organisations end up multi-cloud by accident. The ones that benefit from it chose it deliberately.
The difference between a multi-cloud strategy and a multi-cloud accident is a clear-eyed assessment of what each cloud does well, and a governance model that prevents the worst of both worlds. Without that, multi-cloud compounds cost and complexity without delivering the resilience or leverage it promises.
A structured approach to assessing technology capability across six dimensions before making a major investment.
The Enterprise Technology Readiness Framework emerged from a consistent pattern: organisations making large technology investments without a clear picture of their current capability. The framework provides a structured diagnostic across AI readiness, data maturity, cloud economics, engineering reliability, data governance, and security.
An illustrative scenario in platform engineering transformation.
Illustrative Scenario. Three weeks to deploy a feature is not a deployment problem — it is an architecture problem. This scenario traces an 18-month transformation of a 95-engineer organisation from a monolithic deployment model to a platform-enabled continuous delivery capability, including the organisational and technical decisions that made it possible.
Every engagement begins with a 30-minute conversation about the technology decision you are facing.
