Microsoft 365 is a vast platform capable of uplifting an organisation’s productivity, collaboration, and communication capability. Many of the products within M365 require little oversight above ‘Give everyone a license’ or ‘Make sure Office is part of the SOE’. Other products require significant investment and implementation before they can be used at all – most notably the Power Platform including Dynamics.
There is, however, a third category of tooling within the M365 platform that is often activated, users are granted access, and they are promptly forgotten about. The two most prolific tools in this category are Teams and SharePoint, although OneDrive, Planner, and Yammer also fall into this category. Without planning and governance applied to these platforms, they are liable to grow beyond control and either cause an insurmountable mountain of tech debt or force themselves into obsolescence.
A bit of history
The idea of a platform being provisioned, handed to users without oversight, and for it to ‘sprawl’ beyond control is not a new one. Anyone who has managed a SharePoint environment since 2007 has likely experienced it. All through the 2010s, stories abound of server administrators following the installation wizard, granting a variety of business users Site Collection Administrator (AKA ‘Do whatever you want’) access to a top-level site collection, and then forgetting about it for years until the hardware it was hosted on collapsed under the weight of the million things it was trying to do.
As a consultant, finding one of these environments was a nightmare. Thousands upon thousands of nested sites, custom security, important documents stored either at the root level or down a 5-deep subsite hole. We would find different branding and code applied at different levels creating multi-directional dependencies. It is simply not possible to clean a mess of that size. All that could be done is to provision a new environment, migrate the useful content into a more structured, managed architecture, and then destroy the old platform. It hurt the business, it hurt the users, it certainly hurt the budget, but it meant that life could go on.
Without governance over M365, the same will happen. Within years, your M365 tenancy will be an unmaintainable, unintelligible mess.
What needs to be done?
The strength of the Microsoft 365 platform is its flexibility. Limiting this flexibility of the platform should never be the aim of governance. Instead, when attempting to govern the platform, you should aim to build three core pillars:
- Architecturally Sound
Are the resources being provisioned in the right location? Are they secured in the right manner? Do the right people have access? Can the right people modify who has access? Is the tool capable of meeting the business need, and if not, can it be extended? Is what is being provisioned the actual best possible tool for the job? How do people get access to this information? Is the right data stored in the right place to meet all your legal obligations?
- Supportable
How will data be stored? Where will it be stored? Who will pay for the consumption? How will it be backed up? How will it be restored? How will people know how it is being backed up and how it can be restored? If there is an issue, who should be contacted? What are the typical things that need to be done to the environment? How will they be delivered? Who will pay for the support? Especially for OneDrive, what happens when a user leaves, and who owns that data?
- Maintainable
What is the lifecycle of the information? Is there perpetual growth, or should data be archived or deleted? How do you identify ‘stale’ content? How do you know where useful information is? How do you ensure information is not duplicated? How do you allow users to recall information that may have been archived or deleted? What tools can you provide to your users to manage the platforms?
A solution to each of the three pillars of good governance is unique to your situation. There are no universally right or wrong solutions – other than ignoring it completely.
How can it be done?
The out-of-the-box capacity for M365 to be governed is lacking. The report centres of M365 are designed to encourage uptake, not ensure responsible usage, and are sorely lacking in much of the information, reportability, auditing quality, and automation required to actively govern the platform.
Several fantastic commercial off-the-shelf solutions exist within the market. Analysing and investigating these solutions to understand the types of features these products provide and their respective costs are strongly recommended. For example, the LiveTiles Intelligent Intranet solution, AvePoint Cloud Governance for M365, ShareGate Apricot are the most popular, but many more options are also available, and constantly evolving.
While the standard functionality of M365 lacks governance tooling, Microsoft provides many incredibly powerful tools to help develop your own governance toolkit, often without the need to write a single line of code. After answering all the questions in ‘What needs to be done’, and building your theoretical three pillars of governance, one or many tools need to be built to implement your governance framework.
The requirements for these can be boiled down to the following core features:
- User Interaction
Collect information from your users, and present information back to them. This will likely be relevant for the creation of new assets, the collection of additional information about existing assets, the confirmation of actions that need to be taken, and lastly, the presentation of the current state of assets for review. - Data Ingress
Collect technical information from existing systems and assets, and process it into a usable state. - Data Storage
Store the information collected from both users and systems in a convenient but secure location - Reporting
Get useful information from the data that has been collected - Business Process Management
Identify the need for and execute parcels of work identified by your business rules.
User Interaction
Where possible, you should try to minimise disruption to existing processes. If you can build your pillars without stopping the ‘Create a team’ or ‘Create a site’ process within Teams and SharePoint respectively, this is ideal. If this is not possible, build your processes in the most intuitive way possible – if you currently have an IT Service Portal in which all service requests go through, use this as your platform to manage new incoming requests. The creation of an entirely new interface should be the last resort, only if all existing options have been exhausted.
If you do need to build a new user interface, Power Apps can build extremely powerful interfaces in very short periods, that can then be embedded into either Teams or SharePoint.
Data Ingress
Collecting data from the many different M365 tools should be done using the Graph API.
Other options may include using non-Graph REST APIs, PowerShell commandlets, Power Automate native connectors, or a variety of other options, but after trying many different variations and combinations, the Graph API is the only one that can possibly achieve the scope and detail required to perform good governance.
The Graph API can be consumed using the HTTPS Connector in Power Automate, using PowerShell, using an Azure Function (NB: At the time of writing, Executing PowerShell with Azure Functions had versioning issues, meaning that it was not an acceptable solution, but the author expects this will be fixed by the time you are reading this), or through any other protocol.
Accessing the Graph API should be done using an Azure App Registration (Quickstart: Register an app in the Microsoft identity platform | Microsoft Docs). Any client secret(s) generated for the app registration should be secured using an Azure Key Vault (What is Azure Key Vault? | Microsoft Docs).
Data Storage
Two practical data storage options should be considered.
Firstly, if you are working with a low volume of data (<100,000 records), it may be possible to create an ‘Administrative’ SharePoint site and use SharePoint lists to store the data required. This solution will allow for extremely easy connection with any Power Apps, extremely easy integration with Power Automate, and extremely easy reporting with Power BI. The biggest downside to using SharePoint as your data storage platform is performance – it is not designed to process data at high volume.
Secondly, if you are looking for a more robust solution, consider enterprise-grade storage option, which would be a dedicated database. There are plenty of options for database storage in Azure (Azure Databases – Types of Databases on Azure | Microsoft Azure), most of which would be potentially appropriate – depending on your skills and budget. These options will significantly increase the development time required to build a data storage platform but is the best option for long-term usage.
Reporting
Power Apps can provide an excellent at-a-glance dashboard across the current state of the data, as well as allowing write-back where required. This can become an excellent method for two-way data interaction. This is contingent on there being a connector for Power Apps to access your data source.
For true reporting, including analytics, alerting, and visualisations, there is no better tool than Power BI. Power BI should have no issues integrating with whatever your data storage options are.
Business Process Management
The best place for Business Process Management is as close to your data and users as possible. For example, if you are using a ServiceNow instance to interact with your users and store data, it makes sense to use the ServiceNow Flow Engine.
If you are planning on a primarily M365-hosted solution, Power Automate is an option and rapidly becoming a tier-1 business automation engine, although a premium license may be required. Azure Logic Apps can fill a similar role with a more Azure (rather than M365) focus.
Finally, there are also many other good workflows and business process management engines you can choose from, the most notable of which being Nintex Workflows.
