Chapter 7: Power Platform Fit Gap Analysis
Fit gap analysis is a process that identifies where gaps exist between business or operational requirements and the system capabilities. In this chapter, you will learn how to perform a practical fit gap analysis for our case study at Inveriance Corps. You will learn how to align Power Platform capabilities, Dynamics 365, Microsoft 365, and Azure components to organizational requirements. We will also consider AppSource apps and third-party solutions for inclusion.
Power Platform licensing and API limits will be considered during the assessment process. The usage of Proof of Concepts (POCs) will be discussed as a means of validating a solution’s ability to solve specific requirements. Having identified the optimal solution, you will then learn how to determine the overall scope for the solution, setting the right expectations upfront.
In this chapter, we’re going to cover the following main topics:
- Introduction to Power Platform fit gap analysis
- Deep-diving into feasibility analysis
- Best fit analysis deep-dive – aligning Microsoft product capabilities
- Evaluating AppSource, third-party, and custom solutions to meet functional gaps
- Validating solutions through POC implementations
- Determining the overall scope for the solution and setting the right expectations
Fit gap analysis is an integral part of the application life cycle as it provides clarity on the areas of the implementation that will require additional effort to complete. It also highlights the processes that require support from components outside the core Power Platform capabilities.
Introduction to Power Platform fit gap analysis
One key benefit of fit gap analysis is that it is easy to implement, and the results help identify actions needed to address gaps in product capabilities. You will have a better understanding of the effort required to fulfill the business requirements and make informed decisions on the solution that best fits the organizational needs. Based on your findings, you may also propose changes to these requirements. The net result from the fit gap analysis is to maximize the organization’s Power Platform investment by aligning the implementation with the native product capabilities.
While performing fit gap analysis on a Power Platform implementation, you will balance the need to fulfill a requirement with the implementation cost and the impact on delivery timescales. The decision triangle in Figure 7.1 illustrates the decision process. As the scope increases, the costs to implement a requirement and project schedule change accordingly:
Figure 7.1 – Fit gap analysis decision triangle
You will learn how to match requirements against Microsoft product capabilities, assess whether they are technically feasible, and identify compliance considerations that may impact implementation.
Applying the Pillars for Great Architecture – Balancing Decisions
Running a fit gap analysis on an organization’s requirements will provide you with the knowledge to make an informed decision during product selection, configuration, and development cost estimates. You will then be in the unique position of being able to propose a solution that balances all these factors to achieve the best outcome for the organization.
Power Platform fit gap analysis essentials
Fit gap analysis can be carried out with a simple Excel document and within Azure DevOps user stories or tasks. Whichever tool you use to perform your analysis, you will want to use a consistent set of fit gap qualification criteria.
Power Platform implementations have their own considerations when performing a fit gap analysis. As a minimum, you will want to identify the following for each requirement.
Severity of gap
Identifying severity gaps is a crucial part of the fit gap analysis. The severity gap recognizes whether a requirement can be fulfilled using standard product capabilities (Fit) or whether there is a gap in the Power Platform product capabilities that will require some level of effort to deliver the requirement.
Some projects use the Partial Gap, Full Gap, and No Gap categories. Solution architects adjust the terminology used depending on specific project needs. Consistency in the gap categories is key. The following screenshot shows a requirement being categorized with gap severities tailored to a typical Power Platform implementation.
Figure 7.2 – Categorizing the severity of a gap in a Power Platform requirement
The proposed gap categories indicate the level of effort and the implementation route required to fill that gap. A description for each of the proposed gap categories follows:
- FIT – The requirement can be fully implemented with the Power Platform components using little or no configuration.
- CONFIGURED – The requirement can be implemented by configuring Power Platform components (for example, the creation of tables, forms, and flows for business process automation). The gap can therefore easily be fulfilled without the need for custom development or components outside the Power Platform framework.
- DEVELOPED – The requirement is beyond the capabilities available through standard Power Platform configuration and would require the development of a custom component. This will typically involve the development of a Dataverse plugin or workflow using .NET code, PCF controls, or Power Apps Portal custom JavaScript code.
- DYNAMICS – The requirement is recognized as being a general feature of a Dynamics 365 application. Implementing the functionality using base Power Platform components is not considered a cost-effective endeavor. Once there are enough requirements that match the capabilities provided by Dynamics 365 applications, it is a good indication the project would benefit from using Dynamics 365 as a base platform for the solution.
Matching requirements to Dynamics 365 applications and industry accelerators is discussed in more detail in the following sections.
- APP SOURCE – The requirement does not match the functionality available in Power Platform or Dynamics 365, and custom development is not considered the best option due to the complexity of the functionality, a development skills gap in the team, or ongoing support considerations for a custom solution. Matching requirements to third-party solutions is discussed in more detail in the sections that follow.
The effort required to close the gap
Having identified a gap in the standard product capabilities, you can then proceed to quantify the effort required to fill that gap. Depending on the ways of working used by the project, you may carry out these high-level estimates using t-shirt sizes, agile story points, or other means of estimating effort.
All these approaches will give you an indication of the effort required. Using the same approach consistently within a project makes sure that the estimation method provides a real indication of the effort required, which can then in turn be used during decision making and planning.
The following screenshot illustrates the use of this book’s fit gap analysis template to estimate the implementation effort for a requirement using t-shirt sizes.
Figure 7.3 – Sizing effort during fit gap analysis
Sizing requirements may be part of a team exercise with functional consultants and developers. It is often beneficial to include team members involved in implementing a requirement during the sizing exercise. It will give you insights into technical areas that may have otherwise been overlooked. You can then make necessary adjustments and size the requirements according to the implementing team’s level of expertise and skillsets.
Priority
During the requirement capture sessions, you may have identified priorities for the various requirements. A fit gap analysis session is an opportunity to review or complete the prioritization of requirements. Requirements may be prioritized in several ways, including using low/medium/high priorities and numeric priorities ranging from 1 to 10.
The following screenshot shows how this book’s fit gap analysis template is used to prioritize a requirement:
Figure 7.4 – Requirement prioritization during fit gap analysis
Requirement prioritization helps guide the decision-making process. You might consider descoping low-priority requirements with a high implementation effort, requiring custom development, or requiring third-party solutions. In this scenario, the implementation effort and ongoing support overheads may outweigh the benefit a requirement brings to the organization.
Feasibility
During the requirement capture sessions, you will have gained an understanding of whether it is feasible to implement a requirement. During the fit gap analysis, you will re-assess the feasibility of the requirement to identify technical or compliance risks to the implementation.
Requirement feasibility may be recorded in several ways. The following screenshot shows a requirement’s feasibility being recorded using this book’s fit gap analysis template.
Figure 7.5 – Feasibility assessment as part of the fit gap analysis
Feasibility assessments are discussed in more detail in the upcoming fit gap analysis deep-dive sections.
Best fit
This optional step allows you to record the Power Platform component that is best suited to implement a specific requirement. While not necessary, this categorization will provide you and the reader of the fit gap analysis report with an indication of how the requirement could be implemented. This categorization also provides some context as to the sizing and feasibility assessments for the requirement.
It is useful to provide a list of the most used components within Power Platform and any related applications. You would look to adjust the component list to suit your practice’s areas of interest if necessary. The following screenshot shows a requirement being categorized as well suited to be implemented as Power Apps Portals using this book’s fit gap analysis template.
Figure 7.6 – Identifying components that best fit a requirement during fit gap analysis
Some features may require multiple components to be fully implemented. In such scenarios, you would consider identifying the main component to be used and include the additional details in a notes section.
Identifying the components that are best suited to fulfill a requirement will provide the build team members and stakeholders with a concise list of components. This list can then be used for licensing considerations and as an architectural stocktake of the proposed solution.
Notes
A general notes section for each requirement allows you to record additional details or context that may not be otherwise obvious. Notes allow you to record recommended implementation strategies, feasibility considerations, reasons why a requirement cannot be implemented, and references to alternative components that could be used to fulfill a requirement gap.
Figure 7.7 – Fit gap analysis notes
Notes become an invaluable resource for context, allowing the reader to catch up on the train of thought and constraints that were considered when the fit gap analysis took place.
Fit gap analysis outcome
The completion of a fit gap analysis will result in a report listing the gaps identified for each requirement in the solution and will flag up any feasibility concerns that may have otherwise put a spanner in the works of an otherwise successful implementation. The following screenshot illustrates an example section for a Power Platform fit gap analysis report that uses the templates used in this book.
Figure 7.8 – Example fit gap analysis output in Azure DevOps
Excel is also an excellent tool for fit gap analysis, and the resulting worksheet may also be imported into Azure DevOps at a later stage.
Figure 7.9 – Example fit gap analysis output in Excel
The following sections deep-dive into the considerations you will need to go through to perform an effective Power Platform fit gap analysis.
Deep-diving into feasibility analysis
One of the key benefits of Power Platform fit gap analysis is being able to identify whether it is feasible to implement the requested features and requirements. As part of the feasibility analysis, you will identify technical limitations or regulatory restrictions. At the same time, you will assess the requirements to identify superfluous or outdated processes that may result in that part of the solution not being used when in production.
We will now work through each of the feasibility considerations one by one.
Will a feature be used?
When reviewing requirements, you will seek to understand whether features will be used when the Power Platform solution is in production. By understanding the need behind a requirement and having oversight of the Power Platform product roadmap and also the organization’s plans for the system, you will be in a position to flag up features that may not be required in the long term.
An example could be a requirement that relies solely on a feature soon to be deprecated or a feature that supports a business process that is due to be changed before or shortly after the requirement is put into production.
Identifying features that could potentially fall into the unused pile means you can propose an alternative or simply propose to descope the requirement, thus freeing up resources for other areas of the implementation. Flagging these potentially used features in your fit gap analysis report accordingly will facilitate such discussions with stakeholders.
Is it technically possible to implement a feature?
It is vitally important to identify and flag up requirements and features that may pose technical challenges or implementation hurdles. The earlier these roadblocks are found, the sooner you will be able to mitigate their impact on the project. Furthermore, there will be times when some requirements will simply not be technically feasible with the available product capabilities or time/resource constraints.
During the fit gap analysis, you will use a wide range of technical expertise, combining the following:
- Your knowledge of Power Platform capabilities
- Your implementation team’s experience
- The wider Power Platform community
- Microsoft’s support framework
Utilizing this pool of knowledge, you will be in a position to categorize a requirement or feature as feasible or otherwise.
At times when an answer is not readily available, you would look to carry out a spike into the feature in question. Performing a limited internal POC or testing the product capabilities to gain confidence that a particular component or implementation strategy will fulfill the requirement.
Having completed this exercise, you will then be in a position to categorize the technical feasibility of a requirement.
Are there any processes that have been overlooked?
It is sometimes possible to overlook a business process during the requirement capture and engineering stages. It may not be a process that has been previously identified by the organization but may nonetheless play a part in the Power Platform solution.
While reviewing multiple requirements for feasibility, you may find that, when combined, the individual requirements make up a distinct business process. At that point, you can flag this up and update the business process models accordingly.
Are there any regulatory compliance issues?
Business applications are often subject to regulatory and compliance requirements. Organizations themselves may have internal policies for the processing of personal data. Your role as a solution architect is to work with the organization’s teams, with compliance and law experts within the organization, and liaise with external compliance advisors and regulatory bodies where necessary.
The following are some examples of regulatory and compliance constraints that may be imposed on a Power Platform implementation.
- Data retention policies: How long should data of different types be stored and/or processed?
- Privacy policies: Dictating who can see certain types of data (for example, personal data), and how the data can be accessed.
- Regulatory requirements: This may be in the form of industry-specific laws or regulatory requirements (for example, the organization may be required to store customer records for x number of years, except when the prospect does not become a customer, requiring the deletion of their data within x days).
Working with business analysts and compliance experts within the organization, you will seek to identify these mandated requirements and work with the team to retrospectively incorporate these compliance features if necessary. Finally, you will flag up in the fit gap analysis report the feature that cannot be implemented due to regulatory restrictions and propose alternatives that comply, or arrange to descope the requirement altogether.
Feasibility analysis outcome
The following screenshot illustrates a requirement being classified as having a compliance issue using this book’s fit gap analysis template.
Figure 7.10 – Example feasibility analysis
Having completed a feasibility analysis, you will have a clear picture of the requirements that can be implemented, the ones that are constrained by technical or regulatory limitations, and the ones that should not be implemented as they will not be used in a production environment. You are now in a position to make the necessary recommendations to address any feasibility gaps.
Deep-diving into best fit analysis – matching Microsoft product capabilities
The earlier sections in this chapter discussed the basics of matching up requirements to Power Platform capabilities and the wider Microsoft ecosystem. As a solution architect, you will look to have an understanding of the Power Platform feature sets and the applications and extensions that co-exist within the Dataverse framework.
When matching up a requirement to a product, you will also have a view of the components product roadmap and the organization’s long-term plans for the use of the system. You can then select the Power Platform component that best suits the technical requirement and these long-term considerations.
Matching requirements to Power Platform components
As a Power Platform solution architect, you will seek to identify the Power Platform components that are best suited to fulfill a requirement. Through your knowledge of the platform’s capabilities, you would look at mapping requirements to the following components:
- Model-driven apps
- Power Apps Portals
- Canvas apps
- Power Automate
- AI Builder
- Power Virtual Agents
- Power BI
- Dataverse
Power Platform provides a highly flexible framework for creating business applications and lends itself to being tailored to particular users’ needs. A Power Platform solution is not fixed in scope once applied and can evolve.
Matching requirements to Dynamics 365
Organizational requirements may sometimes steer the implementation toward the realm of Dynamics 365 applications. Knowing the capabilities of each application will help you identify opportunities for expediting the implementation of a business application by leveraging Dynamics 365.
The following applications either share or leverage the same Dataverse framework as standard Power Apps and should be considered for inclusion during your fit gap analysis.
Table 7.1 – Third-party solution review checklist
It is important to note that moving from a Power Apps application to Dynamics 365 would require a migration, as there is currently no standard method of converting a Power Platform application into a Dynamics 365 instance. Therefore, the decision to use or not use Dynamics 365 applications as a starting point should carefully consider the current and future organizational requirements. Conversely, if the organization’s requirements leverage a small percentage of the features provided by a Dynamics 365 application, you could then consider using Power Platform applications to build the customer’s requirements.
Further Reading
Please go to https://docs.microsoft.com/dynamics365/ for full product documentation on all Dynamics 365 applications.
Matching requirements to industry accelerators
Microsoft, Adobe, and SAP have worked together to create what is known as a Common Data Model, a common language used by industries across the globe to structure data and processes, providing solution providers with pre-built Power Platform and Dynamics 365 applications tailored for specific industry verticals.
Microsoft’s offering currently focuses on the following industries:
- Automotive
- Education, including higher education and K–12
- Healthcare
- Media and entertainment
- Nonprofit
- Telecommunications
As you perform your fit gap analysis, you will assess the organization’s requirements industry sectors. You may identify opportunities to leverage the industry accelerators to expedite the Power Platform implementation.
Further Reading
Please go to https://docs.microsoft.com/dynamics365/industry/accelerators/overview/ for detailed information on Microsoft’s industry accelerators for Power Platform and Dynamics 365.
Best fit analysis deep-dive – matching AppSource, third-party product capabilities
Microsoft AppSource provides extensions to the standard Power Platform and Dynamics 365 product capabilities. As part of the discovery phase, you will make use of this resource to fill any gaps in Microsoft solution’s feature sets.
AppSource components are available for review at https://appsource.microsoft.com/.
The proposed rationale behind using an AppSource and third-party component to fulfill organizational requirements is as follows:
- The standard Power Platform functionality does not fulfill a requirement.
- It is not possible to adapt the requirement to match the Power Platform feature set.
- One or more AppSource components exist that fulfill the requirement.
- The AppSource components have been trialed in a POC, demonstrated, and rated internally to confirm their fitness for purpose.
- The vendor has been identified as a company of sufficient repute to satisfy organizational procurement requirements.
- The vendor has confirmed support for future updates of Power Platform.
- The licensing and maintenance costs are aligned with the project’s budget.
- The cost/timescales for developing a custom solution to fulfill the requirement are too large, making the AppSource solution a better option.
Following the preceding assessment steps, you will then be in a position to make the most informed decision, selecting the component that best fulfills the project’s needs, even if it means developing a custom solution in-house when suitable AppSource or third-party components are not available.
A Pillar for Great Architecture – Build and Operation Efficiency
The decision to use an AppSource component will often have an impact on the overall project implementation time and the ongoing operational efficiency of the production environment. To that end, you will review AppSource solutions to ensure they deliver these benefits. You will quantify the expected build time gains, ongoing costs, and support prospects for AppSource solutions by trialing these components, communicating with the vendor’s sales and support channels to ensure the component meets the overall needs of the organization.
You will now work through a typical AppSource component use case scenario.
Case study – matching Inveriance Corp’s requirements to AppSource components
Inveriance Corps has stated a requirement for their customer onboarding portal. The requirement is as follows:
As part of the third-party assessment process, we proceed to review the solution. The following table lists each of the review steps and the outcome of the review for this particular requirement.
Table 7.2 – Third-party solution review checklist
The outcome of the review process identifies a component titled “Power Co-browse” as the best solution for fulfilling the customer’s requirement. The procurement process for the AppSource solution is initiated for inclusion in the build.
Validating solutions through POCs
As you are working through a fit gap analysis, you may find instances where it would be beneficial to implement a POC for a specific area of the solution. You would look to create a POC to achieve one of the following:
- Provide early hands-on access to users, allowing them to try out potential solutions for themselves and confirm a requirement is met.
- Present Power Platform’s out-of-the-box capabilities to users to validate that their features solve a specific problem.
- Test whether an implementation strategy is a viable solution for fulfilling a requirement.
- Validate that a third-party component is suitable for incorporation as part of a Power Platform implementation.
- Validate whether integrations or complex feature sets are required, or whether they could be simplified.
POCs provide early glimpses of what the final system might look like, allowing you to validate solutions as a low-risk exercise.
Summary
In this chapter, you have learned how to perform effective Power Platform fit gap analysis. With this knowledge, you can now assess an organization’s requirements and make the most informed implementation decisions and recommendations to steer the project to a successful outcome.
In the next chapter, you will deep-dive into the Power Platform design process and explore detailed solution architecture blueprints, component re-use patterns, data migration, and test strategies.