EduDataSci – Educating the world about data and leadership – Data Strategy from a one time K-12 data architect

What Replaces Purview Data Governance?

Microsoft is retiring Purview Data Governance. What can OneLake Catalog take over today, and where will enterprises need to replace scanning, lineage, glossary, quality, and approval workflows?

A claims analyst looking for paid claims in Fabric might find a warehouse table, a Power BI semantic model, and three reports with nearly the same name. The analyst needs to know which one Finance uses and whether the paid amount includes reversals. If the number goes into a reserve review, someone may also need to trace it back to the source and show who approved access. All of that work falls under data governance, and the catalog has to support more than the initial search.

On November 12, 2026, Microsoft announced the retirement of Purview Data Governance and named Microsoft Fabric, with OneLake Catalog, as its data governance platform. Support ends November 12, 2027. Microsoft’s Partner Center notice puts Unified Catalog, Data Map, Workflows, and the older Azure Purview governance offerings in scope. Microsoft has closed new governance account creation and put existing capabilities in maintenance mode through the end of support.

Microsoft Purview continues to handle data security and compliance. In Fabric, that includes sensitivity labels, data loss prevention, and audit. A steward who depended on a Data Map scan to identify sensitive fields in an upstream system still has to account for that scan in the transition. The security policy and the source scan do different jobs.

Where OneLake Catalog fits

I like the direction for organizations that already do much of their analytical work in Fabric. In OneLake Catalog, the analyst can use Explore to find the certified claims model, identify its owner, and see the lineage Fabric captures. If the model is configured to be discoverable, the analyst can request access from the catalog. The team that owns the model can use Govern to check curation and sensitivity label coverage, and workspace administrators can use Secure to review permissions and manage supported OneLake security roles. The people making those decisions work with the same items the analyst finds.

That proximity matters when someone uses the model outside the Fabric portal. An analyst can discover it from Excel. If the team makes it available through a Fabric data agent, the agent honors the user’s permissions on the underlying data. Finance still owns the definition of paid claims. A clear description and a certified model give people a better chance of finding the measure Finance actually uses.

OneLake also reaches selected data outside Fabric. A shortcut can reference files in Amazon S3 from a Fabric lakehouse. Metadata mirroring can surface supported Azure Databricks Unity Catalog tables while reading the data in place. Database mirroring, as with Azure SQL Database, continuously replicates data into OneLake. Those are different ways to bring external data into Fabric’s working environment. With an external shortcut that uses a configured connection identity, for example, the source authorizes that identity and OneLake controls which Fabric users can read through the shortcut. That detail matters if the analyst also has a direct way to reach the source.

The jobs that need a replacement

A team that used Unified Catalog to find Fabric assets has a straightforward starting point. A steward who used it to maintain a business glossary, approve access to a data product, and report on quality across several platforms has a broader migration. Here is how I would map that work against the capabilities Microsoft documents today.

Purview capability	What Fabric covers today	What the transition needs to cover
Discovery and domains	OneLake Catalog searches Fabric items and supported tables. Owners, tags, and endorsements provide context, and Fabric domains group workspaces by business area.	Carry over who owns and stewards each business domain, including assets managed outside Fabric.
Data Map scanning	Fabric offers tenant metadata scanning for Fabric items. Shortcuts and mirroring make selected external data or catalogs visible in Fabric.	Replace scheduled scans of external systems where teams rely on Data Map’s source-specific inventory, schema, and classification coverage.
Lineage	The catalog shows dependencies for supported Fabric items. The workspace lineage view can show external upstream sources one step away.	Preserve the path through external transformations, including column-level lineage where a report or control depends on it.
Business glossary and data products	Fabric item descriptions, endorsements, and semantic models carry business context into discovery and use.	Rehome governed glossary terms, relationships to critical fields, and curated data products that group assets across platforms.
Data quality and health	Govern tracks catalog and security posture. Fabric can apply row-level quality constraints during materialized lake view refreshes.	Replace the profiling, recurring rule runs, and quality scores reported across assets, products, and domains. Preserve the history teams use to monitor changes.
Access and publication workflows	Fabric supports access requests for discoverable semantic models and provides controls for reviewing and granting Fabric permissions.	Replace product access and publication workflows, including approver routing, terms-of-use attestations where required, and approvals to publish glossary terms.

