I feel quite passionate about this topic, partly because the absolute “Best Operational Model to Govern the Power Platform” does not exist. It is likely to exist for each organization, but not likely to be exactly the same for all organizations. Nor to be the same at all time for a same organization.

• The Operational Model – Key Ingredient for Governance
• Various Operational Models to Govern the Power Platform
• A Hybrid Model between Centralization and Decentralization

The Operational Model – Key Ingredient for Governance

Let’s not forget about the human side

Most Power Platform Governance discussions I engaged in with other organizations were about technical topics. Which connectors are enabled or blocked? What are the technical tenant restrictions in place to secure the platform? How to manage ownership and orphaned flows and apps? What customizations are relevant on top of the CoE Starter Kit? And so the list goes. All these topics are very interesting and essential for a robust governance, but there is a key question equally as important: who are the persons defining and applying the governance strategy?

This is exactly the question that the Operational Model in place to govern the Power Platform answers to.

Common objectives and challenges

Organizations can have different objectives for the Power Platform. Along with the company size, the primary target for Makers might change from one company to another. It can go from pro developers to IT teams to citizen developers to absolutely everyone. The tolerance to risks will also vary from one company to another. So does the target for end users, who can be internal, external or both. Regardless of these differences, organizations wanting to leverage the Power Platform would typically be looking to achieve these two objectives:

• Drive adoption and empower their target audience for Makers to leverage the platform to the maximum benefits for them, the targeted end users, and the organization
• Doing so without increasing risks, compromising on data protection nor on any other security principles

And below are some common challenges that organizations trying to achieve the above objectives can face:

• Makers’ productivity is stifled. Everything is blocked and the process to get anything enabled takes too long.
• Lack of trust from Executives. CIOs, and leaders of the organizations do not believe in the platform. They heard that it leads to shadow IT and see it as a dangerous platform.
• The Central IT team managing the platform is overloaded. The team owning the platform internally does not have enough capacity to establish an appropriate governance strategy for the platform.
• Things are out of control. Everyone is able to do what they want, no control is in place, leading to severe operational issues and risks everywhere.

A good operational model for an organization is a model that will help them achieve these two objectives while overcoming the possible challenges listed above.

Various Operational Models to Govern the Power Platform

Microsoft already does a great job at giving an overview of the main models possible. In the next section I will dive into one in particular, but let’s first discuss two opposite models.

The centralized model

Organizations adopting such a model would typically have one single Center of Excellence (CoE) responsible for governing the platform. The CoE Member(s) would have the tenant Power Platform Admin role (or, god forbids, the global admin role). The CoE would restrict all the operations to themselves only, such as the Environment creation, setting up of tenant DLP Policies, etc…

In order to empower their target Maker audience to still leverage the platform, the CoE would define processes to request environments, connectors, etc. Such processes would always involve the central CoE team. The most mature CoEs would have a lot of these processes automated to optimize efforts. System Administrator roles would only be assigned to the CoE members and would not be given to Makers on their environments to avoid risks.

We could represent such a model this way:

(Maker image Designed by pch.vector / Freepik)

Pros

• Control: this model can allow the CoE to have full control over what is happening with the platform. They can also control the narrative and ensure that all Makers get the same message regarding governance and processes, provided that they have the capacity to communicate with them.
• Great way to start: this model is simple. Everything goes through the central team. As suggested in these recommendations, keeping things simple can be very helpful, especially at first.

Cons

• Difficult to scale: From my experience, the adoption of the platform tends to increase faster than the resources of the CoE… With this model, multiplying the Makers will result in multiplying the connections with the central CoE. The team might become overloaded by requests and queries from Makers.
• Difficult to unlock all the platform potential: This problem comes along with the scale challenge. With limited resources, the CoE will likely have to renounce many functionalities of the platform to maintain this centralized approach. For instance, it will be hard to allow Makers to leverage Dataverse if they do not have the system administrator role on their environment to create and assign security roles. Alternatively, creating such roles for the Makers is hard if thousands of Makers ask for their roles to be created.
• Proximity with Makers: For large organizations, such a centralized model might make it difficult to stay close to the Makers. Language & time zone differences will add up to the resource challenge as the adoption increases. Makers might not get the support they need from the central CoE team. This could result in the CoE having difficulties to identify the successful solutions which could be re-used across the business. With the lack of proximity with Makers also comes the lack of proximity with the local context and regulations…

The decentralized approach

This model is opposes the centralized one. While organizations will likely still set some tenant restrictions, this model consists in giving much more freedom to Makers or teams of Makers. They could for instance have access to create and manage their own environments and work autonomously for the most part.

Pros

• Less technical obstacles to productivity: Makers in organizations adopting such a model typically enjoy fewer restrictions and can implement what they need faster.

Cons

• Hard to nurture one community and encourage re-use: In a decentralized approach it will be harder to share best practices between all Makers and identify and re-use the successful solutions across the organization.
• Increased risks: If there are less restrictions and no centralized body to govern the usage of the platform, the risks will most likely increase. The general trust in the platform will decrease along with the risk increase.
• Hard to evolve the model: should an organization decide to move away from a decentralized approach, it might be very difficult. Establishing new centralized processes will require to re-assess all the existing solutions to make them compliant. This will come with potential transition and migration efforts. From a human point of view, it is always difficult to explain to someone that they will no longer be able to do some things on their own and that they will now require approvals.

