In this next post within my series on solution architecture for the Power Platform we’ll move onto another consideration, focusing on environments and location. We’ll have a deep dive into what I mean by environments and location and we’ll look at some of the various things we need to consider that sit within this topic! Stay tuned for more solution architecture posts coming up soon in this series friends!
Environments and location
So what do I mean by environments and location? Here, I’m basically talking about the element of designing a solution and putting solution governance in place to meet a range of requirements which looks at where things are sat such as the things we’re building, the data we have and the services we interact with.
Tenant
So one of the first things we can configure, and that normally isn’t really an issue for us is the tenant. The reason I say more commonly this isn’t an issue for us as Power Platform solution architects is that this will be managed and owned by someone in a different role. However, this is still something for us as solution architects to be aware of. There are various things defined at the tenant level which determine where ‘things’ such as data gets resided.
Entire tenants will be located within a specific region of the world / in the Microsoft Cloud (Azure). Microsoft have data centres all over the world and your Azure / Microsoft Entra ID tenant will have its data stored in one of these tenants.
Depending on where a customer needs to store specific data, this could be something to keep in mind. Storing data in SharePoint for example will be based on the tenant location, however Azure resources can be spun up to store data in other locations than the location of the Microsoft Entra ID tenant.
Power Platform Environments
The next thing as solution architects we have to consider is environments for the Power Platform that we will put our building blocks / objects in! There are a few things to consider when looking at these.
One of the things we need to do is put the appropriate environments in place to support the application lifecycle management (ALM) strategy we need to put in place based on the size of the solution we’re building (other factors also come into account). If we’re only going to push through one stage of testing before moving to production or a ‘live’ version of our solution, perhaps you only need 3 environments. For other scenarios, perhaps you need more.
Another consideration to make is the location of the environments and where data should be sat. If we utilise Dataverse you’ll need to ensure the location of the environments is in a space which falls in line with any compliance policies in place.
Non-Power Platform Objects
Now people, in the last post in this series we spoke about the occasions where as solution architects we have to reach outside of the Power Platform when designing solutions to meet certain requirements. This could be utilising Azure Services, on-premise solutions and so much more… so… there’s some stuff to consider here too!
Now when it comes to working with Power Platform and Dataverse we can control all forms of security and access control using security roles. What’s key to remember here is that for every object and service we utilise that sits outside of Power Platform this isn’t the case. So you’ll need to think about the access control model around those external objects.
You’ll also need to think about things like data residency again for any objects that now don’t sit within your Power Platform environment. Sure you may have thought of it when setting up that environment, but does that Azure SQL database you’re spinning up also sit in the same geo-location? These are the kinds of things we need to think about friends and write into requirements!
One point I always like to consider when using objects outside of the Power Platform is the authentication method. Think of your user experience here friends and ensure users can authenticate to the resources needed with their one Microsoft Entra ID identity! No-one wants messy auth!
On premise interaction
A final consideration you may want to make when designing solutions is the need to interact with on-premise solutions. Normally I try to steer a little clear of having to implement solutions to interact with on-premise data and suggest movement in the direction of the cloud completely in these scenarios. However, there will sometimes be cases you come across these requirements and need to implement a solution. Think about how you’ll write this into the breakdown of work items for delivery consultants to complete.
What’s coming up?
So friends, stay tuned as there’s loads more content coming up on architecting solutions for the Power Platform! If you have any desired topics you want me to write about, simply pop them in a note to me or in the comments below 👇