Assessing the maturity of your Power Platform enterprise management and governance

This is the next in a series of essays in which I’m more deeply exploring my favorite best practices from the Power Platform Adoption Framework. The first can be found at Power Platform in a Modern Data Platform Architecture, and the most recent at One Thousand Workloads: How your Roadmap maximizes Power Platform investment. The essay below is derived from what's I’ve written in the Adoption Framework at this link.

Enterprise management, governance, and technical infrastructure for Power Platform are organized around five pillars and 22 dimensions as shown in this diagram.

Organizations must continually mature their Power Platform enterprise management in order to unlock the platform’s value as a first-class cloud application platform and scale it over time. The Enterprise Management Maturity Model is the common standard that can be applied across the platform (and extended across the Microsoft Cloud as well) so that we may assess the maturity of enterprise management and governance, evaluate where an organization has made progress and remains less mature, and identify both organizational risk and opportunities to generate new business value.

Pillars of Enterprise Management

Long-time Power Platform Adoption Framework practitioners are very familiar with the five pillars and 22 dimensions of enterprise management. We’ve developed these pillars and dimensions with a lot of community input and refinement over several years. They' have proven both flexible and durable in seeing that an organization accounts for all it must when establishing and maturing Power Platform at scale. Essentially, the framework recommends five big categories—we call them "pillars"—each with a set of child "dimensions" beneath them that need to be accounted for in an ongoing Power Platform adoption. You can learn more about the concept here.

But this model extends far beyond initially establishing Power Platform in the form of what we call a “Landing Zone”. True enterprise management and governance requires ongoing maturation, so that the organization is able to absorb changes to its own technical and data ecosystems, provide for internal demand for platform services, respond to evolving market and regulatory conditions, and take advantage of updates to the Microsoft products themselves.

Enterprise Management Maturity Model

The Enterprise Management Maturity Model helps organizations assess the maturity of enterprise management and governance in order to evaluate where the organization has made progress and where it remains less mature.

In the model, each dimension is reviewed with cognizant technical and organizational stakeholders—and your Power Platform CoE team, I hope—to reach consensus on which maturity level and description fits best at the time of review. These ratings align to the 5-point scale outlined in the diagram shown here, with "Evolutionary" (5) being the most mature and "Unaware" (1) being the least.

Apply the Enterprise Management Maturity Model to each dimension in order to determine each dimension’s maturity relative to the others, then identify those risks and opportunities to further mature management and governance, and therefor allocate resources to the areas of greatest need.

More mature dimensions are technical assets to be leveraged across the business. They are also indicators of success that justify investment, in other words, where an investment has sufficiently matured a dimension and effectively bought down corporate risk. Less mature dimensions represent organizational risk and / or opportunity to unlock new capabilities, and should generally be a focus of investment.

Note: In April 2021 the Microsoft Power CAT group released an “Adoption Maturity Model”. These models are complimentary to one another wherein the Adoption Maturity Model can provide a high-level means of understanding where an organization is on its Power Platform journey, whilst the Enterprise Management Maturity Model provides deeper granularity, risk assessment, and opportunity identification around the things about which IT groups most care: Platform Management, Enterprise Architecture, Application Lifecycle Management, Mature Security Model, and User Empowerment. In other words, use the Adoption Maturity Model when you’re looking to go broad and high-level, but use the Enterprise Management Maturity Model when you’re looking to go deep.

Assessing your Enterprise Management maturity

The model provides a common standard for assessing platform maturity, but it cannot be used on its own absent the insight and judgement that comes from professional expertise in Power Platform enterprise management and governance. Low code does not equal low complexity, and the framework is best used as a tool in the hands of experienced practitioners, not as a formulaic shortcut to platform maturity. This is a particular area where a Microsoft partner or individual practitioner(s) are quite useful.

I observe some ground rules for its use when when speaking with IT stakeholders:

Round down when undecided between two maturity levels. It is better to overestimate risk than to ignore it.
There is no shame in “Disarray”. It is better to admit where we are and fix it than to hope things magically improve.
“Strategic” is a high bar to achieve. It means that we’ve planned and committed resources to future state.
“Evolutionary” is an even higher bar. It means that we’re actually executing our plans, day in and day out.

Defining and refining CoE roles and responsibilities (the “CoE Establishment” dimension) requires that each dimension be clearly “owned” by someone or a group of someones within the organization. “Disarray” is the best you can hope for absent clear ownership, so resist the temptation to mark owner-less dimensions any higher than (2).

The pace at which an organization assesses its dimensions is important. Too infrequent assessments can result in bad data that could skew risk management and resource allocation, whilst assessing too frequently can waste a lot of time in pursuit of only marginally more up-to-date results. In general there are three reasons to update a dimension’s maturity assessment (up or down):

When just starting out on your Power Platform adoption journey. It’s hard to know what to do next when you don’t have a firm understanding of where you are. I recommend assessing all dimensions in a single go.
At a regular cadence that makes sense for your organization. Could be quarterly or every six months. It may also make sense to re-assess a different pillar each month to produce rolling maturity updates.
When a compelling event occurs, which might include big Microsoft product updates, acquisitions or major internal re-orgs, following a governance incident, major platform expansions in the organization, etc.

