Power Platform environments strategy (2)
With the growing popularity and usage of the Power Platform in many organizations, we have seen that many of them are struggling to build an effective strategy that helps them manage their environments. In this three-piece blogpost we will help you with managing your environments and with writing a clear environment strategy. If you need any assistance in building a customized governance for your company, you can always contact us.
In part 1, we discussed how environments are built in the platform. In this second blog post, we will take you through the steps in building an environment strategy.
Developing an environment strategy is important to keep your Power Platform organized and structured in the long term. With developing a strategy, you can achieve a place where business critical apps and personal apps can be used and maintained in the long term.
When developing a strategy, it is important to step away from the default environment and create a structure which fits your company. Most of the time, multiple environments will be needed for this.
Benefits of using environments
An environment can be tied to a geographic location which is important in a business with multiple physical locations worldwide. There is an isolation boundary for all resources because you can never have resources that reference resources across environments.
For each environment, a different target audience can be configured based on the purpose. As discussed in our previous blogpost, you can plan the roll-out of platform updates. Data loss prevention can be configured for each environment as well as backup/restore. Over time, it might be relevant to have different analytics based on each environment.
Why is developing a strategy important?
You want to secure the data of different applications and avoid that the wrong people have the wrong permissions.
The default environment is always created and cannot be removed. Therefore, it is important to find a place in your strategy. Next to this, you want to avoid a sprawl and conserve capacity. Always ensure that your data is being stored and transmitted in acceptable geographic regions ensure. Also, organize recourses in logical partitions.
On top of that, with a strategy, you can manage the application lifecycle management: what will happen with the application in the future, the maintenance, retention …
Steps to develop your strategy
When developing your environments strategy, we advise you to follow these six steps to get you on your way:
- Assign your admins Power Platform service admin role
- Restrict the creation of trial and production environments
- Treat the default environment as a ‘Personal productivity’
- Enable a process for requesting access to environments
- Create Dev/Test/Production environments for critical applications
- Have ‘individual use’ environments for Proof Of Concepts
You can go out lots of directions when developing an effective environment strategy, but we want to give you some extra advice regarding this. First, always deploy production solutions with a service account to avoid the applications becoming “orphans”. Besides, it is a good idea to share your applications with AD security groups.
If possible, try to reduce the number of shared development environments. But if needed, we sometimes suggest developing an automated provisioning for environments. This is especially used when you want to create a specific training or demo environment for trainings or demos which will be removed after these have taken place.
Lastly, keep in mind while developing a strategy: less is more. You want to avoid users getting lost in the search for the right environment.
Define types of application solutions
When developing a strategy, it is important to know that there are three types of solutions: critical, important and productivity. We mostly define one of the three types and use this structure as the basis of our environment strategy.
Example of a strategy
This image is an example of a strategy, which is an example of a best practice of Microsoft.
Here, you can divide the environment in five high level structures:
- Critical project
- Business unit
- Important project
The default environment (a) is open for everyone and can be used for personal or small team productivity applications which are not business critical applications. The environment can also be renamed and is mostly used by the citizen users.
On the other hand, the developer environment (b) is only available for users that are subscribed to the community plan and the only purpose is to develop applications. Applications can be migrated to other environments if needed.
Critical applications (c) are placed in separate environment, with both a test and development environment. Those applications are mostly supported by the IT department in organizations and are following a deployment flow over the different environments.
For business developments (d), we suggest creating a separate container. Here, users who have been very active in the default environment and have proven that they have the knowledge, can develop the applications. If the applications are developed, IT admins can migrate them to a shared test and production environment in which the user does not have the creator role.
The last group is a separate environment for the development of important projects (e). Here as well, applications can be migrated by IT admins to a shared test and production environment. We suggest creating a shared production and test environment for business and important projects to avoid an overkill of environments.
This concludes this second blogpost. In the third and last one, we will dive into the monitoring of environments with hands-on examples and a checklist for your organization.