Power Platform is not one product, it is a suite, and the most consequential thing an architect does on a project is decide which piece of that suite each requirement belongs to. Canvas apps, model-driven apps, Power Pages, Power Automate, plugins, business rules, Dataverse, virtual tables, Power BI, the platform gives you many ways to meet a requirement, and only some of them are the right way for any given one. The projects that go smoothly are the ones where each requirement landed on the component built for it. The projects that fight the platform are the ones where a team picked a favourite component and forced everything through it.
This is why fit-gap analysis and component selection are the heart of the architect role. Before designing anything, you take each requirement and answer two questions in order: can a standard component meet this as configured, and if so, which component is the right one. Skip that and you get the two classic failures, building something custom that a standard component already does, or building it in the wrong standard component and spending the rest of the project working around the mismatch.
Fit-gap first: configuration before code
The first pass over the requirements is fit-gap, and it is the same discipline that keeps any platform implementation maintainable. For each requirement, the question is whether the platform meets it through standard configuration (a fit), whether adapting the process slightly avoids a gap, or whether it genuinely requires custom development (a real gap). The goal is to resolve as much as possible as configuration, because configuration carries forward cleanly and custom code does not.
The reason this matters on Power Platform specifically is that the platform is broad enough that a surprising share of requirements are fits once you stop assuming custom code is needed. A requirement that sounds like it needs a plugin is often a business rule; one that sounds like a custom UI is often a model-driven form; one that sounds like a bespoke integration is often a standard connector. Running every requirement through the fit-gap question before reaching for code is how you keep the custom-development footprint small, which is what keeps the solution upgradable and cheap to own. Custom code, the PCF control, the plugin, the Azure Function, is the last resort, justified only when no standard component and no reasonable process change can meet a genuine requirement, because it is the part you maintain against every platform change forever.
Matching the requirement to the component
Once a requirement is a fit, the second question is which component, and this is where knowing the suite earns its keep. The components sort into layers, and the requirement usually tells you the layer if you listen to it.
For the app layer, the question is who uses it and how. A data-centric back-office experience over Dataverse, with forms, views, and business process flows, points to a model-driven app. A task-specific, pixel-controlled, often mobile experience points to a Canvas app. An experience for external users, customers or partners outside the organisation, points to Power Pages. These are not interchangeable; we covered the model-driven versus Canvas decision in depth, and the architect's job is to pick the one that fits the audience and the data, not the one the team is most comfortable in.
For the automation layer, the question is what triggers the logic and how complex it is. Simple field logic on a form is a business rule; a workflow across systems or with connectors is Power Automate; transactional, synchronous, or high-complexity logic close to the data is a plugin. Reaching for a plugin when a business rule would do, or a flow when a plugin is required, is the same wrong-component mistake in the automation layer, and we wrote about choosing between business rules, Power Automate, and plugins because it comes up on every project.
For the data layer, Dataverse is the default system of record, with virtual tables when the data must stay in an external source, and dataflows when it must be imported and transformed. For analytics, Power BI is the answer when the requirement is reporting and insight rather than transactional interaction. Each layer has a right tool per requirement, and the architecture is the sum of those correct matches.
The default-tool trap
The failure mode to guard against has a recognisable shape: a team that defaults every requirement to the component it knows best. The Canvas-first team builds data-heavy back-office apps as sprawling Canvas apps that should have been model-driven, and fights delegation and maintainability the whole way. The developer-first team writes plugins for logic that business rules handle, and owns custom code it never needed. The wrong component does not fail outright; it works, badly, and makes everything harder than it should be, which is why the cost is easy to miss until the project is deep in it.
Avoiding the trap is a discipline, not a talent: for each requirement, ask which component is genuinely right, not which one is familiar, and be willing to use the part of the suite the team knows least if that is the correct fit. An architect's value is partly in being the person who insists on the right component when the team's instinct is to reach for the comfortable one.
How the architecture comes together
A Power Platform architecture is, in the end, a set of correct component matches under a fit-gap discipline. You run each requirement through fit-gap to keep configuration ahead of custom code, then place each fit on the component built for it, the right app type for the audience, the right automation tool for the trigger and complexity, Dataverse for the data, Power BI for the insight, and custom code only where a genuine gap leaves no alternative. Do that and most of the build is configuration on the right components, which is the cheapest and most durable kind of build.
The skill is resisting two temptations at once: the temptation to build custom when a standard component fits, and the temptation to use the familiar component when a different one is right. Match the requirement to the platform piece built for it, requirement by requirement, and the solution stops fighting the platform and starts running with it.
