Architecture & Work
Each entry is labelled for what it is. The goal is to show the decisions, trade-offs and validation behind a design — the parts an architecture interview should probe.
Delivered case study
Work that shipped, described only with facts I can verify and share. None are published yet; client work stays confidential unless approval exists.
Reference architecture
A reusable approach to a recurring class of problem — the decisions, structure and failure modes I would design around.
Technical exploration
A design exercise that reasons through scale or a new capability. Numbers are stated assumptions, not results.
A reference architecture for moving hundreds of .NET Framework applications forward: evidence-based assessment, per-application paths, dependency-aware waves, and release gates you can defend.
Read the architecture
A reference architecture for using LLMs to analyze legacy code without trusting them blindly: deterministic facts first, targeted model interpretation, independent validation, policy-based acceptance and a full audit trail.
Read the architecture
Next conversation
I'm interested in technical architecture challenges where the decisions matter and the engineering has to hold up in production.