What's Your Power Platform Strategy

The Power Platform is a Citizen Developer platform, designed to be accessed by everyone, just like Excel. But it is not just like Excel, it's built on Dynamics, a powerful fully featured CRM tool, so it can be much more like a standard IT solution. This means as a platform owner you have a choice, Excel or CRM, so what is your Power Platform strategy?

But there is not just your strategy, there is also your model. If the strategy is your direction, the model is how you get there. It's the practical implementation of the strategy, the rules and processes setup.

There are 4 main strategies/philosophy's when setting up the Power Platform, and they are:

1. Personal Owned
2. Scaled
3. Federated
4. IT Owned

1. Business Owned

Spun up by IT but then delegated to the users with little to no oversight. This is the "I trust you" approach, you empower the citizen developers to make any solution in their own way. Kind of like the Excel model but on purpose instead of by accident.

2. Scaled

Different controls depending on the solution, with low no IT involvement and high fully IT owned. This is the "I trust you but it depends", with different indicators/thresholds setting the level of independence for the developer. If it breaches the threshold there is less trust with IT getting more involved.

3. Federated

Business teams are up-skilled to own their own environments, with IT governance enforced but the process not managed by IT. This is the "I trust you but only if you do it my way" approach, building out the processes and tools for citizen developers to create their own IT setup.

4. IT Owned

IT owned, managed and used by IT professionals only. No mistaking this one, it's the "I don't trust you". The low code capability is only to improve the productivity of IT professionals, no citizen developers allowed as the risks of something going wrong are too high.

The most common models I see that represent the 4 strategies are:

1. Full Citizen Developer
2. Managed Risk
3. Business Managed
4. IT Integration Tool

1. Full Citizen Developer

The full Citizen Developer approach encompasses what I think the original vision of the Power Platform was. Just like Excel, anyone can build and share. The developer owns everything, from design to build to test to deployment to support.

There is no Dev/Test/Prod, everything is prod.

The organisation setups up with a 'Default' first approach. DLP policy is all or nothing, once approved anyone can use it. Dataverse is not used as tracking ownership of the space is difficult, so all the developers use SharePoint or Excel/OneDrive.

Pros

• Lowest barrier to entry so high users with high implied value
• Little platform administration

Cons

• Little visibility actual value generated
• Data/security risks
• High orphaned rate
• Low skilled solution as developer often have minimal dev time

Orphaned are flows/apps that have no real owner as they have either left or switched teams with no handover

2. Staged

The staged approach looks at business criticality and then positions the solution sliding governance process.

• Low user low criticality - Default environment (Personal)
• Medium user low criticality - Team environment (Teams)
• High user or Medium+ criticality - Managed environments (Enterprise)

Personal
Owned and maintained by the user (very much like Full Citizen Developer), only with limited DLP and sharing limits.

Teams
Approved business teams own their own environment each with its own DLP policy. Still owned and maintained by a user but with a process to share/switch owners

Enterprise
Developed by the business but supported by IT, Dev/Test/Prod environments, security, architecture & security review, enforced with seperation of duty through Service Account ownership and change management.

Pros

• Lowest barrier to entry so high users with high implied value
• Majority owned by business so low platform administration
• Focused dev teams generate skilled developer
• IT governance for high risk solutions
• Developer knowledge of solution/requirements

Cons

• Little visibility actual value generated
• Data/security risks as policy focus on criticality not security

3. Business Managed

Business owned environments but follow IT governance. Environments follow Dev/Test/Prod, security, architecture review and change management. Teams are responsible for administering their environments and work with central team for DLP updates.

Pros

• Majority owned by business so low platform administration
• Focused dev teams generate skilled developer
• IT governance for all solutions
• Zero orphan rate
• Developer knowledge of solution/requirements

Cons

• Minimum visibility actual value generated
• Barrier to entry as business need to be upskilled to IT standards
• Teams have to replicate functionality (platform support, architects, user admin, etc)

4. IT Integration Tool

IT treats the platform like any other IT software. Enforcing IT governance on all aspects. Development only to be completed by certified developers in the IT team. Deliveries prioritised by ROI (Return On Investment) and delivered for all of the business.

Pros

• Professional dev teams generating high value/quality solutions
• Improved productivity through certified developers
• IT governance for all solutions
• Zero orphan rate
• Accurate platform metrics

Cons

• Barrier to entry as business need to be upskilled to IT standards
• No developer knowledge of solution/requirements
• Consolidated backlog limits low value solutions

As you can see there is no right strategy, they all have their pros and cons, and right for certain organisations.

Additionally the models are not rigid, and can be mix and matched, with many shades of grey.

The key is to ensure your model aligns with your strategy, and you understand the practical impacts of the model.