One Thousand Workloads: How your Roadmap maximizes Power Platform investment
This is the second in a series of essays featuring new and deeper best practices added to the Power Platform Adoption Framework. The first can be found at Power Platform in a Modern Data Platform Architecture. The content below has been incorporated into the Adoption Framework at this link. Special thanks to Emily Cartner and Lucy Bourne with whom I have tirelessly collaborated on these concepts, and to Aaron Rendell (who is a great leader in this technical community) for his suggestion that the framework include a deeper dive into road mapping.
I often tell people that “I am not concerned with one app. I’m interested in getting a thousand workloads running on Power Platform.” That’s how we achieve real value—how we maximize return on investment—in the cloud.
The workload Roadmap is an indispensable part of an organization's ongoing Power Platform adoption. This roadmap provides a prioritized backlog of workloads that are candidates for migration to or new solution builds on the platform. It allows the organization to project the technology's business value over time, and is the core driver of return on investment (ROI) in the platform.
Why is the roadmap so important?
To understand this, consider a notional organization of 10,000 employees who use various software applications on a regular basis. That organization might choose to meet its needs with any mix of technology solutions that might incur license costs via commercial off the shelf, consumption costs via cloud infrastructure (e.g. Microsoft Azure or AWS), significant IT operations costs to on-premise infrastructure, or the cost of licensing Power Platform services. Now let's say that this organization decides to modernize an application or meet an entirely new business need using Power Platform, so it invests in the cost of per user licenses for each of its 10,000 employees. The marginal cost per app per user is fairly high in this scenario, but that marginal cost does not account for the new economic paradigm introduced in a low code application platform (LCAP) scenario such as Power Platform. In making its initial license investment, that organization has pre-secured the capacity needed to migrate or build potentially thousands more applications on the platform. Whereas the marginal cost per future application per user in a traditional cloud scenario would have further driven up consumption costs, with Power Platform the marginal cost for application number two and beyond has become zero. The license cost could conversely be spread across all apps, but in either case, app number two onward decreases in marginal cost and increases overall return on investment.
The roadmap is therefor pivotal in ensuring that there is a flow of workloads inbound to Power Platform, and that the organization is focusing its development resources on the workloads that will provide the highest value once deployed. In short, a healthy roadmap allows the organization to:
Continuously decrease marginal costs per app whilst continually increasing overall return on investment
Provide a trajectory of anticipated usage so that license acquisition can be tapered up over time (i.e. don’t pay until you need)
Achieve quick wins to justify early investment, transitioning to big wins that justify long-term investment
Focus development resources on the most valuable workloads
Avoid costly development quagmires by de-prioritizing the least valuable workloads
We must therefore work directly with business owners, users, and IT to identify, prioritize, and categorize candidate workloads and to create a roadmap for building those workloads on the platform. These candidate workloads should be prioritized and re-prioritized on an ongoing basis so that our Build Track activities remain focused on the most important next steps.
What’s the high-level process?
This ongoing process consists of three primary activities:
Identify candidate workloads to determine what we might build on the platform
Prioritize our identified workloads to determine the order in which we should build
Categorize our prioritized workloads by criticality to determine:
Who (citizen developers or full-time developers) should build the solution
Enterprise management considerations such as to which environment the workload should be deployed and the extent to which ALM should be used
Workloads are then added to the organizations Power Platform adoption roadmap, which is in essence the high-level backlog of solutions to be built on the platform. Whoever is responsible for the "Road Mapping" dimension--ideally your Power Platform Center of Excellence (CoE)--should then be responsible for managing and continually re-prioritizing the roadmap in collaboration with business stakeholders / workload owners as business needs change over time. This re-prioritization may lead to workloads being dropped from the roadmap as they become either obsolete or as it is determined that they may be better suited for technologies other than Power Platform.
The extent to which this ongoing roadmap management occurs will determine the maturity (e.g. unaware, disarray, reactive, strategic, evolutionary) of the organization in the "Road Mapping" dimension.
Who participates in the process?
Let’s identify the typical participants in the road mapping activities before going further. They include:
Executive Sponsor(s) who are the leaders in the organization possessing the authority, budget, and imperative to drive forward Power Platform adoption broadly and / or building solutions to address specific business needs. These sponsors may or may not be involved in the step-by-step road mapping activities, but in many cases will provide the organizational blessing or direction for specific workloads on the road map to go forward being built on the platform.
Business Stakeholders who possess expertise in or responsibility for solving the business challenges related to the workloads included on the roadmap. These stakeholders possess the knowledge needed to identify, prioritize, and categorize workloads. They should therefore be involved at all steps of the process, and should later work collaboratively with the development teams responsible for building the future solution.
Platform Owner, ideally including your Power Platform CoE if you’ve (yet) established one, in order to continually understand the business needs driving workload identification, and to provide context and guidance around prioritization and categorization.
Partner and Microsoft personnel will often be involved in these activities as facilitators, subject matter experts, or as direct service providers. For example, many large enterprise organizations choose to have their chosen Microsoft partner consultancy support their roadmap specifically, their Power Platform adoption or Center of Excellence more broadly. This approach is useful as the partner and Microsoft personnel are able to provide technical and industry expertise (and often tools) to support the organization’s roadmap.
Which activities should be undertaken?
The ongoing roadmap process consists of three primary activities including workload identification, prioritization, and categorization as discussed below.
Identify
Business stakeholders identify workloads as candidates for building on Power Platform. These stakeholders come from all areas of the business and include those performing the organization's purpose as well as those supporting the organization's purpose (e.g. human resources, finance, supply chain, etc.). IT personnel may also identify candidate workloads such as those that enable their own work or based on their knowledge of legacy systems slated for end-of-life. Workloads may also be identified as part of actions or prioritized initiated by executive sponsors.
In general, though, the following are considered to be ideal workloads for Power Platform.
Meeting new business needs by quickly building new solutions to emerging yet often complex business challenges, needs, and use cases with low code application platform tools. Think of these workloads as solutions to challenges that until recently you didn't know you had, but now have taken on a sense of new importance.
Re-imagining existing applications or business activities, in other words taking out-of-date applications or ways of doing things and modernizing them as mobile and web apps, automating business processes, and infusing these solutions with chatbots, data intelligence and visualization, artificial intelligence and predictive analytics, and modern data source(s).
Sunsetting legacy technologies is similar to re-imagination described above, but driven by the upcoming retirement and thus the need to migrate away from from technologies approaching end-of-life such as InfoPath, classic SharePoint workflows and apps, Access, Lotus Notes, legacy CRM and ERP, on-premise data centers, etc.
Citizen developer productivity applications that serve more localized or niche use cases involving individuals, small teams, or less complex business functions. These are the areas where development of custom applications would have previously been cost prohibitive, but where low-code tools allow business users to develop lower complexity apps to meet their own needs.
Prioritize
Most enterprise organizations will in time be able to identify thousands of candidate workloads as they expand the reach of Power Platform to include more business groups. It is therefor important to prioritize these workloads for building on the platform given limitations on development (even citizen development) and maintenance resources. Solution development on Power Platform has been validated by independent research to be 74% faster than traditional software development, but resources are nonetheless finite.
The goal here is not to establish an absolute and sequentially ranked order for migration, but rather to consider which workloads are highest priority to migrate to Power Platform based on two high-level considerations:
Business Value is a stakeholder-driven assessment of how impactful that workload is to the organization, its alignment with business goals, its importance in mitigating organizational risk, and any number of industry-specific measures through which business value might be measured.
Complexity of the workload considers the complexity of the business activities in question, their current technology solution (if any), and the stakeholders or collection of stakeholders involved.
Taken together, a Low-Moderate-High assessment of both business value and complexity will prioritize each workload into one of four "buckets":
Big Wins that, though more complex (and likely more time consuming or expensive to build) will provide the highest value
Quick Wins that are still moderate to higher value but whose lower complexity make them quicker or cheaper to build
Nice to Haves that are neither difficult to build nor as valuable to the business overall so should therefor be de-prioritized or potentially built by citizen developers at lower cost to create and manage long-term
Wastes of Time whose higher complexity will cost valuable time and financial resources without providing significant value
The diagram below illustrates this concept.
This workload prioritization matrix in the Power Platform Adoption Framework helps to visualize the workload roadmap and focus resources on development efforts that offer the greatest value.
Many organizations find that first taking on workloads classified as "Quick Wins" allows them to rapidly prove the platform's value early in their adoption. This aligns with the "get to value quickly" concept espoused in the Quick Start and throughout the Power Platform Adoption Framework. Purposefully moving up the value scale into the "Big Win" quadrant maximizes return on investment and should thus be done soon as feasible.
Finally, it is important to note that some workloads will simply be urgent, regardless of their priority in the matrix above. Urgency may be derived from top-down organizational direction, the need to evacuate a data center, or by some other external factor. This urgency may even be assigned to "Waste of Time" or "Nice to Have" workloads.
Categorize
The final activity in the road mapping cycle is to categorize the identified and prioritized workloads and align them to the criticality scale in our Environmental Architecture Model discussed as part of the "Environments" dimension (reference that section of the Adoption Framework for criteria used to define the productivity, important, and critical workloads discussed below). This is a critical step to situating the workload in our enterprise management and governance model, as well as to determining if the workload is best built out and supported by citizen developers or by full-time Power Platform developers. This decision will among other things impact cost and development cycle time.
Here we are categorizing or triaging the workload into one of three categories:
Obsolete workloads that are no longer in use, will not be built on the platform, and will therefor be deprecated. Set these aside.
Productivity workloads are generally used by a team or business group. Turn these over to your citizen developer users, and provide them training for do-it-yourself development.
Important or Critical workloads are tied to critical business functions or in widespread use. They'll be built out by full-time Power Platform developers as part of our partner consultancy or internal software development teams.
Business Value Assessment
Many organizations will want to conduct a business value assessment (BVA) to make a business case based on specific goals and expected outcomes of their Power Platform adoption generally and their development efforts for important and critical workloads specifically. Such assessments allow mature organizations to determine and make sound financial choices around considerations such as return on investment (ROI), net present value (NPV), and other industry-specific factors.
The variation of business cases amongst different industries and pre-existing best practices for business value assessment make it impractical to address these activities within the Adoption Framework. However, organizations that choose to invest in BVA will most often do so as part of their roadmapping, and the activities outlined in this section above will provide valuable input to those assessments.