Take the claims example. The Fabric lineage view can show the warehouse and semantic model behind a report. If a Snowflake transformation assigns the reversal flag, Finance needs to be able to follow the number through that transformation as well. Fabric can consume a supported Snowflake output through a shortcut. Tracing how the reversal flag was calculated requires lineage from the Snowflake transformation itself. For a reserve review, Finance needs to be able to follow both parts of that path.

Quality is a similar case. A Fabric engineering team could implement a rule in a materialized lake view to keep records with a missing payment identifier out of the curated table. The steward’s job includes tracking whether the rate of missing identifiers is rising and finding which upstream system introduced the problem. If the team uses Purview’s quality reports for that work, the replacement needs somewhere to store and compare rule results over time. A Fabric team could use a shared results table and report. Teams running the same checks across several platforms may need a data quality or observability tool that can pull the results together.

Fabric IQ’s ontology, currently in preview, gives the business context a place in Fabric. A team can model Claim and Payment as entities and represent how a payment relates to a claim. An agent can then use those relationships when answering questions. The steward still needs a process for approving the official definition of a paid claim, relating that definition to fields across platforms, and notifying teams when it changes.

I would make OneLake Catalog the entry point for Fabric users. Where an enterprise already runs important workloads across several platforms, I would also keep an enterprise catalog that can scan those systems and maintain the business context they share. Microsoft names Atlan, Alation, Collibra, and Informatica as integration options. If a team uses two catalogs, it should decide where stewards maintain the authoritative glossary and product definitions so the claims team has one place to change what “paid” means. Fabric governance is included in Fabric capacity. The cost of maintaining enterprise coverage depends on which other jobs and systems the organization needs to support.

I’d start the transition with a data product someone already depends on. Carry its definitions, ownership, and quality rules forward, then have a consumer find it, request access, and trace a reported number to its source. Have the steward retrieve the approval and quality history. Microsoft’s Purview self-serve analytics can publish metadata about domains, products, glossary terms, subscription requests, and quality rules and results into OneLake or Azure Data Lake Storage. That gives teams a starting inventory and a way to preserve some of the evidence they’ll want during the transition. If the approval record is part of a regulatory control, I’d review that workflow with Microsoft early, as the retirement announcement recommends for highly regulated customers.

Microsoft has already been improving discovery in OneLake Catalog. At FabCon Barcelona, it showed how users could go beyond the item name to inspect tables and columns in the catalog. Every step like that makes it easier for a data owner to give people the context they need before they start working with the data.

Microsoft Ignite is next week, November 17–20, and we may hear more about OneLake Catalog there. I’ll be listening for improvements to business glossaries and lineage across platforms. I’d like the next analyst looking for paid claims to be able to find the approved definition and trace the reversal back to its source from the same place they found the model. That feels within reach.

Buying Azure Commitments for a Changing Estate

Azure commitments should reflect the estate the organization intends to run. Connect management-group recommendations to hourly demand, migration plans, allocation and purchasing decisions, with an illustrative model of unused commitment.

A cloud discount can be attractive and still be the wrong purchase. That happens when the usage behind the recommendation belongs to an estate the organization has already decided to change. Servers will retire, applications will move, a project will finish, or a platform team will remove capacity that was provisioned for a demand peak.

Microsoft’s September 29, 2026 announcement of management-group-scoped savings plan and reservation recommendations gives central teams a broader view of that decision. They can evaluate recommendations across the subscriptions represented by an organizational hierarchy. The improvement is useful, but it does not turn historical usage into a forecast.

The business task is to buy against the eligible demand the organization expects to retain. That requires a shared decision between finance, FinOps and the people accountable for the modernization roadmap. A percentage discount is one input. The amount of commitment the future estate can consume is the other.

Build Enterprise Prototypes with Lovable and Microsoft

A practical capacity-planning example connects a tested HTML prototype to Microsoft Copilot Managed Runtime through Lovable, then develops the templates, access checks, and ownership needed to support multiple teams.

The useful next step after generating an HTML application is to preserve its behavior while changing the way it is operated. A local calculator can establish the interface and calculation. A tenant application adds organizational identity, a controlled data connection, and a place where colleagues can use the same version.

