Governing to enable solutions and people

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

Hey everyone! The next step on the enablement of your Power Platform and Copilot journey continues to build on our Scalable Governance foundation - You’ll remember that so far we’ve layered on our Environment Strategy and looked at where we best use Managed Environments, Environment Groups and Default Environment Routing, and we’ve designed our DLP strategy! Today we’re going to look at how we build our Governance on top of it and we’ll look at it from a Platform, Process, and People perspective!

Let’s start by asking ourselves the question - What do we mean by governance? And how does it differ to guidance?

Governance are the rules of the game - In Monopoly if our chance card says that we must go to jail, do not pass Go, do not collect £$€200… then that’s what we must do… unless we cheat, of course! In Power Platform we set rules on what people can do, where they can do it, how they can do it - Our Scalable Governance, Environment, DLP etc… They are our rules!

Guidance is the behavioural element - Imagine taking we’re wearing a blindfold and our friend has taken us by the hand and is describing what’s going on, some of the challenges, the actions that we need to take - In our Power Platform world this guidance could be by providing documents, guides, FAQs. It could be through sharing information in our community. It could be people responding to each others questions. It’s showing people the way… but they choose which pieces are important to them and what they’ll follow.

When we think about the governance that we need to put in place we can break it down into different elements - Platform, Process, People - When we’re designing our Governance we want to layer these up.

Platform Governance are the controls we can build into our platform configuration - Hard controls that enable people to do some things, and not do others - For example - We grant people permissions in specific Environments so they can or can’t use specific connectors we’ve made available through the DLP policy.

These are firm controls - they don’t require people to remember to follow them, or make a decision… They just ARE! These are our first level of control

Process Governance is how people interact with our world. They may be as formal as Policies and Procedures (e.g. An organisation’s Data Security policies, or acceptable use of IT resources), or they may be processes that we put in place to take demand into our service - Request Processes, or the operational processes for how we manage the platform.

These are less firm - Either people need to know that some of them exist, and remember what they contain. Or they need to know how to interact with them and follow them before they can do something e.g. request processes… For that reason these are our next layer of control.

People Governance is how we rely on people to do the right thing in the right way. We encourage the right mechanisms to encourage people to understand things like best practices, but ultimately it comes down to them following them. This is our last line of governance defence as it’s our weakest and least certain governance layer.

Because of these layers of effectiveness we design our governance in this order - Platform > Process > People - Let’s take each one in order and drop down into some detail mapped against our Scalable Governance Model to show where they are most applicable…

Platform

Proactive Governance - There is core governance that we apply across everything in the platform - Environment Strategy, DLP Strategy, Implementing Managed Environments, Developer Environments, Environment Groups

We can look at where pipelines are best implemented to enable pipelines, and where we may look at delegated ownership / management of environments. These should be considered compulsory across Large and Extra Large environments, We may also see some benefit into the more mature orgs in Medium environments

Reactive Governance - We can implement monitoring to keep an eye on what’s going on… Are solutions growing out of their permitted sharing, or perhaps their usage and criticality has evolved.

Perhaps new features are being released and we want to govern what we make available, to who, in what order?

Process

Proactive Governance - We can use processes like the automated maker welcome mail from the CoE Starter Kit to push comms across all makers to guide them to our Power Platform SharePoint Hub, our community, education paths any other sources we want to guide people to.

As we start to bring in advanced and elevated environments and connections in Medium, Large, X-Large we may opt to implement an attestation process or learning requirements to ensure makers are conscious of their responsibilities or levels.

When we get up into the Large / X-Large sizes then our IT operational processes are especially important - things like capacity or license management or forecasting, documentation standards, formal change management processes, audit access reviews etc.

Reactive Governance - Across all of our solutions we should be monitoring our solutions. These may be monitoring against how solutions are scored against our scalable governance criteria. We should be monitoring what orphaned solutions there are, whether we have unused solutions, environments, connectors that should undergo our housekeeping processes.

People

Proactive Governance - We need governance in place across the platform for all joiners. These may be people joining and needing to use solutions in our different sizes, or develop in these environments.

Our product owners of Large and X-Large solutions should be driving governance across their solutions, or the environments they manage, their responsibilities include being our governance representatives, as do our champions and community members.

Reactive Governance - The main reactive governance for people is generally monitoring what they are doing. We also need to consider how we will manage movers and leavers of environments and solutions and have mechanisms in place.

One way of bringing a number of these governance controls together holistically is to design your demand management process around them. Let me describe a scenario to try to bring it to life :)

In this example our new ideas, or our existing solutions, can be evaluated in a self assessment tool against our Scalable Governance criteria. Based on the responses these can direct our makers to what ‘size’ their idea, or their existing solution, is and what they should do next

If small and just use the limited connectors we’ve made available to everyone they can start building as we’ve employed Platform level control to limit what they can do and what they have access to. When they start building we can send them an email guiding them to where our help docs, training guides, governance information is, and how to join our community and how they get help and support through it. We’ll monitor against these solutions against the scalable governance criteria we defined and identify whether we need to intervene and suggest they move to a Medium environment, or higher.

If Medium we direct them to requesting a new environment or access to an existing one. We make ask them to attest that they’ve refreshed their memory of their org’s data security and privacy rules, and the acceptable use of IT resources procedure before granting access. We may introduce them to separating Dev and Prod environments and if they have premium licensing introduce Managed environments and pipelines.

If Large or Extra Large we might then ask them some additional questions about their use case, their sponsor, the business justification, their business process, if they need development support, if they have budget etc. so that when we take it into the qualification phase we have a good understanding without needing to go back and forth to get further info.

We triage these ideas and ensure whether we have enabled the service they’re asking for, whether their IT business partner agrees that it’s the right problem to solve and a strategic priority, and whether their are any regulatory considerations that need to be evaluated. We also have a light conversation with our architects to ensure that there isn’t a more appropriate solution using an existing system, or a different set of tooling.

We then design our solution architecture, data, UI / UX, and estimate the team, duration, and costs to confirm that the customer wants to proceed, and we take them through our formal governance steps like Architecture Review Boards, Security & Privacy Reviews, Compliance Reviews, Project governance boards etc. to get all required approvals and schedule the work, and resource it appropriately. We provide them with the new environments and educate them on their responsibilities on owning their own environments and how to perform them.

We can then develop it according to our development standards, and manage it through our Application Lifecycle Management processes using test cases and change controls. System documentation is written, Service Now groups are set up, KB articles are written for the help desk, solutions are transitioned into support. Our launch comms are published, our users trained, our product is launched into the world with a fanfare!

Rather than thinking of our governance as individual elements we can think of how it enables our solutions, value, and keeps them safe, but also how it enables our people to be as effective and efficient as possible - Finding this balance is the key to governance!

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! :)