Identify potential third-party components


During a project, you might realize that the app you are working with isn't capable of meeting a requirement. At that point, you have three choices:

  • Custom-build a new app

  • Look for a third-party solution

  • Work with the customer to remove the need from the requirements

Whenever possible, it's always best to prioritize the out-of-the-box solution because it results in less complexity in the solution and licensing/maintenance costs throughout its lifetime. This unit discusses some of the considerations that you might make when considering third-party solutions.

Where to find third-party solutions

The official Microsoft app store for third-party solutions that work with Microsoft Power Platform and Dynamics 365 apps is AppSource. Independent software vendors (ISVs) can register their solution and go through the certification process to be listed.

As you look at solutions, consider their level of integration with Microsoft Power Platform apps and the Dynamics 365 apps that you are using. The less integrated they are the more likely you will have to perform custom integration to fully use the solution.

Solution architects that work in the same solution area should be aware of the most popular ISVs that solve problems in that area. Often, partners will develop skills in a particular set of ISV extensions that they can reuse on future engagements. A Solution architect is frequently involved in that internal evaluation and selection.

Evaluate the ISV

As you contemplate including a third-party ISV component as part of your overall solution, know that you are taking a dependency on the long-term viability of that component and the vendor. The success of your implementation now depends on that component working as advertised and, if not, it being supported by that ISV. As part of evaluating an ISV, you should consider the following factors:

  • How long the ISV has been in business

  • How large the ISV is and whether they have the means to support an implementation of your size

  • How long they have been building for Microsoft Power Platform or Dynamics 365

Evaluate the ISV component

You should assess the ISV component to ensure that it is viable to solve the targeted problem. Often, it is not until you try the component in your proposed solution setting that you will discover its shortcomings. Often, this scenario is when a proof of concept approach can help.

As you evaluate the component, consider the following factors:

  • Security integration - Determine if the component works with Microsoft Power Platform and/or Dynamics 365 app security models. If the component has a different model, assess whether you can easily map a solution and still meet your requirements.

  • Flexibility for customization - Microsoft Power Platform and Dynamics 365 offer several options for customization and extending. Review what is offered by the component and whether it will adequately fulfill your requirements.

  • Stays current with Microsoft releases - Microsoft updates weekly in some cases and, at times, deprecates older approaches to keep the apps modern. Assess whether the ISV is keeping up with releases and is using supported techniques in their product to ensure that you won't have problems.

  • ISV roadmap - Determine if the ISV has a roadmap of their planned enhancements. Make sure that you verify whether the ISV has plans for enhancements or not and if the product is offered "as-is."

  • Data location - Find out where the ISV component stores its data, if it integrates with your Microsoft Power Platform and/or Dynamics 365 apps, or if they have their own cloud or other storage solution.

  • Fitting the gap - If your team plans on further customizing the component, verify that the component's licensing will allow for that and what technical debt you might be adding.

Evaluate licensing

If you're bringing a third-party component into the solution, licensing must be considered. Ensure that the licensing is not only in the project budget, but also is done in a way that is compatible with your use. For example, limits on the number of API calls or other ways that users interact might not work for your volume of use.

The use of open source is also becoming more popular on business application solutions. Generally, the appeal is that they are free to use. However, solution architects should still be aware of the component's licensing model and any requirements to comply. Additionally, project contracts with customers often stipulate some level of approval when open source is included in the overall solution.

Using third-party components is a great way to solve gaps in the out-of-the-box features for the apps. Often, by using a third-party component, you can save time and optimize ongoing maintenance when compared to custom-building similar components. By spending initial time evaluating and selecting the components that you use, you can avoid unpleasant project issues that arise from selecting components that aren't a good fit.

Exercise: Review AppSource for financial solutions

With Woodgrove Bank in the market for a large solution, you should be aware of what others have done and how that might fit into your proposed solution. Go to AppSource and look for package offerings that could help Woodgrove Bank quickly reach a viable solution.