This walkthrough carries the capacity-planning example from From One HTML File to Enterprise Software through that transition. We will define a small calculation, generate a standalone prototype, rebuild it for Microsoft Copilot Managed Runtime through Lovable, and connect it to a synthetic SharePoint list. We will then turn the pattern into a reusable prototyping service for multiple teams.

The accompanying starter package contains a complete HTML reference, its calculation source, fixtures, prompts, and tests. Fourteen calculation checks were executed locally. Tenant deployment, browser rendering, access controls, and load behavior have not been tested here; the walkthrough identifies the checks to perform in your environment.

I Am a House Floof. You Get the Door.

I heard the doorbell. My ears work perfectly well from down here. Why this should involve my legs remains unexplained.

Dear humans who keep looking at me when the doorbell rings,

I heard it.

My ears work perfectly well from down here. I am aware that somebody is outside. What I do not understand is why this information is being treated as a reason for me to stand up.

FUAM and the Business of Running Fabric

FUAM’s latest updates give Fabric leaders more useful evidence for capacity investments, workload improvement, ownership, and access reviews.

A request for more Microsoft Fabric capacity often arrives with a familiar explanation: usage is growing, performance is slipping, and the platform team needs more room. Approving the request may be entirely reasonable. But a business leader should also be able to ask what is consuming the capacity, which services depend on it, and whether the proposed spending addresses growth or avoidable inefficiency.

Fabric Unified Admin Monitoring, or FUAM, helps assemble the evidence for that conversation. Its latest published updates make it more useful to leaders who need to connect platform operations with spending, ownership, and business priorities.

As of October 17, 2026, the newest dated entry in the FUAM changelog is release 2026.6.1, published June 2. The developments below support a more informed discussion about how the organization runs Fabric.

Deploying Lovable Applications to Azure with Continuous Delivery

A team builds a useful application in Lovable. The workflow makes sense, the screens are good enough to put in front of users, and somebody asks when it can become an internal service. That is the point at which the conversation changes. The application needs an owner, a production identity, somewhere appropriate to run, and a way to release the next version without reconstructing the deployment by hand.

Azure App Service can provide that operating environment. Lovable can continue to provide the development experience. A Git repository connects them, giving the organization a place to review the generated code and decide which version becomes a release.

I have put together a reusable deployment starter for that arrangement. It includes infrastructure in Bicep, GitHub Actions workflows, a small deployment runtime, environment configuration, and an adoption guide. The design supports both the older React and Vite applications and the newer TanStack Start applications produced by Lovable. This article explains the choices in the package and walks through adopting it for an internal delivery-review application.

Azure and the Next Round of Enterprise Modernization

Azure’s September and October announcements point to a platform taking on more of the work of running the enterprise estate. This editorial examines what changed in compute, Kubernetes, networking, security and hybrid operations, and what that direction means for customers.

An application can be running perfectly well while the infrastructure beneath it becomes harder to expand, more expensive to retain, or more demanding to operate. That is a familiar enterprise problem, and it provides a useful way to read Azure’s announcements since the beginning of September. Microsoft is changing how customers plan the life of a virtual machine, where Kubernetes can run, and how much of the surrounding operational work the platform can absorb.

I see Azure becoming more deeply involved in the continuing operation of the enterprise estate. The latest developments extend its management model onto customer hardware while making the public cloud more capable of maintaining itself. This is a sensible direction for organizations with long-lived applications and mixed infrastructure. It also gives Microsoft a larger role in their architecture and spending decisions. The changes through October 17 make that direction much more concrete.

Modernization becomes a continuing obligation

The VM lifecycle policy published on September 28 establishes four stages: Current, Extended, End of Life and Retired. Current families are the preferred destination for new deployments. Extended families remain supported, with transition planning encouraged. End of Life means retirement has been announced, while maintenance and support continue; capacity, purchasing options and pricing can become less favorable. At retirement, remaining VMs are deallocated and lose support and SLA coverage. The initial policy covers general-purpose, memory-, compute- and storage-optimized families. It makes the consequences of retaining older infrastructure much more explicit.