If opting for a six-month regular re-assessment cadence, consider conducting those in May and November to follow Microsoft’s big Power Platform release waves that begin in April and October each year.

Quantifying your Enterprise Management Maturity

We can then determine the following indicators of overall enterprise management and governance health for Power Platform in an organization at any given time using a scale of 1-5 (with 1 being least mature / highest risk and 5 being most mature / lowest risk).

Aggregate Platform Maturity (APM) = Sum of each dimensions' maturity divided by 22 (the total number of dimensions). This tells you where you are with enterprise management as a whole.
Pillar-level Maturity (PLM) = Sum of the dimensions' maturity for a single pillar divided by that pillar's number of dimensions. This helps you identify pillar-level areas of focus in maturing towards your next horizon.

These values are crucial metrics that allow the Center of Excellence (or other platform owner) team to demonstrate progress, IT leadership to assess risk, and for decision makers to set priorities and allocate resources.

The following guidance may generally be applied to qualify maturity rating at the dimension, pillar, or aggregate platform level:

Ratings of less than "3" (disarray or lack of awareness) are high risk / high opportunity; address these immediately
Ratings of "3" (reactive approach) are both a risk and opportunity for the organization; address these when possible
Ratings of greater than "3" (strategic or evolutionary approach) are lower risk and areas of strength; protect them

This is a representative example of where I’ve found many organizations are in their Enterprise Architecture maturity when I first begin working with them. It tracks with the typical discussions I’ve shared here.

So taking the "Enterprise Architecture" pillar as an example, we might assess each dimension as shown in the table below to determine a PLM rating of 2.6 indicating high risk, high opportunity, and a need for immediate action. I would find this to be fairly representative of where most organizations are with their enterprise architecture when I’m just getting started with them. Below are typical outtakes of those conversations I’d have with IT teams (over several hours) through which we might have arrived at this example assessment.

Authentication: We’ve migrated from on-prem to Azure Active Directory. We set up security groups when we made the migration, so we can wire those into the Power Platform security model… but we’ve not revisited them since, so we don’t know if they’ll really meet our needs.
Environments: We’re letting citizen developers “play” in the “Default” environment, and we’ve created a few dedicated environments for a few app development initiatives as those requests have been made. Also, we have Dynamics for Sales, but we’re just now learning that that by definition means we have environments running for that solution.
License Management: We’re thinking of making a big license buy on our next enterprise agreement renewal with Microsoft, but we need to see the value first. For now we’ve bought a smaller number of licenses and are assigning those out to users as needed.
Reusable Components: We had never considered the idea of a base solution, and until just now didn’t know that PCF components existed.
Data Ecosystem: We’ve migrated some of our on-prem data to a combination of Azure SQL and Data Lakes (as appropriate), but we still have a lot sitting in XYZ data center. We also have an effort underway to build a modern data warehouse, and we know we’re going to need to connect Power Platform to that if we’re going to be building “important” and “critical” workloads there… but we’ve not really thought of how to do that (yet).

From Assessment to Action

PPAF_20210718_Enterprise Management Maturity Model (Typical).png

Some might be alarmed by a maturity assessment of “2.6 - Disarray”. I’m not. Because, as if I’ve said, this is a pretty typical state of affairs for organizations just beginning their adoption journey or trying to impose maturity rigor on a a journey already underway. Extrapolating the example out across the five pillars and 22 dimensions, I actually have found most organizations to hover with an Aggregate Platform Maturity (APM) rating in the mid to high “Disarray” zone when they first start to think seriously about enterprise management and governance.

So… don’t despair!

Your first step is to use the insight you’ve gathered via assessment by turning it into action. Once you’ve determined where you’re mature and where you are lacking, then identify the dimensions where you most urgently need to improve with your internal CoE team, Microsoft, and your Microsoft partner team (if you have one). Set goals for where you need those dimensions to be in (say) three (or six) months. Then determine actions necessary to mature those focus dimensions to a minimum viable level. The goals you’ve set represent your “next horizon” of enterprise management maturity. The actions you’ve put in place to meet those goals form your backlog through which to work.

This assessment to action approach offers several benefits as it:

Focuses your budget and effort on the dimensions of greatest need
Brings order to your enterprise management and governance activities as part of a larger, more strategic platform adoption
Allows platform owners to demonstrate value for money over time, i.e. three months ago we were “there”, but through investment we’re now “here”, and these are the benefits we’ve wrung from that investment
Creates a more clear path to deploying important and critical workloads into production, particularly when IT security and “security accreditation” is in play

Lower maturity is a marker of risk to be bought down, so to speak, but it also represents an opportunity to make the transition from the previous IT generation of “point solutions” to the next generation of platform-first approaches that I’ve taken to referring to as the “Cloud Application Platform”. I’ll write more about this in a future essay.