Scalable Governance

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

UPDATE - After you’ve read this to understand the basics and thinking behind Scalable Governance go and see this update Blog Post to find out how it’s evolved into Scalable Governance V2! :)

Every Power Platform implementation needs a solid foundation on which to build adoption - This is our governance. We want to secure and protect the things which we care about most, and be more free to innovation and experimentation on the low risk things that we care about least.

The way we look at this is from a platform perspective, process perspective, and people perspective. We think about how we can use different controls on these to set the guardrails on where people can work, what they can do, the processes, standards, and best practices they need to follow.

For example this means having an Environment Strategy that both protects and secures, but also enables. It means being clear on which connectors are made available to which developers. It also means what data sources we think they should use for different types of use case, what support model they should have in place, what governance boards they should interact with etc.

We don’t want to push every single use case through all these things though. For one it would be hugely inefficient, frustrating, and overwhelming for the processes but equally it would place big overhead and barriers in the way of a load of really simple, low risk use cases where people are trying to make their lives easier and more productive

One governance size doesn’t fit all!

Image : Scale of solutions from simple to complex

So let’s think about what a scale of solutions might look like.

At the small end of that scale we have solutions that are for people / teams to increase their productivity - They likely have few users, are simple processes, low risk to the business, and low criticality if they go wrong. These are the types of use case that people are probably solving today in Excel or SharePoint Lists

At the largest end of the scale we have solutions that could be deployed organisation wide to 10’s if not 100’s of thousands of people, are complex processes, higher risk to the organisation, higher criticality and disruptive if they go wrong. Because of these factors and importance they’re likely… or at least should be… build to high standards, supported, invested in, and treat their data with care and respect.

The majority of Power Platform solutions will be use cases at the lower end of this scale where Citizen Developers or Business Technologists are solving problems of different sizes every day.

The smaller percentage that are big, complex, important… Need to be designed, architected, resourced, governed, prioritised and developed by people with the level of skill to create robust, scalable, supportable solutions of this importance. These are commonly IT developers, following standard IT standards and best practices.

So let’s take that forward a step and work out how we can translate that into a model that anyone can understand - a citizen developer. An IT Developer. Someone from a governance team. A business or IT leader… Anyone!

Image - Applying T-shirt sizes over the solution complexity / risk / user base scale

We’re going to set some ‘T-shirt sizes’ over our solution scale - Small at the simple, low risk, low criticality end. X-Large at the complex, higher risk, high criticality end.

These t-shirt sizes are how we’ll make it incredibly easy for anyone to think about their use case idea, or something they’ve already started building, and identify what t-shirt size their use case is. From there we can also tell them what the standards and best practices are for that size, and what environments they should be working in, what governance processes they need to go through…. What their next steps are!

But it’s not going to be 100% perfect… No frameworks are! We need an exception process too so people can challenge where it feels they’re being guided too harshly, or too leniently.

Also, for all the similarities between organisations, there are always differences too. How do we describe the line between Small and Medium? Or Medium and Large?

Also, what do we do when solutions evolve, or grow, how do we intervene?

Image : Example simplified description of t-shirt sizes, and standards / expectations for those sizes

This table shows a simplified view of how we draw those lines between the sizes to help people understand the differences between them. There are multiple criteria which we need to think about for a use case to describe the risk associated with it. For example we need to think about Data risks, financial risks, business continuity risks, regulatory risks so we can use multiple criteria to describe each ‘t-shirt size’ dependant on what’s important to our organisation.

The way we describe each of those criteria against the different sizes is how we draw the lines between what we’ll allow. For example we might be fine people creating a ‘Small solution’ sharing it with 3 people… or 5? Or 20? But if they breach that then it’s a ‘Medium solution’. If they share it with the organisation perhaps it’s then a ‘Large solution’ or ‘X-Large’ depending what it’s doing. Any organisation can then draw those lines how it views risk levels, and can align them to anything already defined in their Policies and Procedures.

By using plain business language rather than techie language anyone can then use it to ‘size’ their idea. It gives us a way to describe the risk of a use case!

It also gives us a way to define what our expectations are of that use case should it be developed into a solution! As you’ll also see in the table we can tell people what data sources we’d expect them to use - e.g. If you’re using Personal Info then you’ve got to secure it, so you’re going to need to put it in DataVerse or SQL, for example. We can also tell them whether we expect it to be branded in the company’s brand… or what support we’d expect them to have… Or what documentation might be needed… or what governance boards they need to go through… We can make it really clear for them!

And after testing and fine tuning these things through a fairly manual process… well we can also build some tooling around these to give people a simple process to help them and direct them to the next best action, or who to consult with….

If / When a solution grows we can also use data to identify when to intervene! Shared with 100 users when it should have only been 10 we can tell them, “Come and see me please!” 😁

We can ask people to update their question responses every 3 months, 6 months, 12 months… whatever we choose so they can give us fresh information too!

The other thing we can start to do is to use the model to define our Environment Strategy to give the right controls aligned to our T Shirt Sizes. This builds on a couple of pieces of work that define a theoretical platform architecture / landing zone

Microsoft’s PP North Star Architecture

Power Platform Adoption Framework

This scalable governance framework gives us a practical way to implement aligned to the organisation’s strategy to give a solid and scalable foundation to build adoption