Structuring Terraform Modules for Reuse
How to split a flat Terraform config into versioned, composable modules with clear inputs, outputs and boundaries — and how to know when a module is premature abstraction.
Pillar: Pillar 02 - Architecture Comprehension
Pillar 02 · See
Platform Consolidation vs Best-of-Breed: The Question That Actually Decides It
“Consolidate onto one platform” and “pick best-of-breed for each function” both get argued as if one is universally right. Neither is. The question that actually matters is which specific cost each approach is asking you to accept — and most organisations pick a side before anyone has named the cost honestly. Consolidation’s advocates point to …
The AI Act’s Obligations, Translated Into Actual Engineering Deliverables
Ask a compliance team what the AI Act requires and you get articles and annexes. Ask the engineering team building the actual system and you get a shrug, because nobody has translated “conduct a fundamental rights impact assessment” into a sprint they can actually plan. That translation gap is where AI Act compliance programmes quietly …
Deterministic Automation vs Agentic Autonomy: Choosing the Right Level of Non-Determinism
Every automation decision now defaults to “can we make this agentic” when the actual first question should be “does this need to be.” Deterministic automation and agentic autonomy solve genuinely different problems, and picking the more exciting one for a task that needed the boring one is a specific, recurring, expensive mistake. Deterministic automation — …
How to Audit a Technology Estate You’ve Never Seen Before
Walking into an organisation on day one and being asked “so, how are we doing” is the single most common moment in fractional CTO work, and it’s also the moment where a wrong first move costs months. There’s no existing context, no institutional memory of past decisions, and a genuine risk of either taking too …
AI as Amplifier: Why It Makes Good Engineering Orgs Better and Bad Ones Worse
AI doesn’t make an engineering organisation good or bad. It makes a good one better and a bad one worse, faster than either outcome would have happened without it — and the organisations most excited about AI’s productivity gains are frequently the ones with the least visibility into which of the two they actually currently …
Architecture Before Technology Selection: A Repeatable Decision Sequence
I’ve written about why regulation, and the data model, both have to precede the tool. This is the practical version of that argument — not the philosophy, the actual repeatable sequence, usable on any technology decision regardless of size, that keeps the reasoning from collapsing into “let’s just look at some vendors” by the second …
Process Design Before Tooling — Always
Automating a broken process makes the business bad at the process faster. This is one of the oldest observations in operations management, and technology teams rediscover it painfully, at real cost, every time a new tooling category makes automation newly tempting — which is, currently, constantly. I’ve written about the data model and the architectural …
Reading a Vendor Contract Like an Architect, Not Just a Lawyer
A vendor contract gets read twice, usually: once by legal, checking liability and indemnity language, and once by procurement, checking price and payment terms. Almost nobody reads it the third way that actually matters for a technology decision — as a specification of the system’s actual architecture, written in legal language instead of technical language, …
Small Language Models in the Enterprise: When Smaller Beats Frontier
Every AI procurement conversation defaults to the largest, most capable frontier model available, on the reasonable-sounding assumption that more capability is always better. For a genuine majority of real enterprise use cases, that assumption is wrong, expensively so, and a smaller, narrower model would do the actual job better, faster, and at a fraction of …