Skip to content
Artwork for Support Engineering Weekly
Support Engineering Weekly · September 20 · 21 min

The Power Platform Isn't Three Products: It's an Architecture

Why does the Microsoft Power Platform become difficult to support when Power Apps, Dataverse, and Power Automate are treated as isolated products? In this episode, Alex and Maya examine the Power Platform as an architecture, with clear responsibility boundaries between the user experience, governed business data, orchestration, integration, compute, analytics, and the control plane. The discussion explores deliberate handoffs between Power Apps, Dataverse, and Power Automate, the event-driven pattern that connects them, why Dataverse should be treated as shared business context rather than simple storage, and why specialized compute and analytics belong in the appropriate services instead of inside apps or flows. The episode then examines enterprise control through environments, application lifecycle management, data loss prevention, and workload-level security. The conversation also looks at the 2026 direction of the platform, including Copilot, autonomous AI agents, and agentic low-code development, and explains why AI does not replace architecture. Instead, AI makes clear identity structures, governed data, security boundaries, integration controls, and proper ALM even more important. The central lesson is straightforward: start with the workload, define clear responsibility boundaries, use deliberate handoffs, and treat the Power Platform as an integrated architecture rather than three separate products. This episode is based on the Support Engineering Blog article “The Power Platform Isn't Three Products: It's an Architecture”, including its architectural model, responsibility boundaries, deliberate handoff pattern, Dataverse business context, integration and compute guidance, control-plane principles, security model, and supporting diagrams. Chapters 00:00 - Three Products or One Architecture? 02:07 - Responsibility Boundaries 04:51 - Deliberate Handoffs and Events 07:57 - Dataverse as Business Context 10:28 - Integration, Compute, and Analytics 13:16 - The Control Plane and ALM 15:53 - Security Across the Workload 17:00 - AI Doesn't Replace Architecture 19:19 - The Workload-First Architecture Model Learn more: The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch.

0:00 · Three Products or One Architecture?-21:20

transcript

No transcript — this publisher did not publish one.

show notes

Why does the Microsoft Power Platform become difficult to support when Power Apps, Dataverse, and Power Automate are treated as isolated products? In this episode, Alex and Maya examine the Power Platform as an architecture, with clear responsibility boundaries between the user experience, governed business data, orchestration, integration, compute, analytics, and the control plane.

The discussion explores deliberate handoffs between Power Apps, Dataverse, and Power Automate, the event-driven pattern that connects them, why Dataverse should be treated as shared business context rather than simple storage, and why specialized compute and analytics belong in the appropriate services instead of inside apps or flows.

The episode then examines enterprise control through environments, application lifecycle management, data loss prevention, and workload-level security. The conversation also looks at the 2026 direction of the platform, including Copilot, autonomous AI agents, and agentic low-code development, and explains why AI does not replace architecture. Instead, AI makes clear identity structures, governed data, security boundaries, integration controls, and proper ALM even more important.

The central lesson is straightforward: start with the workload, define clear responsibility boundaries, use deliberate handoffs, and treat the Power Platform as an integrated architecture rather than three separate products.

This episode is based on the Support Engineering Blog article “The Power Platform Isn't Three Products: It's an Architecture”, including its architectural model, responsibility boundaries, deliberate handoff pattern, Dataverse business context, integration and compute guidance, control-plane principles, security model, and supporting diagrams.

Chapters

00:00 - Three Products or One Architecture?

02:07 - Responsibility Boundaries

04:51 - Deliberate Handoffs and Events

07:57 - Dataverse as Business Context

10:28 - Integration, Compute, and Analytics

13:16 - The Control Plane and ALM

15:53 - Security Across the Workload

17:00 - AI Doesn't Replace Architecture

19:19 - The Workload-First Architecture Model

Learn more:

The full technical article, references and supporting resources are available through the Support Engineering Blog at https://blog.sadhan.ch.

chapters

9 chapters