For example, Microsoft’s retirement guidance for Dv3, Dsv3, Ev3 and Esv3 sets November 15, 2029 as the deadline in the affected public-cloud environments, excluding government, 21Vianet and sovereign regions. Capacity growth restrictions already apply separately. An application owner therefore has to consider whether a workload can expand or be redeployed as well as whether it runs today. HPC Pack 2019’s end of support in August 2027 creates a related planning task for organizations relying on that cluster-management and scheduling stack. Cloud adoption has not removed infrastructure renewal from the budget.

There are new destinations for that renewal. The Lasv5 and Laosv5 VM families reached general availability on September 29. They combine fifth-generation AMD EPYC processors with substantial local NVMe storage for workloads such as caching and distributed storage. Laosv5 provides three times the local storage capacity per vCPU of Lasv5. The useful distinction is the resource balance: organizations can choose a denser storage configuration without treating every storage-heavy workload as a reason to buy proportionately more CPU.

Azure Migrate’s September previews address the work needed to reach a new environment. Network assessments examine VMware environments, including NSX, and recommend Azure networks, security controls and load-balancing resources alongside readiness and cost estimates. Auto Wave Planning uses inventory, assessment results, application mappings and dependencies to propose migration groups and their order. Together, these features bring the application’s connections and sequencing into the migration plan. That is a substantial improvement over a project organized around a list of servers, because moving the machines is only useful if their applications can still communicate.

The management-group scope added to savings-plan and reservation recommendations also fits this broader view. Finance and platform teams can evaluate opportunities across an organizational hierarchy of subscriptions, rather than assemble every subscription’s picture separately. I would connect this directly to modernization planning. A recommendation based on consumption is useful evidence, but a commitment should reflect the infrastructure the business expects to retain. Microsoft is improving the view of current demand; deciding which demand will survive a migration remains an architectural and financial judgment.

Azure management reaches further into the estate

The September 22 public preview of AKS flex nodes lets an existing Azure Kubernetes Service cluster use worker nodes in other Azure regions, on premises or at the edge. An encrypted overlay connects those nodes to the cluster’s API server, and Kubernetes scheduling and access controls operate across the expanded cluster. This offers a way to use capacity near an application’s data, or capacity available elsewhere, without introducing another cluster control plane. The management boundary grows while the compute can stay where it is needed.

AKS on bare-metal Ubuntu, announced on September 30, takes a different approach. Both the Kubernetes control plane and the workloads run on customer-owned Ubuntu hardware, without a hypervisor between Kubernetes and the server. Azure supplies the management integration, while the customer retains control over the host and hardware stack. The current public preview is limited to single-node clusters, so this is an evaluation opportunity for local and edge computing rather than a ready-made replacement for a large production cluster. Its significance is the direction: Azure’s Kubernetes offering is extending to infrastructure Microsoft does not own.

September’s Azure Red Hat OpenShift hosted-control-plane preview changes the division of work within Azure itself. The control plane moves outside the customer’s worker subscription, while application workers remain in the customer’s virtual network. The documented architecture reduces the minimum customer compute footprint from three control-plane nodes and three workers to two workers, and separates control-plane upgrades from worker-pool upgrades. That could make smaller clusters and stronger separation between application teams easier to justify. The economic change comes from reducing the infrastructure and coordination needed to operate each cluster.

Azure Virtual Desktop Hybrid became generally available in September. Azure Arc connects local session hosts to the Azure desktop service, so organizations can deliver remote applications and desktops from infrastructure they already own. The service handles the cloud desktop layer while the customer operates the local machines. Provisioning, power management and autoscale remain outside this hybrid offering, and Windows Enterprise multi-session is unsupported. This is nevertheless a useful concession to enterprise reality: a business can adopt a managed access service while continuing to use its existing hosting investment.

Other Virtual Desktop changes make that service easier to operate and reach. Regional host pools, generally available in September, store host-pool metadata in the chosen region instead of a database shared across regions, reducing cross-region dependencies. Managed identities also reached general availability for supported host-pool operations, including session-host configuration, autoscale and Start VM on Connect. October adds general availability of external-identity support in Windows App on iOS, allowing invited external users to access assigned desktops and applications from that client in supported configurations.

These announcements describe several distinct deployment models, but they share a commercial logic. Microsoft can supply more of the operating environment even when moving every workload into an Azure datacenter would be impractical. I think that is a stronger enterprise proposition than treating retained infrastructure as an unfinished migration. It gives customers more choice about location while increasing the importance of Azure’s identities, policies and management services to the estate as a whole.

