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?
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:
Post a Comment