A Hybrid Model between Centralization and Decentralization

One model I came to particularly like is a hybrid approach which combines centralization and decentralization to govern the Power Platform. In my opinion, such a model, when implemented properly, can allow to overcome many of the challenges listed above as the adoption increases. It involves a Global CoE responsible for setting up the global governance guardrails and some local CoEs responsible for reduced scopes.

• The Global CoE defines the governance strategy for the platform at global level. They also maintain a central knowledge base and organize events to invite Makers to share best practices and success. They manage the default environment and their own ones but are not responsible for the Makers’ environments which are under the responsibility of local CoEs.
• The Local CoEs are responsible for reduced scopes. A scope could be a region or a function for example. They manage their own environments and are responsible for their respective Makers’ activity. They define the Environment strategy for their scope and are the ones supporting their Makers.

(Maker image Designed by pch.vector / Freepik)

The role of the Global CoE to govern the Power Platform

There are many ways in which this model could be implemented, though the Global CoE would typically have the Power Platform Administrator role and would be responsible for:

• Defining the global governance strategy and implementing processes to govern the platform (tenant restrictions, connectors strategy, environment request process, etc.). Such processes should involve the Local CoEs when it relates to their respective scope while maintaining a global oversight and control. For example, environment requests coming from Makers should be routed through the related Local CoE first to ensure it fits within their local environment strategy, prior to being created by the Global CoE.
• Supporting the Local CoEs, for example by:
  • Organizing Community of Practice of Admins. This allows to ensure Local CoEs are up to date with best practices to manage their environments.
  • Implementing and sharing admin tools to facilitate environment administration operations for the Local CoEs.
  • Gathering usage telemetry and creating dashboards for Local CoEs. The global CoE can maintain the CoE Kit at global level and leverage Power BI Row Level Security to share the data with the Local CoEs with only what is relevant to them. This way each local CoE can have access to the solutions created by their respective users on the default environment.
• Organizing nurturing activities for Makers such as Community of Practice events and maintaining a knowledge base.

The role of the Local CoE

The Local CoEs are responsible for:

• Defining their local environment strategy. Each team would be responsible for a different scope, and the same strategy might not be relevant for all. Therefore it makes sense to give flexibility to each local CoE. Some Local CoEs might only use their environments to deliver solutions to the business themselves, some others might want to have some environments available to citizen developers as well.
• Supporting their Makers: such teams are close to the Makers and their context, they are able to support and advice them on the right approach and technology.
• Managing their Environments: the local CoEs have the System Administrator role on their environments. They are responsible for managing the access to their environments and the onboarding process for their Makers. They can decide the level of permissions that they want to grant to Makers on their environments. They are also responsible for defining the environment settings, in agreement with the Global CoE.
• Compliance: they are responsible to ensuring compliance with global and local regulations and standards. Some of it is managed at platform level by the Global CoE and the controls they implemented for the platform, while some other topics are under the responsibility of Local CoEs. For instance with the dashboards provided by the Global CoE they can be responsible for ensuring their Makers do not use the default environment for non-appropriate use cases.

Some advice for success

Here are some suggestions to implement this model with success:

• The Global CoE is a good start. At first, having a centralized model is probably enough. It is only as the adoption increases that the model is likely to need to evolve.
• A clear agreement is key. The success of this model will depend on how clear the responsibilities are defined between Global and Local CoEs. Laying these black and white on paper and having both parties signing an agreement for each Local CoE can help to ensure alignment.
• The scope definition matters. If the scope for a local CoE is too big, the team will face the same issues as for a the centralized model when the adoption increases. The scope might need to be re-visited as the time goes, and additional levels might need to be defined. On the other hand if the scopes are too small, the Global CoE will have too many teams to work with and will also have similar difficulties as with a centralized model and high adoption.

Challenges with this model

No model is perfect, and below are a few of the challenges that organizations might face by setting this up:

• Some efforts to define the model. Defining the details of the model (scopes, agreements, etc.) will take some time. This is a one-off investment which only requires some reviews and adjustments afterwards.
• Difficult to generate interest at first: It might be hard to pitch this model to prospective local CoEs at the beginning. This will get easier as more teams will be in place since it will be possible to demonstrate the value of this model. Setting up some restrictions (connectors, environment creation, etc.) and requiring to have a Local CoE as a pre-requisite to benefit from additional functionalities can also help.

Benefits of this hybrid approach

Beyond a certain threshold of company size and Power Platform adoption, this model presents multiple benefits:

• The Global CoE keeps a centralized control over the platform usage, while being able to delegate some of the operational tasks to Local CoEs to govern the Power Platform
• The contribution of the local CoEs can free some capacity of the Global CoE. They can then invest more time in exploring new features and products of the platform to unlock even more capability in a secure way.
• Activities benefiting all the community remain centralized for an economy of scale while some flexibility is offered to local CoEs
• Local CoEs have a good proximity to Makers and are familiar with local context. Therefore Makers can get some additional and more tailored support while Local CoEs are better equipped to ensure local compliance with regularions
• Local CoEs can act as ambassadors for the Global CoE and contribute to spreading knowledge around the governance in place. This can result to an increased popularity of the platform