Wednesday 8 January 2020

Improving Power Apps governance and analytics

Some of the work I’ve been doing (alongside some talented colleagues) recently is around improving governance of Power Platform use within an organization – in particular Power Apps, since a lot of the risk tends to be centred there. It’s becoming increasingly common that the Power Platform can be be widely-adopted within a company (or at least, adoption is growing), but a whole new set of problems become apparent in terms of exactly who is doing what with which apps. In some ways, ungoverned use of Power Apps and Power Automate can become a free-for-all in an organization – and this can cause serious operational problems if a critical app created by someone in the business has problems, or that person changes role or leaves the company. In many cases, people 'out there in the business' can create apps which become critical and users expect I.T. to provide support – but I.T. have a blind spot to what is happening in this area and don’t know the first thing about the application.

Common questions are:

  • How do I.T. get on top of this? How do we become aware of which apps exist already, and which are being created?
  • How do we discover whether apps are connecting to Azure, SQL, SharePoint, or perhaps even SAP, Workday, ServiceNow or ungoverned cloud services such as Dropbox?
  • Which accounts are used for connections? Are they appropriate?
  • Are we protected if that person who made the app leaves the organisation or moves to another role?
We’ve done some work around this with some organizations, partly based on the Power Apps COE starter kit. However..

The Power Apps COE starter kit is not a turnkey solution

Whilst the COE starter kit is a great baseline, as the name suggests this isn’t a turnkey solution. For one thing, unfortunately it’s based on CDS which means immediately that every maker of a significant app in your organization may need additional licensing just to use the governance solution! This seemed crazy to us, since many makers within our clients are using Power Apps extensively, but focusing on apps which only talk to Office 365 sources – and so these users would not therefore would not have a ‘per app’ or ‘per user’ plan license.

So, we decided to create a fork of the COE kit which is re-engineered to store data in Office 365. This side-steps this and provides some additional benefits over the baseline, and is the solution we’re using with our clients.

A peek at what the solution provides

The solution provides quite a few things around analytics, doing a lot of data collection in the background (including app launches from the Office 365 audit logs – another area we had to tweak) to provide a Power BI dashboard which provides some very useful insights. Here's just ONE screen from it, but the tabs across the bottom give you an idea of what else is in there:

The governance framework also introduces the idea of ‘compliant’ and ‘non-compliant’ Power Apps to your organization. This consists of a few things, including requests to app makers to provide a mitigation plan for their app. Exactly what should happen if the app becomes unusable or an update breaks something? Since I.T. aren’t necessarily in a good place to provide SLA support, having these things in place can de-risk the situation significantly across the enterprise. Administrators get to see a traffic light rating of each app, as well as having built a good understand of each app including it’s connections and data sources, the environment used, the usage patterns, the maker(s) and users and so on.

We also do a lot more to facilitate a well-functioning Power Apps maker community – including creation of a Power Apps Knowledge Center site with some policy content we wrote, and using the data we collected about makers, creation of a Yammer group or Microsoft team where all the top makers are invited and introduced to each other. From there, they have a place to share experiences, ask for help and so on.

A podcast interview about this

If you want to hear more, I was interviewed recently by Jeremy Thake for the Microsoft 365 Developer Podcast on this. In fact, we only decided that this would be the topic at the last minute, but I think it came out OK! If the embedded version below doesn’t work, the direct link is:

https://www.podbean.com/eu/pb-s8iq2-cab99d

No comments: