Architecture & engineering notes
Practical notes on architecture, production engineering, and applied AI from 28 years of building software.
Latest essay
The tools keep changing. My architectural responsibility stays the same: understand the real problem, make tradeoffs visible, and stay accountable through delivery and operation.
Read the latest articleMore writing
24 published articles
I’m building ArchGauge to review architecture evidence and Acme FieldOps to test those reviews against known strengths, defects, fixes, and gaps in evidence.
I am using AI-103 study to connect Azure AI features with the harder work of designing, evaluating, securing, and operating an AI application.
Architects rarely receive complete information. A sound decision makes risk visible, gathers useful evidence, and preserves a safe path to correction.
Before an enterprise connects AI to operational data, it needs data products with an owner, a stable meaning, enforceable access, quality evidence, and a support contract.
BlazeOS carries ListBlaze’s workflow evidence into a rebuild centered on explicit ownership, local-first operation, immutable evidence, and recoverable marketplace effects.
Give an agent more authority only when the use case has earned stronger identity, evaluation, approval, audit, and recovery controls.
AI quality is not one score. It is a versioned agreement about useful behavior, unacceptable failure, and the evidence required for change.
Not every AI problem needs RAG, tools, or an agent. Add probabilistic behavior and autonomy only when each layer earns its cost and risk.
Telemetry is useful when it helps someone decide, diagnose, or recover. Start with the questions people need to answer on a difficult day.
ListBlaze used AI to speed marketplace listing preparation while keeping source evidence, approval, durable state, and recovery visible.
A feature can work and still be unsafe to operate. Production readiness is evidence accumulated across the whole workload, from design through recovery.
An AI agent should not become a shortcut around the identity, authorization, data, and audit controls required by the underlying business action.
A mature pipeline does more than automate deployment. It reduces uncertainty, limits blast radius, and makes recovery a practiced part of delivery.
A template can create resources. A mature IaC practice makes infrastructure changes reviewable, repeatable, observable, and recoverable.
Choose whether to build, buy, or integrate by weighing which capabilities are worth owning and which risks the organization can support over time.
Connecting acquired systems is easy to draw and hard to operate. The work begins with meaning, authority, identity, and a migration path.
Cloud analytics can create value from operational data without turning an IT application or AI model into an unrestricted control path.
Offline-first design changes the product promise: teams must define data authority, conflict handling, security, testing, and support before synchronization.
WellOS showed me the cost of a broad oilfield platform, so I chose a narrower product with a clearer promise and a shorter path to operational evidence.
WellOS was a personal project for exploring connected oilfield workflows. Building it taught me where the product scope needed to narrow.
Good oil and gas software starts with the person, decision, constraint, and operating consequence in the field, then earns its technology choices.
WellOS began with a practical question: how can field work, operational data, and business workflows connect while preserving trustworthy boundaries?
I earned AZ-900 and AI-900 to connect 28 years of software delivery with the cloud and AI choices facing local oil and gas companies.