More operational work moves into the platform

Azure Firewall explicit proxy reached general availability on September 2. Applications and browsers can send outbound HTTP and HTTPS traffic to the firewall through ordinary proxy settings. The GA release uses one proxy endpoint port for both, and can retrieve proxy auto-configuration files from Blob Storage using a managed identity. This lets organizations replace self-managed forward proxies while retaining a familiar application configuration. It also allows selected traffic to pass through the firewall without redirecting every connection from the subnet, making modernization easier to stage.

Network security perimeter metrics became generally available on September 30. For protected resources, Azure Monitor now exposes aggregate allowed and denied access activity that teams can chart, alert on and compare as rules change. Teams can establish a traffic baseline before enforcing a perimeter and see whether a policy change produces unexpected denials. Detailed investigations still use diagnostic logs, but routine monitoring becomes more accessible. Security policy is more useful when its effect is visible to the people operating the application.

Reliability is receiving similar treatment. Microsoft’s September 9 guidance on two-zone and three-zone designs asks architects to evaluate each component’s surviving capacity and consistency requirements. A stateless application tier and a quorum-based system need different reasoning. This is architecture guidance, not a new service, and I welcome its emphasis on proving what survives a failure. Counting zones on a diagram cannot establish that the remaining application will carry the business workload.

Two scale-set features turn parts of that reasoning into platform behavior. September’s Automatic Zone Placement preview chooses zones for new instances using SKU availability, capacity and customer constraints. It reduces the need to maintain fixed zone lists for every region. Automatic Zone Balance was announced as generally available on October 15 and addresses an existing deployment’s uneven distribution. Its create-before-delete mechanism creates a replacement in an underrepresented zone and checks health before removing an instance elsewhere. Placement governs new capacity; balancing corrects drift. Because balancing recreates instances, the application must tolerate that lifecycle, and it should not be treated as a zone-outage recovery system.

The October 14 general availability of StandardV2 NAT Gateway for AKS-managed egress strengthens another dependency that can otherwise undermine a resilient cluster: outbound connectivity. StandardV2 is zone redundant, supports IPv6 and raises the throughput ceiling from 50 to 100 Gbps. New clusters using the applicable API and managed-NAT configuration receive it in supported regions. Existing clusters retain Standard until migrated. That migration replaces the gateway and changes its public addresses, so it requires coordination with systems that allowlist outbound traffic. The improvement matters because distributing application workers across zones achieves little if their shared route to essential external services remains vulnerable.

Specialist infrastructure is also moving into managed services. Azure Payment HSM v2 entered public preview on September 17, initially in West US and West Europe. It combines Marvell hardware security modules with Utimaco Atalla payment software to provide cryptographic operations such as PIN translation, card issuance and key management through Azure. For payment providers, the proposed operational change is substantial: consuming the payment-security platform as a service can remove the need to deploy and maintain its physical appliances. Azure is extending into work that previously required a particularly specialized local infrastructure team.

The engineering underneath Azure is changing too

Anyscale on Azure reached general availability on October 7. It provides managed Ray, the distributed-computing runtime, on AKS. Customer workloads, datasets and model artifacts stay in the customer’s Azure subscription, while Anyscale operates its control plane in its own Azure tenant and processes operational metadata there. The relevant Azure development is the packaging of specialist infrastructure into a supported operating service. Teams can run distributed workloads without taking on every part of the Ray cluster lifecycle themselves.

The Open Compute Project announcements on October 13 show how far below the software interface the next round of infrastructure work reaches. Microsoft’s power architecture work advances 800-volt DC distribution and the Mt. Diablo design, which moves power conversion into a separate rack so power and compute can scale independently. Solid-state transformer research aims to reduce conversion stages between the utility supply and computing equipment. These are engineering initiatives at differing stages of development, rather than new Azure services to select in the portal. Their purpose is to make increasing compute density physically and economically supportable.

