powerplatformaf / powerplatformaf

Power Platform Adoption Framework

Power Platform Adoption Framework

Welcome!

We continue to open up the evolution of Power Platform Adoption Framework to input and ideas from around the global Power Platform community. This idea has been one of our primary revelations as we've thought about the framework’s future.

So that’s why ongoing development of the Power Platform Adoption Framework is now happening on Github. Developers everywhere use Github to create software, and now we’re going to use Github to further build the framework that enables people to create beautiful and useful things on Power Platform deployed in large, enterprise-grade organizations.

We hope you’ll join is one of a several ways. PowerPlatformAF on Github (https://github.com/PowerPlatformAF/PowerPlatformAF) is the place where we’re inviting members of our community to:

1. Submit ideas, recommendations, issues, and other input for discussion and possible inclusion in ongoing updates to the framework

2. Join those discussions through comment and reacting to submitted ideas so that we can determine what (and in what form) additions to the framework need to be made

3. Have always-up-to-date access to the latest version of the framework now posted on the wiki

Keep in mind that the wiki will always be a draft work-in-progress. Everyone can now share and use the latest ideas coming out of the community here. Periodically (thinking every six months or so) we’ll give it a good scrub and turn it into the next official edition white paper.

We hope that you will join, share, collaborate, and help drive large-scale adoption of Microsoft Power Platform with us!

What is Power Platform Adoption Framework?

The Power Platform Adoption Framework is the start-to-finish approach for adopting the platform at scale. It has become the global community standard for adoption, buildout, road mapping, enterprise management and governance of Power Platform at scale within enterprise-grade organizations.

The framework is supported and driven by its original creator (Andrew Welch) and publisher Applied Information Sciences (AIS) -- Microsoft Partner -- and contributed to by Power Platform experts and citizen developers around the world (Manuela Pichler, Keith Whatling, Lee Baker, and Lucy Bourne are some major luminaries on this topic - follow them!). AIS is fully behind the framework, sharing it with the community, and committed to its future development as best practices for enterprise adoption evolve. We’re sharing it so that everyone can use it, because we believe that a vibrant and thriving community around this technology is good for everyone who uses it.

More at www.RunwayView.com.

powerplatformaf's Issues

Strategy for templates and re-usable applications in Teams environments

Update all language to to replace "CDS" with "Dataverse"

Use "Dataflex Pro", "Dataflex for Teams", and when referring to both together "..." (@KeithWhatling will check with Microsoft).

Integration with Microsoft cloud adoption documentation

New forward re-contextualizes the Framework in the broader ecosystem

Broadly applicable best practices for adoption at scale. Not a technical manual.

Example:

• Framework: You must test.
• Playbook: This is how you test in a given context.

Example of big enterprise bank vs a SMB. Context is important, which is why we're not being technically prescriptive here.

Some adoptions feature a significant "citizen developer" emphasis, some do not. This is about the ability to adopt at scale either way.

Concepts:

• Open to the community
• "Don't turn it off. Here's how to start and manage growth + what's next."
• Throwing good money after bad... this is a commitment you need to make
• 1st Class Citizen / App modernization / Journey

Update the project lifecycle diagrams to reflect “Quick Start” instead of “Discovery”

Identify which components of the COE Toolkit are most directly connected to Track 3: Enterprise Management

Identify specific components.

Also:

• Admin & Governance
• Operations
• Nurture
• Support

Update the Environmental Architecture Model to include Dataverse for Teams environments

The EAM will need to be updated to include guidance on how Dataflex for Teams fits into the ecosystem. Including:

• Why would we choose to use Dataflex for Teams vs Dataflex vs SharePoint vs Azure SQL (e.g. SharePoint offers higher capacity but minimal relational qualities... So if workload is high capacity + low data service sophistication, then SharePoint; if workload is lower capacity + high data service sophistication, then Dataflex for Teams... if high-high, then Dataflex Pro or Azure SQL.)

• Describe what we mean by "data service sophistication", e.g. relational qualities, security controls, business process management, automation and calculation, etc.

• Consider a quad chart or some additional diagram to help contextualize this. Possibly a quad chart that uses two axes + bubble size to show data sources in terms of capacity, data service sophistication, and ability to utilize features in Power Platform. For example, SharePoint does not permit the use of portals or model-driven apps.

• Insert a "Teams Environments" tier between business group and localized productivity, with Productivity and non-ALM Important workload criticality

• Insert Dataflex for Teams into the data storage best practice

• Consider a more detailed diagram for each tier, so that the primary diagram does not become unreadable

• Address the application lifecycle between Dataflex for Teams and Dataflex Pro; what's the glide path?

Updated diagrams showing where all Power Platform components fit in the larger tech ecosystem

Thinking three layers here:

• Data Layer (e.g. Dataflex Pro, Dataflex for Teams, Azure SQL, data connectors); expand on the capabilities specifically available in Dataflex Pro

• Extensibility Layer (Power Apps, Power BI, Power Virtual Agents, Power Automate)

• Product Layer (e.g. M365, Azure, Dynamics 365, third party applications)

...Add narrative explanation explaining the diagram(s).

Identifying what personas should be on the COE, and what the level of time involvement they will need

Grading of PowerApps developers

I was looking at a standardised way of determining what skill level a powerapps maker was at and stumbled across Sfia (Sophia).

It's a recognised framework and part of it was determining skills, it was quite simple and easy to apply so that non-IT people could take it onboard.

https://www.sfia-online.org/en

1. basic skills, needs one on one support to build X
2. partly skilled, can work alone and requires remote support
3. can work autonomously, work checked by X person
4. can help people at level 1 and 2, recognised as an expert
5. has accredited certification in X and is the person that reviews work for all levels.

Management of users within a Microsoft Team, consuming Dataflex for Teams Applications.

The use of Dynamic Group Membership will play an important part going forward for Power App solutions within Teams. Consideration, planning and governance needs to be considered on how best this is managed.

Best practices for getting started with COE Starter Kit

Emphasize also that this is a "Starter Kit", it is not the ultimate answer. Begin with the Starter Kit and go from there. So, guidance on customizing the starter kit (or at least a call out that this needs to happen, and directing you to the MSFT resources).

• Provide guidance on how the overall adoption into SK components.
• The Admin App is agnostic of data source upon which its catalog apps sit, but it itself is built on CDS
• Discussion of how to use key COE Toolkit components to support Track 3: Enterprise Management

Update the "Nurturing the Community" section

Solicit community input as to what the latest best practices are for:

• Supporting IT
• Supporting Business
• Supporting the Community

https://github.com/PowerPlatformAF/PowerPlatformAF/wiki/7-Nurturing-the-Community

Narrative discussion for relationship of Power Platform in the larger Microsoft stack

Migration path for moving from Dataverse for Teams up to Dataverse (environment and solution)

Content updates to de-emphasize “Discovery” in favor of “Quick Start”

Create narrative content describing how to use key COE Toolkit components to support Track 3: Enterprise Management

Migration path for getting into Dataverse for Teams

Track 1: “App Build” becomes “Build” in order to not be so Power Apps specific

What are we building?

• Apps
• BI Components
• Flows
• Bots
• AI Models
• PCF Components
• Teams Apps
• Integrations

Nomenclature updates of "User Support Measures" to be "User Empowerment"

Emphasize importance of the training in adoption plan

I see a brief mention of ABC in a Day training in the Quick Start and some mentions of training in the Nurturing the Community sections, but I think more emphasis could be made and perhaps explicit directions as to what types of skills are needed by whom (i.e. Citizen Developers should complete the .... learning path on Microsoft Learn). There are many ways to acquire these skills and not everyone learns the same way, but it's critical to emphasize that everyone needs to prepare to learn as part of the adoption, whether they are a citizen developer or an IT admin.

This may overlap with the CoE Starter Kit some, but again it's super important to build into any Power Platform adoption plan, this idea that the initial wave of employees you train will become your org's Power Platform subject matter experts (or champions) who deliver the training to the next generation of Power Platform users. Hopefully starting an endless cycle of training and learning that nurtures the community within your organization.

In short, a good adoption plan creates a Power Platform training program that sustains the growth within the organization for years to come.

Complete content for the entire "Application Lifecycle Management" pillar

Updated link to the content stub:

https://github.com/PowerPlatformAF/PowerPlatformAF/wiki/4c-Application-Lifecycle-Mgmt

Originally submitted item:

In organisations with no Azure DevOps knowledge, how do you implement and automate ALM? Even with DevOps skills, how do you abstract this layer from end users and makers?

User Empowerment > Citizen Developers

Excerpted quote from Twitter:

@BergmannBene of for sure, very much agree! If someone is (1) full-time software of any kind, and (2) has #PowerPlatform skills, they are absolutely a Power Platform developer.

What's the role and need for an Exec Sponsor for the Power Platform?

Successful enterprise adoptions have seemed to require an executive sponsor, but we want to define exactly why an Exec Sponsor is needed. What key decisions do they drive? What role do they play? We'd like to get to some sort of checklist as to what the exec sponsor should be doing.

"Citizen Developers" vs "Pro Developers" vs [Something Else?] needs to be clarified

Split-up Power Platform Developer Role

As the Power Platform grows towards maturity, several tasks which could be easily combined in earlier stages become much harder to combine nowadays. The way I see it 3 Power Platform roles are starting to emerge:

• Citizen Developers
• Power Platform Developers
• Power Platform Administrators

The more Power Platform Administration tools and features are being released, the harder it becomes for the ordinary Power Platform Developer to stay on top of both the "Maker" experiences and the administration side of things.

If we take into account the roadmap as unveiled by Charles Lamana at the POWERful Devs Conference, the release cycle of governance related tools and features will only accelerate in the coming months and years.

If we look at the Power Platform Certification Microsoft is also starting to acknowledge this trend. With the unveiling of the PL-100 Exam - which is focused on the Maker role- Microsoft is starting to recognize that there is a difference between Power Platform Developers and Power Platform Administrators.

Reference the Power BI Adoption Framework

To what extent do we reference the Power BI Adoption Framework as a component of the overall Power Platform adoption (when Power BI is a part of the picture)?

https://github.com/pbiaf/powerbiadoption

"Utility" applications in the Enterprise Architecture Model

Where do widely used, yet not profoundly complex applications fit into the EAM? We're thinking about applications that may not make it into the Teams feature backlog, but will be developed for very specific use cases and then widely deployed into DF for Teams.

Model for architecting environments at enterprise scale

Would be good if we had a model (or more likely several) that provides guidance as to how environments should be architected, arranged, integrated with one another in large organizations. Perhaps pose a few different scenarios and discuss the advantages and disadvantages of each?

Need to consider how Dynamics fits into this picture.

Define tiers of applications:

• Critical
• Important
• Productivity

Address adoption and governance best practices for Power BI

Reference the Power BI Adoption Framework.

To what extent do we reference the Power BI Adoption Framework as a component of the overall Power Platform adoption (when Power BI is a part of the picture)?

https://github.com/pbiaf/powerbiadoption

Update diagrams to replace "CDS" with "Dataverse"

Identify areas where a graphic or diagram would help better explain the concept

Quick Start - Envisioning stage

Is there scope to add an 'Envisioning' stage prior to identifying and building the first concept app?

I normally carry out several 'Envisioning' workshops which show the 'art of the possible' and highlights the capabilities in real-life scenarios before moving to a proof of concept / Proof of value, physical build phase. This helps to identify an appropriate business scenario for the quick start solution build.

Measure / ROI / Business Value Assessment

How do you measure the value of your Power Platform Adoption? What are key questions your users and makers should answer to identify the ROI? How can tracking this be automated? What are key impact areas?

Change Program Management Pillar to Platform Management

Dimensions become (not necessarily in this order):
Project Tooling
Backlog Management
Road Mapping
COE Starter Kit
COE Establishment

Layers of reusability

Define the different layers where "stuff" could be reused.

Examples:

1. Code
   1. Shared, copy/pasted
   2. Templates (boiler plates)
   3. Libraries (extensions, base classes, interfaces)
2. Solutions
   1. Feature solutions (horizontal)
   2. Industry specific (vertical)
3. Custom Connectors
4. PCF controls
5. Common child flows
6. Canvas
   1. Components
   2. Themes
7. Uniformity
   1. Code style rules
   2. PP Checker rulesets
   3. Report templates

Update / create new overall template for the “production ready” white paper

Explaining the value and suggested model of "internal" user groups

Guidance on when to use CDS vs SharePoint vs Azure Data Source

Proposing a model that assesses a workload's:

• Scope
• Impact
• Integration (with other apps / data / services)

...in order to provide guidance as to where the app should be built from a data source perspective.

Specific treatment to CDS and related best practices

Ideas:

• Describing CDS and its value
• Critical best practices
• Why don't some people use CDS?

Re-format final second edition white paper with more subtle branding

COE Starter Kit ≠ Center of Excellence

You need to secure the platform no matter what, even if you don't have a COE.

However, securing the platform / installing the "Starter Kit" does not mean that you've done what's necessary to actually adopt, manage, and govern the platform. COE Starter Kit ≠ Center of Excellence, and vice versa.

Diagram showing relationship of Power Platform in the larger Microsoft stack

Nomenclature updates of "Discovery" phase to be "Quick Start"

Best practices as to when / how to go COE, and where it should live organizationally

Office 365 Admin Team ≠ Power Platform COE

Create narrative content discussion the value of partners to the maturing of enterprise management and governance in scaled platform adoptions

Specifically address the importance of Teams in Power Platform adoption, enterprise management, and governance

Sections to update:

• Power Platform (introduction)

• Enterprise Management (address the CoE, PPAC, etc)

How to handle Time?

I think being a citizen dev tool there needs to be some consideration around the handling and explanation of Time. Time is a very tricky thing in computer terms and a proper method for employing it in Power Platform and getting makers to adhere to best practice around it is a tricky thing.

Yesterday means so many things depending on where you are and if you're looking at raw UTC time strings etc etc.

Different adoption approaches / drivers

Among them:

• Legacy D365
• Decentralized citizen developer focus
• In-house consultancy teams
• Partner
• Focus on adopting a platform / capability
• Focus on a specific workload / use case / requirement

Tracks Numbering

Currently, the tracks are numbers 1 - 3, where three is the base for the other two tenants of the platform. In reading the AF, it appears when you present build first, then road map, and finally enterprise management, you're suggesting that that is the order of importance. I would recommend either switching 1 & 3 (so that you start with EM), or removing the numbering entirely. If numbering is removed entirely, it still seems most logical that the PPAF addresses EM prior to the road map and build when addressing the three-pronged approach.

This way, you first present EM which feeds both the road map and build, then you head on to the road map, which feeds into the build. It presents a clearer order of what makes sense for adoption and increases the apparent importance of enterprise management.