Environment Strategy
Welcome everyone! This post is part of my wider series on how to implement low-code not just from a technology and process perspective, but also for a people enablement and adoption perspective to truly maximise value from the platform - This post gives an overview of the structured approach I’ve defined and how I’m breaking down my blog posts
Holistic Low-Code Enablement - Blog structure and navigation — EmPOWER Your World
As you read in my previous post we’ve got a scalable governance model to manage different ‘sizes’ of solution and to balance enablement of people to develop their solutions, with safety of our data, processes, and organisation… but how do we implement our platform to enable that model, develop those solutions and grow adoption and value? Our first piece of the puzzle is setting our Environment Strategy.
We’ll start by thinking about how we might structure our environments to reflect the increasing levels of risk / complexity / criticality, and the shift from business developers to more traditional IT practices. As the risk rises we want to increase the robustness of how we manage these solutions to mitigate the risk.
One way of doing this is to introducing the concepts of Application Lifecycle Management through our Environment Strategy as the risk rises and the impact of any issues increases.
Many organisations have different appetite to risk, different standards, different requirements. I’ve shown some of the most common approaches / configurations above.
As we spoke about in the Scalable Governance post - The way we’ve defined these ‘Sizes’ in a specific way and can use that to connect our environment strategy to how we manage that level of risk:
Small are low risk, low complexity solutions, with basic low risk data, low criticality, productivity solutions using general ‘Office’ connectors and they’re shared with a small number of people. The sort of solutions that people would otherwise use tools like Excel to solve. Because of this we shouldn’t be so worried about these and so perhaps we’ve happy for these to be lightly governed through controls and restrictions we can apply to the default environment.
Medium are a step up in complexity, perhaps shared to a bigger group of people and so the criticality and potential impact starts to rise. We need a bit more robustness, we want the solutions to be backed up, we might start to introduce some of our business developers to the concepts of solutions and Dev and Prod to ensure our changes don’t impact our users and teach them to export and import solutions between their environments. We might create a environments for teams or departments or functions to put their solutions in to segregate them.
Large are a step up again - Business Important solutions that we’re starting to rely on, are perhaps connecting to bigger data sources or business systems. They might be shared with a larger user group and be delivering value that impacts our KPIs. We’ve got to look after them! We’re doing to be documenting them more fully, logging them in our CMDB, defining support models reflecting their operating hours, formalising our change management processes and testing approach etc. Our environments reflect, and enable, that and maybe we start to introduce pipelines.
Extra Large raises the bar further again, fully aligned with IT standards, best practices, documentation needs, support models, SLAs etc. etc. These are our most important, most critical, highest risk solutions and so we treat them with care. We likely have automated pipelines and testing, with approvals. No human developer accounts anywhere except in Dev etc. Environments dedicated to specific solutions.
Using this approach we have a way to robustly govern our platform, enable our developers of all types, But with different levels of overhead and effort.However there are ways to reduce this overhead….
Over the last 6 months or so we’ve been given more options on how to manage control over our environments and solutions even better! Managed Environoments, and just the last week the launch of Environment Groups!
You may have recently read announcements about about the launch of Power Platform Environment Groups for simplifying managing multiple controls across multiple environments - https://learn.microsoft.com/en-us/power-platform/admin/environment-groups
And you might have been reading about how managed environments have been deployed and the types of features they provide us with - https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview
We know that to use Managed Environments and Environment Groups we need all makers and users in that environment to have premium licenses so they’re not available to everyone. But if we invest what capabilities do those licenses buy us, and what do managed Environments (currently) provide? How might we categorise them? And which can be made available through Environment Groups?
As you might have expected if you’ve read my other posts… I’ve drawn a picture! 😁 I’ve classified them by Controls / Compliance, Process Enablement, Comms / Engagement, and Information / Insights. I’ve flagged which can be managed through groups.
I’ve then thought about how these capabilities might relate to the ‘T-Shirt Sizes’ in our scalable governance model, and the types, and capabilities, of the makers who may be developing those sizes of solution. I’ve then scored them on how valuable I see them being in those different scenarios. I haven’t weighted them at this stage though. I’ve just looked at them all equally.
As you can see a number of items I’ve scored the value as amber. This is due to the value being scenario dependent - for example for Limit Sharing - In ‘Large’ these could be business led solutions where we may want to control levels of sharing, or IT Developed solutions which have undergone governance to approve use case and operate under those limitations. However it may be that we manage who we’re sharing with through System Access Plans, and Defined access review processes and so are less concerned by the actual numbers but instead that they are the RIGHT people with access.
For other controls like Customer Managed Key - The way that we’ve designed the Small and Medium sizes is to limit use cases and connectors to low risk use cases, often with just the Microsoft Office connectors. We won’t be using a Customer Managed Key in that scenario - hence them being red. For Large / Extra Large it’s going to be dependent on the use case and connectors.
Managed Enviornments, Environment Groups as an enabler for Scalable Governance
If we reflect on these Managed Environment capabilities and how they apply to our Scalable Governance and our Environment Strategy they give us ways to have greater control at lower ‘Sizes’ without adding complexity or overhead to our developers.
This brings us more options and capabilities! As an example of what that could mean against our scalable governance model
Small - We can make use of ‘Default Environment Routing to send makers to their own dedicated environment, grouped together so we can manage simply, where they can create their own solutions, we can automatically enforce the number of users they can charge with as we defined for that T-Shirt Size. We can automatically provide makers with welcome content.
Medium - Grouping similar sets of environments together for simple management we can implement simple pipelines that business users can use without needing to understand, we can limit sharing as we defined in the model. We can enforce solution checking to improve the standard of our solutions. We can simplify promoting solutions through our app catalog and automatically generate descriptions of our solutions..
Large - Our Business Important solutions can have all the additional benefits we’ve used in Medium plus bringing in some of the additional security benefits, monitoring benefits with App Insights. We could group together our Dev, UAT, Prod Environments for departments to make management easier.
X-Large - On top of everything else we might have solutions supporting our regulated, or business critical processes where one of the requirements is for us to have back ups that extend longer than the standard backup capabilities.
As you can see from these examples showing how managed environments and environment groups simplify management against our scalable governance model There’s clear value to deploying Managed Environments at each individual level! But it also smooths the transition through the sizes as solutions grow and are deployed wider across an org to enable more value too!
If you’re buying licenses for solutions we’ve defined as ‘Large’ and ‘Extra-Large’ then it’s a no brainer to configure them as managed environments. Is the value enough to trigger premium license investment for all makers / users of Medium, or Small environments…? I think that’s down to the organisation… but perhaps not…
But if you / they have invested in Premium Licenses across the organisation then I’d use Managed Environments everywhere!
Additional posts connected to this topic :
Scalable Governance of Low Code solutions for any organisation — EmPOWER Your World
DLP Policy alignment to scalable governance model — EmPOWER Your World
If you find this post or any other of my posts useful please subscribe below to make sure you don’t miss out on future posts when they’re published! :)