On networking, Microsoft and partners have released the Multipath Reliable Connection v1.0 specification through OCP. It distributes an RDMA connection, used for high-speed communication between machines, across multiple network paths. Traffic can use available capacity and route around congestion or failed links, helping large accelerator systems continue useful work. The strategic point is that buying more compute is insufficient if its communication system leaves it waiting. Azure’s future performance depends increasingly on the behavior of the complete system.

The hardware-security announcements apply the same thinking to trust. Tessera Integrated HSM opens the specifications and supporting software for hardware-protected key management close to workloads, with a path toward fully open-source silicon. Composite Entity Attestation Token binds evidence from components such as CPUs, GPUs and storage into a single signed platform claim, simplifying verification of a whole machine. These contributions aim to make independently supplied components work together securely. Open interfaces help Microsoft build and evolve its infrastructure with a wider ecosystem; they do not, by themselves, make an Azure application portable to another provider.

Taken together, this is a credible direction for Azure. Microsoft is improving the machinery that keeps applications running while widening the range of infrastructure that its management services can reach. AI helps explain the urgency of the power and network work, but the broader enterprise benefit is operational: more placement decisions, lifecycle tasks and specialist services can be handled through the platform. Fabric, databases and Copilot deserve their own examination; this infrastructure story already has consequences for organizations whose main concern is dependable business applications.

I would judge the next phase by how much operating work these services actually remove. Retaining local compute can be the right decision if Azure makes it easier to govern and maintain. A new managed service earns its place when fewer people need to coordinate upgrades, diagnose dependencies or keep specialist appliances running. The tradeoff is a deeper relationship with Microsoft’s operating model, even where the hardware remains elsewhere. For many enterprises that will be worthwhile. The strongest case for Azure is becoming the quality of that continuing relationship, measured in reliable applications and manageable costs over their working lives.

The Squirrels Have Accomplices. One of Them Has Wheels.

The squirrels can climb, the rabbits are listening, the geese have air support, and something with wheels refuses to explain itself. I have concerns.

Dear world,

In my last letter, I explained that the squirrels were getting away with something. I appreciate that this was a considerable concern to place before people who may simply have wanted to look at a golden retriever.

You may still look at the golden retriever. I will remain available throughout.

But while you are looking at me, other creatures are moving about outside. Some climb. Some fly. One has wheels, which raises questions I do not believe anyone has properly considered. To understand the Great Squirrel Conspiracy, you need to know who is involved.

Business Events Go GA in Microsoft Fabric

Business Events are generally available in Microsoft Fabric. Explore the technology, the changes to data-product design, and the operational work these signals can support.

A data platform can tell a distribution team that a customer’s order is likely to arrive late. Getting that finding to the person who can change the outcome is often a separate project. Someone has to recognize the condition, build an integration, decide who should respond, and preserve enough context to explain what happened afterward.

Microsoft’s September 2026 release lists Business Events as generally available. This gives Fabric teams a common way to publish meaningful business occurrences and connect them to downstream responses. For organizations already using Fabric to combine data and calculate business conditions, that is a substantial extension of what the platform can contribute.

I see the architectural opportunity in treating the findings produced by analytics as something other teams can subscribe to and use. Understanding that opportunity starts with what a business event represents, then follows through to the systems we build and the people whose work those systems support.

Lovable and Microsoft Change the Business Case for Internal Apps

Lovable and Microsoft could make more small internal applications worth building. The business case depends on reusable operating services, process improvement, and the full cost of ownership.

There is a familiar category of business problem that never becomes a software project. A sales team needs a better way to handle pricing exceptions. Operations needs a tool for work that falls between two systems. A department has outgrown a spreadsheet, but its requirements are too specific for the standard application and too small to compete for engineering capacity.

The organization keeps paying for the problem through delay, repeated work, and missed opportunities. Building the tool might make sense in isolation. Owning it, connecting it, securing it, and supporting it can make the total proposition difficult to justify.

Lovable’s September 28 announcement with Microsoft addresses that gap. Applications built in Lovable can be packaged for Microsoft Copilot Managed Runtime, with Microsoft hosting, organizational sign-in, and tenant governance. The partnership also brings together Microsoft data connections and distribution through Microsoft’s ecosystem.

My reading is that this changes the investment threshold for internal software. More business improvements could become economically achievable when an organization can reuse the foundations required to operate an application. Understanding that opportunity requires looking beyond the speed of generating its first screen.