Reference Architecture for the “Landing Zone”, your indispensable foundation for scaling Power Platform
This is the next in a series of essays in which I’m more deeply exploring my favorite topics from the Power Platform Adoption Framework. A special thanks goes to my friends and colleagues, Reece Campbell and Brent Ellingwood, who have been fantastic collaborators on many of the topics that I cover below.
I’ve had a lot to say over the years about the three “tracks” of Power Platform Adoption: Enterprise Management, Solution Development, and Business Value. But I think my writing has often not given as much treatment to the “Landing Zone”—the building of which precedes an organization’s ability to manage, develop, and derive business value from the platform—largely because it feels such a foundational concept from my experience in the world of Microsoft Azure. Over the last year, though, I’ve increasingly been met with blank stares when I’ve talked “Landing Zone”. Put another way, what feels such a foundational cloud concept from an Azure perspective—and is equally foundational in Power Platform—is too often forgotten in the Apps! Apps! Apps! world of Power Platform.
Before we go any further, though, I want to conceptually frame what a Landing Zone is and why it’s so foundational to Power Platform in an organization. You see, the angst around the platform that I hear in most IT organizations can be boiled down to five objections:
This is chaos! Solutions are not managed or monitored, and people are spending time developing apps of questionable business value.
This doesn’t fit with our tech ecosystem! We have identity, licensing, security boundary, and pre-existing apps and data to worry about.
This is unsustainable! What about our pro developers, quality standards, source control, deployment automation, and CI/CD?
This is not secure! Our apps need to be approved for use on a secure platform where users are managed, and data is protected.
This is too costly to support! How are we going to support business stakeholders and citizen developers building on their own?
These concerns align—not coincidentally—to the five pillars of Enterprise Management for Power Platform as set forth in the Power Platform Adoption Framework: Platform Management, Enterprise Architecture, Application Lifecycle Management, Mature Security Model, and User Empowerment (and their 22 component dimensions, shown in the table here). They are effectively the wall between where the organization stands today and the technology’s value in meeting new business needs, sunsetting legacy technologies, reimagining existing applications, and supporting worker productivity.
The Power Platform Landing Zone is the beginning of the path to overcoming these barriers. A foundation, if you will, the Landing Zone is the initial technical infrastructure plus governance of that infrastructure that allows an organization to begin “landing” workloads (combinations of data, apps, automation components, etc.) in Power Platform. Skipping the Landing Zone so that you can go straight to app building is like buying furniture without a house or an apartment in which to put it. Your apps are the furniture, whilst your Landing Zone is the structure in which they (and you) reside.
For several years the pretty widely accepted approach to dealing with these concerns was to work from a rough semblance of a list that most Power Platform governance practitioners had jingling around in their pockets: Deploy the CoE Starter Kit to some random environment you found, build some more environments, apply some data loss prevention (DLP) policies, jump through hoops to make sure security is happy, do some more random things, and eventually—maybe—you’ll have a minimally viable semblance of Power Platform within the organization such that “people” (usually IT security and folks who come from an Azure background) won’t freak out.
But there’s a severability problem to this approach. Say you are trying to solve an ALM challenge, that is to say Source Control and Deployment Pipeline. These functions are automated for Power Platform by Azure DevOps or GitHub, so you can’t solve ALM without getting proper Project Tooling into place. Further, ALM depends on environments, so if you have an ALM challenge you almost certainly have an Environments architecture challenge. Environments are monitored by the CoE Starter Kit. The data contained in environments is secured in part via Data Loss Prevention (DLP) policies. And, well, you get the idea: Here we’ve started with a narrow ALM challenge and in the matter of a paragraph touched six of the 22 dimensions (italicized just now).
The moral of the story above is that it is very difficult and usually completely inadvisable to sever your attention on a single dimension from the greater whole of enterprise management, hence, the value of a comprehensive Landing Zone approach. So with that in mind, a while back I set out to create a reference architecture for a Power Platform Landing Zone. In other words, if an organization were to build their Power Platform infrastructure properly, it would look a lot like this reference architecture.
The architecture should of course be adjusted to account for every organization’s “somewhat” unique needs, though I quote “somewhat” because there’s only a finite amount of creativity (or need thereof) in the world of technical infrastructure. For example, this architecture is particularly well suited for highly regulated organizations with ethical walls or those working across multiple geographies where local regulations around—say—data governance and sovereignty apply. The less regulated the organization, in theory, the less need the organization may have something quite this sophisticated. That said, I counsel that it’s wise to think of all this as best practice; any organization really pursuing a platform-first approach should be doing business this way.
Tenants in Common
Beginning with the basics, most of what you see in this architecture lives within the boundary of an organization’s Microsoft tenant. This is illustrated by the blue box I’ve drawn around the technical services therein. I’ve had long debates with folks about whether a separate “sandbox tenant” or “developer tenant” is necessary, and in general I find that approach to be silly and obsolete. There was a time when a tenant could house only a few environments, but those days are long gone. The very existence of Power Platform environments—and all the security tools around those environments—has largely made the need for sandbox tenants obsolete. Better to create sandbox environments inside of your primary Microsoft tenant, then to link them to TEST, STAGE, PROD, etc. via proper DevOps-based ALM than to cordon your development into wayward development tenants.
There are, of course, some circumstances where an organization has multiple production tenants with which to contend. Common scenarios include mergers and acquisitions where the IT systems have not been fully brought together, situations common to financial services featuring hard walls to information sharing, or businesses operating in countries with regulations different as say China and the European Union. Microsoft’s pattern for these scenarios is to use Azure Active Directory B2B to facilitate sharing between users in different tenants, and they’ve been working to create increasingly sophisticated capabilities to support this established pattern.
External users are also relevant in our architecture insofar as the organization plans to use Power Pages to build externally facing web portals for use by customers, suppliers, and partners outside of the organization. Use of these portals has sky rocketed over the last several years—particularly in the Public Sector as agencies have worked hard to improve their virtual citizen services through the pandemic—and earlier in 2022 were broken out from Power Apps to form Microsoft’s fifth “Power” service in Power Pages. A variety methods exist for external user access to these portals, but in the case of our architecture here we’re going to assume that they’ll use some combination of Azure B2B or B2C as the individual uses case dictate. Best to get that infrastructure in place in advance, so as to not impede development of these externally facing apps down the line.
Internal users, that is employees (etc.) with a named account inside of the organization, authenticate via Azure Active Directory (AAD). This should be fairly straight forward if the organization has established itself in AAD, including if there’s a synchronization scenario in place with on-prem Active Directory. Fine, but that scenario provides a good example of how our architecture would be necessarily modified in order to reflect the organization’s unique particulars. It is important here to understand how security groups are used in the tenant at the point you’re building this architecture. We will likely want to leverage this.
I should also add that for public sector organizations whose tenant exists inside one of Microsoft’s unique public sector “regions”, the Power Platform services must always follow the authentication. In other words, the architecture above must be built inside of the same tenant where the Azure Active Directory is hosted.
Power Platform Environments
Onwards…
This architecture is very much built with the Environmental Architecture Model (EAM) in mind, so I recommend getting smart on this via the Power Platform Adoption Framework if you’re unfamiliar. The diagram I’ve shared is best understood as organizing Power Platform environments (the labeled rectangles) in three criticality tiers called (in decreasing order of criticality) Critical, Important, and Productivity. There are are two classes of environments relative to AAD:
Environments that are tied to a specific AAD security group, thus ensuring that only members of the paired security group have access. These include the [BG ∞] – IMP – PROD environments in the “Important” tier and [BG ∞] – Personal Productivity environments where in both cases there are a theoretically unlimited number of business groups that might require their own environments. This approach is useful from a user management perspective generally, and particularly important in the aforementioned scenarios where segregation of different business functions or groups is required.
Environments that are broadly available to all users in the organization, i.e. environments that may host apps that need to be accessed by employees across business groups will not be tied to an AAD security group. I should note here that the apps deployed to these environments themselves will use role based access controls (RBAC) to secure the apps themselves and the data they contain, but here we are talking about the ability to access the environment itself provided that one possesses the appropriate security roles, which are determined on an app by app level during development of each app (vs. from a platform architecture perspective, which is what we’re discussing now).
Finally, a few notes before going further…
It is absolutely imperative to establish a naming convention for all the environments in your tenant. I generally prefer: [Owning Business Group] - [CRITICALITY] - [Purpose, if applicable] - [TYPE] where:
Owning Business Group = the business group using the environment and / or responsible for its management;
Criticality = Critical (CRIT), Important (IMP), or Productivity;
Purpose = specific purpose or solution for which the environment was established, if applicable
Type = DEV, TEST, PROD, etc.
This architecture provides a baseline, so it is entirely possible that an organization’s broad requirements or the specific requirements of any given app will drive the creation of new environments, the customization of specific DLPs, etc. The goal here is to create a baseline infrastructure into which those additional or future services may be deployed.
The “clusters” (grouping of three stacked environments) in the diagram indicates that proper ALM best practices must be applied, i.e. development only in environments so designated, followed by component integration (if applicable) in a separate environment, testing and / or staging, and production all facilitated by DevOps automation, proper source control, etc.
Critical Environment Services
The critical tier will at minimum be home to two clusters:
IT - CRIT, a Dataverse-enabled environment for critical-grade solutions managed by the central IT organization
IT - CRIT - CoE, a Dataverse-enabled environment to which the Microsoft CoE Starter Kit should be deployed (and customized as needed)
Organizations using any of the Dynamics CE applications (which are themselves built on Power Platform) are likely to either deploy these to IT - CRIT - PROD above, or to establish a separate cluster for IT - CRIT - Dynamics if it is desirable to isolate the Dynamics apps from other critical apps. It’s therefor important to identify which if any Dynamics 365 solutions are in use today, or planned within 12-18 months, so that the platform architecture can account for this.
We’ll then apply or deploy a variety of services into this tier:
Design a DLP to be applied to critical environments. This policy will generally be less restrictive than what might be applied to important or productivity environments because we assume that the solutions deployed here will be subject to more stringent security auditing, and therefor better equipped to connect to a wider variety of external data services.
Enable Azure DevOps (ADO) to facilitate ALM.
Deploy the organization’s “base solution”, that is a solution of components and tables in the data model that the organization wishes to standardize and make available across all environments.
Consider the use of an environment cluster here to facilitate Master Data Management (MDM) in the organization, or likely, Power Platform’s integration to the organization’s broader MDM scheme.
These environments are more likely than others to be connected to Azure Data Lake to facilitate a variety of data warehousing and data analytics requirements.
Important Environment Services
The important tier will e home to—likely—many clusters:
IT - IMP, a Dataverse-enabled environment where central IT will maintain important-tier apps for which it has agreed to be responsible
[BG ∞] - IMP, Dataverse-enabled environments specific to business groups as defined by the organization. There’s really no limit to how many of these would be appropriate, as it is really an organization-by-organization decision, hence use of the ∞. These environments are ideally tied to the appropriate BG security group in AAD in order to limit access.
It’s therefor important to understand and define how business groups (e.g., geographic, functional, combination) work within the organization, and note that we’re talking about the organizational structure, not about “business groups” as they are understand as a construct within Dataverse.
We’ll then apply or deploy a variety of services into this tier:
Design a DLP to be applied to important environments. This will generally be more restrictive than critical and less restrictive than productivity as we assume solutions deployed here will be subject to moderate security auditing. Different organizations will have different risk tolerances.
Enable Azure DevOps (ADO) to facilitate ALM.
Deploy the organization’s “base solution”.
Consider integrating these environments to the organization’s Power Platform MDM approach, similar to the critical tier.
There are plenty of scenarios where Azure Data Lake connections are useful here, but it’s not quite as clear as in the critical tier.
Productivity Environment Services
The productivity tier will e home to—likely—many clusters, many of which may not include Dataverse unless the organization is deeply invested in this as a data service technology.
Personal Productivity, which is the renamed “Default” environment inherent to Power Platform within every Microsoft tenant
[BG ∞] - Personal Productivity where users are able to build their own localized productivity components specific to their business group (again, highly useful in scenarios involving prohibitions on data sharing amongst business groups)
We’ll generally apply our most restrictive DLPs to these environments because the apps they contain are the least likely to be subject to a stringent (or any) security audit, so we’ll want to be particularly conservative about the data sources that we allow our users to access.
Other services are certainly not outside the realm of possibility here, but in general the apps deployed here will be developed by less technically sophisticated users, so many of the services we’ve previously discussed (e.g. ADO / ALM, MDM, Data Lake) may be outside of their skillset. The concept of a base solution is made possible Dataverse in the environment, so environments without Dataverse will not be able to receive that solution.
Teams in the Power Platform Reference Architecture
This is not the context for a lengthy discussion of Dataverse for Teams (DV4T) and how that capability forces Teams into the Power Platform architecture discussion…
Suffice it to say, though, that DV4T allows for a team to be 1:1 paired to a “light” Dataverse environment so that some apps can be built and used inside of Teams. Teams carry on being administered inside of the Teams admin experience, whilst the DV4T environments they spawn light up inside of Power Platform administrative tools. It is as a consequence important to consider how we’ll treat these relatively decentralized Power Platform environments within our broader architecture (or whether we will turn off the capability completely), and if DV4T is already in use or even rampantly so.
Conclusions
There’s a lot to unpack here, and even more runway (get it?) on which to bend the Landing Zone construct to fit the organization’s unique needs.
For example, we touched briefly on the organization’s broader data ecosystem and master data management specifically, but this is an absolutely crucial consideration in taking Power Platform to class one enterprise scale. I could write significantly more here about that integration both for inbound and outbound data connections, whether a staging or intermediary is necessary between most of the Power Platform services and the MDM solution, etc.
That said, the Landing Zone is the indispensable foundation to scaling Power Platform. If you’re working with anyone who disagrees or has omitted this architectural work from your Power Platform journey, then you are working with the wrong people. In recent times we’ve moved well past the old days of doing this haphazardly. This reference architecture I have shared will show you the way.
