Scalable Governance v2

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

Back in June ‘23 I wrote a post about Scalable Governance. Since then I’ve probably used that model with about 20 organisations across public sector, financial services, healthcare, manufacturing; Across UK, Europe, and the Americas; Some at the beginning of their journey and others more advanced; Some focusing on Citizen Development, some IT Dev . I’ve also been working with organisations where they are bringing together federated low code teams where Power Platform and Service Now low code is happening together using the same scalable governance model we’ve defined.

As you’d expect although there is a lot of commonality in how the model is deployed as that’s how it’s been design.

This is how I described it previously showing that the scope of Power Platform use cases can be small, simple, low criticality, low risk (left), and enterprise scale, high complexity, large criticality, with sensitive data. And we can conveniently split these into productivity use cases owned by the business and Citizen Developers, and important / critical use cases led by IT and run as IT products and services.

However as more and more organisations have embedded low code and it’s matured in their organisations we’ve seen differences!

One of the differences we’ve spotted has been how ambitious of some organisations embracing Citizen Development at scale are and how some have really fantastic groups of smart people who are pushing the boundaries and wanting to develop solutions which use premium connectors but are still relatively low risk solutions. In our previous version of the model we classified these as ‘Large’ solutions. However these examples don’t justify weighty governance and development standards we would have generally prescribed.

Another difference has been with ‘Medium’ sized use cases, which are generally low risk, team productivity solutions, with low complexity and business criticality, and are of the type where we encourage people to develop them themselves. Some groups either don’t want to develop themselves, have a more urgent need for the tool to be in place, or perhaps want to collaborate with someone else building it. In these scenarios they ask for developers (IT, or partners) to develop for, or with, them. This resulted in us often using the term ‘Medium Plus’.

Because of this I’ve re-drawn the scalable governance model to reflect this difference and build this flexibility into the model.

Previously there was a dividing line between Medium and Large with Cit Dev on the left and IT Dev on the right. Although that made for a nice tidy picture it didn’t reflect the world of a mature adoption of low code technologies like Power Platform. We can now position that ‘Large’ type of solution as being a blurred line between the two groups. Sometimes 100% business, sometimes 100% IT, often a blend of the two in fusion, or hybrid, teams.

The principles on how we describe the different sizes have also evolved!

Image : Table showing the criteria and example values that describe ideas / use cases / solutions that we can call Small / Medium / Large / X-Large

Previously the criteria which we used to describe the sizes (where we also provided examples of what these answers actually mean in business language too, of course) all had the same weighting. As more and more new ideas, or existing use cases, were assessed it became clearer that we were more flexible and introduced ‘wiggle room’ around some criteria but were less tolerant around others. Because of this I’ve introduced classification of them as ‘FIRM’ where we aren’t willing to down / upgrade ‘sizes’, and ‘FLEX’ where these are more subjective and open to negotiation.

Image : Table showing the criteria and example standards / best practices / processes that we can define should be followed for Small / Medium / Large / X-Large

As well as this FIRM and FLEX terminology also translating through into the standards and best practices expected for each of the sizes, I’ve also identified more standards we may wish to define.

This v2 bring with it a leap forward in how it applies to organisations at any stage of maturity, using any low code tooling, and enables them to describe use cases using a common language and define the standards and governance needed to execute them with safety, security, and scalability for the organisation!

Additional posts connected to this topic :

Turbo charge your Power Platform with Managed Environments and Environment Groups — 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! :)

Previous
Previous

Environment Strategy

Next
Next

Maker Movement v2