If you’re building with Materialized Lake Views (MLVs), you’ve probably felt the tension: the definitions live in code, but the Lakehouse itself is an environment-specific artifact. That gap is where deployments get messy—schemas drift, tables don’t exist yet, and MLV refresh behavior looks “random” when it’s really just reacting to configuration. This post lays out a pattern that closes that gap cleanly: a lakehouse configuration notebook that you promote through your deployment pipeline and run in every environment to create schemas, tables, and MLVs idempotently—using SQL cells only. The key is that MLVs are treated as “definition-driven assets” that can be iterated in dev and re-stamped into test/prod with the same notebook.

In financial services, the questions that matter most are rarely answered by “the latest record.” Regulators, auditors, model validators, and operations teams want something more specific: what was true for the business at the time, and what did we know at the time? That’s bitemporal thinking—and it’s exactly the kind of problem where Microsoft Fabric’s Lakehouse on Delta becomes more than storage. It becomes a practical design advantage. In this post, I’m going to walk through what bitemporal tables actually require, why intervals matter (ValidFrom/ValidTo), and how to implement bitemporal efficiently in Fabric by leaning into #DeltaLake in the Lakehouse.

DirectLake on OneLake is one of those “this is what we’ve been waiting for” features in Microsoft Fabric—until you try to deploy it cleanly across Dev → Test → Prod and realize you’ve re-entered the world of post-deployment manual fixes. In this how-to, I’m going to do three things: Contrast DirectLake on SQL endpoints (the “classic” flavor) with DirectLake on OneLake (the newer flavor), and explain why OneLake is worth the trouble. Walk through the normal deployment pipeline approach that works well for DirectLake on SQL. Show a two-step, semi-automated approach for DirectLake on OneLake using: …

DirectLake has a way of sounding wonderfully simple: “Power BI, but it reads the lake directly.” Then you build two semantic models that both say DirectLake, and they behave… differently. One falls back to DirectQuery when you least expect it. Another refuses to touch your SQL views. Security works for you, but not for your report consumers. Suddenly, “DirectLake” feels less like a feature and more like a riddle. The good news: this is explainable. And once you understand the two flavors—DirectLake over SQL and DirectLake over OneLake…

Most financial services data is already “connected.” It just isn’t modeled that way. Fraud rings don’t show up as a single row. Money laundering doesn’t announce itself in one transaction. Counterparty exposure isn’t obvious from one booking. The meaningful signal lives in relationships: who shares an address, which accounts route funds through the same nodes, where devices and identities overlap, and how risk propagates through a network. Graph in Microsoft Fabric is designed for exactly that: turning your OneLake data into a connected model you can explore visually, query with GQL, and enrich with built-in graph algorithms—without standing up a separate graph stack and duplicating data.

A schema change is rarely “just a schema change.” It’s the moment an upstream team’s perfectly reasonable adjustment becomes a downstream team’s broken report, confusing metric, or silent misinterpretation. And that’s why schema evolution has always been a source of anxiety: a schema isn’t simply structure—it’s an interface. In this post, I’ll do three things. First, I’ll ground why schema evolution has historically been such a persistent concern. Next, I’ll reframe Medallion with Gold as the published surface area of the data product, and Silver as an optional workshop layer where data is supplemented and transformed.

