Fabric
How Azure Automation Cut Microsoft Fabric Cost by 78%
Four schedules, one Fabric capacity, and a simple decision to stop paying for idle compute.
Read article →Writing
I write about decisions, not features.
Architecture notes and case studies from production work: what I built, why I chose one approach over another, what it cost, and what I would do differently next time.
Microsoft FabricLakehouse, Direct Lake, capacity, pipelines and operations
Data architectureModelling, integration, governance and trade-offs
AI engineeringPII, human review, retrieval and workflow design
Applications & integrationOperational systems, APIs, Power Platform and data ownership
Featured writing
Production work, architecture decisions, and the trade-offs left in.
Three pieces that best represent how I think about Microsoft Fabric, data architecture and AI engineering.
Case study · Microsoft Fabric
From PostgreSQL to Conversational Analytics
Designing a governed analytics and AI architecture in Microsoft Fabric, from a read-only ingestion boundary to natural-language questions that reuse the same definitions as Power BI.
Read the case study →One-person data team · Data platform
Ship one report before you build the platform
When you are the entire data function, the sequence matters more than the architecture.
Read article →What I write about
Four areas, one architectural question: what makes the whole system work?
The topics are deliberately connected. Applications create data, the platform governs it, analytics makes it useful, and AI eventually brings some of that intelligence back into the workflow.
Microsoft Fabric
Architecture choices, workload behaviour, capacity, Direct Lake, pipelines and the operational side of running Fabric in production.
Data architecture
How source systems, lakehouse layers, dimensional models, semantics and governance fit together — and where the seams fail.
AI engineering
Practical AI inside business workflows: retrieval, document intelligence, privacy controls, human review and responsible implementation.
Applications & integration
Operational systems, APIs, PostgreSQL, Power Apps, Dataverse and the decisions that determine who owns the data a process creates.
All writing
Technical notes from the work itself.
The three featured pieces stay highlighted above. New articles and shorter technical notes will collect here as the archive grows.
AI
Redact before the model, not after
If personal data reaches the model, redacting the output is theatre. The only control that counts sits upstream of the call.
Fabric
Direct Lake is not a free upgrade
Direct Lake reads Parquet straight from OneLake with no refresh step. That removes a whole class of problems and introduces a smaller, sharper one.
One-person data team
From Laptop to Azure, Part 2: Taking Django + React from DEV to Production
Building a repeatable Azure deployment path for Django and React, with automatic DEV deployments, deliberate PROD releases, PostgreSQL, custom domains and HTTPS.
One-person data team
From Laptop to Azure: Designing an Enterprise Django + React Stack — Part 1: The Local Foundation
How I designed the local foundation for an enterprise Django and React application so the move from a developer laptop to Azure does not require rebuilding the architecture.
Power Platform
The SharePoint list that became a database
Every list starts as a convenience. The question is what happens on the day someone needs a second table.
How I write
The useful part is usually the decision behind the implementation.
I am less interested in reproducing documentation than in explaining why a particular design made sense in a particular situation.
Start with context
A technology choice is difficult to judge without the workload, constraints, users, cost and operational environment around it.
Show the trade-off
There is rarely a universally correct architecture. I try to make clear what a decision improves, what it complicates and when I would choose differently.
Keep it close to production
Examples matter more when they include the details that demos skip: deployment, security, handover, cost, failure modes and maintenance.
Why I write
Writing is part of how I test whether I understand the architecture.
Explaining a decision forces the assumptions into the open. If I cannot describe the trade-off clearly, I probably have not understood it well enough yet.
The same habit carries into consulting work: architecture discussions, stakeholder conversations, documentation, runbooks and technical handover all depend on making complex decisions understandable.
1,000+practitioners trained across 12 countries — teaching and explanation have been part of my work for years.
See teaching & knowledge transfer →
Connect
Interested in the architecture behind the work?
I am based in Edmonton and work across Microsoft Fabric, application architecture, data platforms and AI-enabled business workflows.
Or get new writing by email