There are a lot of great ISV solutions available in the Dynamics AX ecosystem that can help you bridge the gap between the standard product and the required industry-specific functionality. Usually, if someone already has a solution that has been used by multiple customers, and has experience in that specific domain, it will be less risky than developing your own solution—you don't want to reinvent the wheel.
Project managers and solution architects need to act as the customer's advocate in choosing ISV solutions. Getting the right ISV solutions and holding them accountable within their areas is important for your success.
Before choosing ISV solutions, consider the following points:
- Build versus buy analysis: Sometimes, going with an ISV solution may look like a quick win. However, it may have a great cost associated with it. You need to make sure that the team has done a good build versus buy analysis.
- Benefits and percentage of fit: Understand all the benefits that the ISV product has to offer and identify the percentage of fit that you have with the requirements. If you still have to customize for more than 20-30 percent of the scenarios, you may be better off building the whole solution by yourself.
- Readiness on current version: It is very important to see a demo on the current version of the product (that is, the version you are planning to use) or understand how close the ISV is to delivering the solution for the version that you will implement. Try to defer the decision to buy an ISV solution until the product is functional for the version you need.
- Product roadmap: Understand their roadmap and features, if any, promised as a part of the roadmap. Make sure that those deadlines are mentioned as part of the contract. For example, ISV currently provides tax calculation only for the U.S. However, Canada is on the roadmap. Make sure that you understand the deadlines for Canada and have those documented as part of the contract to ensure that your project doesn't suffer due to delays from ISV. Also, review their roadmap for upcoming cumulative updates.
- AX roadmap: Be aware of any new functionality that Microsoft is working on for new releases. Will these features supplant the ISV solution? And how easy would it be to upgrade AX and take advantage of the new features? Would it be more cost-effective? How will it affect the business if you wait for new features versus doing a temporary customization or implementing the ISV solution?
- Architectural review: Have high-level architectural reviews done by the Solution architect/technical architect on the team as part of the evaluation (to ensure that there are no architectural gaps and the solution is scalable).
- References: If you don't have an existing relationship with the ISV, ask for customer references and have a discussion with the references prior to making a decision.
- Company size and support: Yes, it does matter! You don't want a multibillion-dollar organization to be dependent on the small ISV solution provider (that will be part of the tier 1 ERP system) that has only two employees. The solution may be great, but you need to evaluate the risk to the business if you are going to be fully dependent on an ISV partner to support you.
If there are a lot more features that are included in the ISV solution than the customer may ever need, and if these features touch any of the core features of Dynamics AX, you may have to reconsider the solution (more features would inject more bugs in the overall Dynamics AX environment and may cause issues for other standard AX features).
Consider the following after partner selection:
- Get the budget approved and have all the invoices billed through the partner. This way, the customer doesn't have to deal with multiple parties.
- Share your project plan with the ISV partner and align their delivery dates according to your schedule. Update your project plan to include key ISV deliverables.
- Have them attend weekly meetings for status updates (if they are working in parallel on building the solution).
- Install all the ISV Solutions in a specific layer other than the VAR layer. Usually, ISV solutions are imported in the ISV layer.
- Plan the code and configuration changes from ISV that must be incorporated into your development and other environments.
Consider the following to avoid common pitfalls during ISV selection:
- You don't want to involve too many ISV solutions as part of the overall solution. It would increase dependencies for upgrades, and there may be conflicts in their solutions, which would cause pain.
- Each ISV solution being envisioned in the overall solution design should have a minimum overlap of functionality and objects.
- Upgrades (or even hotfixes) provided by Microsoft may become challenging. You will have dependencies on an ISV solution if the hotfix provided by Microsoft touches the areas modified by the ISV partner.
- Access to the code base and any proprietary solution components: You must avoid any ISVs that have proprietary solution components that are not available for you to modify (for example, DLLs for which you don't have code. You are now dependent on the ISV Partner for every change that needs to be made).