Copilot in Power BI isn’t “one feature.” It’s a growing set of experiences that show up in different places, behave differently, and—most importantly—solve different problems. That’s why two people can both say “Copilot didn’t work for me,” and both be right. One might be trying to generate a report page in Desktop. Another might be trying to chat across any model in their tenant. A third might be expecting an agent-like experience that stays grounded in a curated subject area. In this post, we’ll map the major modes of Power BI Copilot (where it shows up, what it’s best at, and what it’s 

If you’ve ever clicked Deploy in Fabric, watched the spinner, and hoped nothing “mysteriously” changed in Test or Prod… you’re not alone. Microsoft Fabric has made it possible to manage analytics artifacts like software. But getting to reliable releases—repeatable deployments, environment-safe configuration, and auditable changes—still takes intent. In this post, I’ll walk through a practical, production-minded approach to CI/CD in Microsoft Fabric: how to structure Deployment Pipelines, where Git fits, how Variable Libraries and Deployment Rules reduce environment drift, and when to lean on Fabric-CICD and APIs to move beyond the UI.

There’s a pattern I see in mature analytics organizations: as soon as the data platform gets big enough to feel “enterprise,” someone reaches for domain-driven design (DDD) as the organizing principle for data engineering and governance. It’s an understandable move. DDD gives us language for ownership, boundaries, and “this team is responsible for that thing.” And when you’re trying to untangle a spaghetti warehouse, that sounds like oxygen. But here’s the catch: the most valuable data in a warehouse—the fact tables in traditional star schemas—often doesn’t live neatly inside a single domain.

Microsoft Fabric’s Warehouse can now materialize external files into tables with straight‑ahead T‑SQL, and Materialized Lake Views (MLVs) have quietly leveled up with optimal refresh (including incremental) and stronger, UI‑backed monitoring. If your north star is Zero unmanaged copy, the question isn’t “should I materialize?”—it’s “how do I materialize responsibly under OneLake governance?” Here’s what changed since our last take—and what to use when.

The first time someone asks for “real‑time,” it sounds like a small tweak: refresh the dashboard faster, trigger an alert sooner, show a counter that feels alive. In a data platform, that single request quietly changes everything—how you ingest, how you process, how you serve, and how you operate. This post keeps it practical. It frames real‑time as a freshness target (not a vibe), walks through the two taxes real‑time introduces—architectural complexity and cost—and shows how patterns evolve as you scale from modest #StreamingData to internet‑class velocity. It also folds in recent Microsoft Ignite announcements that matter for real‑time platforms, including SQL Server 2025’s “change event streaming” and near real‑time analytics via OneLake/Fabric mirroring, plus the continued maturation of Microsoft Fabric’s Real‑Time Intelligence building blocks.

By the end of 2025, the conversation around analytics stopped being about dashboards and started sounding a lot more like operations. The rise of autonomous and semi-autonomous agents put a sharper edge on an old truth: AI only becomes an enterprise capability when the underlying data is trusted, discoverable, and defensible. Microsoft Fabric and Microsoft Purview spent 2025 building toward that reality from opposite (but increasingly overlapping) sides of the house. Fabric pushed the platform forward—unifying workloads, expanding OneLake, and adding new intelligence and database capabilities designed for AI-era workloads. Purview tightened the governance and security loop—making data quality, cataloging, risk visibility, and policy enforcement feel less like a separate initiative and more like part of the daily flow.

There’s a moment in every Fabric semantic model lifecycle where the “click it in the UI” approach stops scaling. It usually happens when you need to rename dozens (or hundreds) of fields to match a business glossary, or when Dev is stable and you’re ready to point the same model at a new Lakehouse for Test/Prod. That’s when the model stops being a diagram and starts being an artifact—something you want to treat like code. This guide reflows the whole workflow end-to-end, using the Fabric service Edit in Desktop experience to open the model, exporting it to a PBIP project stored as a TMDL folder, editing that folder externally (no scripting inside Power BI Desktop), and then getting those changes back into the service—

Financial Services, Insurance, Wealth Management, and Professional Services have a gift—and a curse—when it comes to data. The gift is that these industries know how to run critical systems with discipline. The curse is that we’re so good at controlling risk that we often rebuild the same constraints in every new platform we adopt. That’s why so many “modern cloud data platforms” in these sectors end up feeling like the old data warehouse with a new hosting model: better infrastructure, familiar bottlenecks.

Every enterprise carries a shadow backlog—the should‑do work that never beats the urgent. It’s the reconciliation that almost closes, the control that’s “fine for now,” the evidence that exists but isn’t filed where audit will accept it. None of these items is existential in isolation; together they become trust debt: silent risk, rework, slower decisions, and reputational drag. 2025 amplified the problem.

Monday, 9:02 a.m. The CFO pings: “What was Q3 gross margin by region—and did audit call out any risks?” Your RAG bot shines on PDFs and wiki pages, but it can’t compute a number you’d put on a KPI card. After Ignite 2025, the answer is cleaner than ever: let a Fabric Data Agent generate and run a governed query for the metric, and let your RAG retriever bring back the one‑sentence risk note.

If you work with Microsoft Fabric long enough, it’s easy to come away with the impression that “real” Fabric means “medallion everywhere.” The official docs walk through Bronze, Silver, and Gold patterns for lakehouses. The learning paths lean on medallion as the canonical example. Fabric clearly makes medallion a first‑class citizen. But that doesn’t mean your data platform – or your data products – must be medallion‑shaped.

If your acceptance criteria live in a comment thread, they’re not requirements—they’re opinions. Spec‑driven development (SDD) turns those opinions into executable truth so code, tests, docs, and operations move in lockstep. Building on our split between functional and nonfunctional requirements, this follow‑up introduces spec‑driven development: what it is, why it reduces drift, and how to run it inside agile without ceremony.

We like to say we’ve “transformed” how work gets done. But if you look closely at many enterprise systems, you still see the outline of a paper form hiding under a slick UI. We replaced paper with terminals, terminals with web apps, web apps with SaaS—and then pointed automation at the whole stack. In too many places, we’ve simply substituted one medium for another, without asking whether the underlying process still makes sense.

If you’ve ever shipped a feature that “works” and still disappointed users, you’ve met the gap between what a system does and how well it does it. That gap is the space nonfunctional requirements occupy—and it’s where agile teams win or lose product trust. In this continuation of our requirements series, we’ll clarify the difference between functional and nonfunctional requirements, show how to make nonfunctional requirements measurable, and connect both to practical agile habits—user stories, acceptance criteria, Definition of Done, SLOs, and pipeline checks.

AI agents are showing up everywhere in the enterprise: Copilot add‑ins, line‑of‑business copilots built in Studio, “helper” bots glued onto SaaS apps, home‑grown automations running in the background. Individually, each one looks harmless. Collectively, they turn into something more dangerous: agent sprawl. You get dozens (soon hundreds) of agents with overlapping responsibilities, inconsistent permissions, and no clear answer to a basic question: …

Yesterday we went deep on Fabric IQ’s Ontology—the shared vocabulary that teaches Microsoft Fabric how your business actually talks. Today we’ll zoom out to everything else: the graph that lets insights travel across relationships, the agents that answer questions and watch your operations in real time, and the governance and integration that make it usable at scale.

AI agents don’t fail for lack of data—they fail for lack of meaning. Microsoft Fabric IQ’s new ontology capability tackles that head‑on by modeling the business concepts, relationships, and rules that live across your estate, then binding them to live data so agents (and people) can ask better questions and take smarter action.

In brief: SQL Server 2025 is generally available with built‑in AI, major developer conveniences, sturdier performance/availability behaviors, and licensing/edition changes that lower the cost of entry. Below I frame the release around three themes—AI + developer experience, performance + resilience, and product/edition shifts—and close with concrete first steps you can act on today.

SAP and Microsoft have just taken away one of the biggest excuses for slow analytics and AI on SAP: “We can’t move that data safely or reliably enough.” At Microsoft Ignite 2025, they announced SAP Business Data Cloud (BDC) Connect for Microsoft Fabric—a new capability that lets you share SAP Business Data Cloud data products and Microsoft Fabric data sets bi‑directionally, with zero‑copy, and have those products show up natively in OneLake and back in BDC.