At some point during the development lifecycle of mid-to-large scale Dynamics CRM projects, we are faced with a number of design decisions that are to be made. That is, when is it appropriate to customize the platform versus when is it appropriate to opt for pure configuration.
First off, let’s talk about what configuration is. Configuration, in the Dynamics CRM sense, refers to the ability to use out of the box (OOTB) functionality to achieve a desired result. For example, using business logic features such as CRM Workflows and Business Processes, or CRM Form Designer for user interface design. These are no-code configurations where no specific custom programming logic is required.
There are hard costs and soft costs for opting for one over the other. And the factors which lead to choosing customisation vs configuration can be either technical or business driven.
Here is a checklist of factors which deserve some consideration when opting for one over the other (in no particular order of importance).
Where there are immediate time constraints brought on by resourcing or an external factor, these lead to a decision to bring forward shippable product releases by opting for pure configuration. One of the drawbacks to this approach is fidelity in the user experience or functionality is sacrificed. However, that may be outweighed by other considerations that will be mentioned later in this article.
MVP and The Value Proposition
Creating a minimally viable product (MVP) is a way of bringing forward ideas and testing concepts early. This is agile thinking which places emphasis on features that bring the most value to the business/customers. A MVP in a CRM context places a certain emphasis on achieving quick wins through using OOTB form controls over custom developed form controls – where an investment is required to develop custom controls. Whereas, the investment in using an OOTB form control is negligible. An MVP is an excellent way of ascertaining the level of user acceptance of the product early on.
Tie back to requirements
The best place to start is with the original business requirement. Ensuring that the project has not deviated from the original intention of our user story. A differentiation between want vs need should be made at this decision juncture. On large projects, a degree of segregation of roles can sometimes lead to a misinterpretation of the original requirement and subsequently lead to some less than desirable design decisions. It is worthwhile clarifying the original requirement, possibly develop an OOTB prototype to test the proposed solution with the business.
When opting for an extension to the platform, we should always keep in mind that Microsoft is continually investing in the Dynamics CRM platform. This is especially so for on-cloud deployments, which we will talk about further in this blog. Major releases (such as 4.0, 2011, 2013, 2015, 2016) as well as mid-cycle releases (2016 Update 1) have introduced new features which may or may not be code compatible with any custom extensions. One way to guard against using unsupported extensions is through the use of the Microsoft Dynamics CRM Custom Code Validation tool. This tool detects any deprecated code references and offers solutions for a fix. However, this method is not completely fool proof, with certain operations likely to be deprecated with no alternatives.
Another consideration is any future plans to move between cloud and on-premise environments. While the best solution designs are largely hosting agnostic, it is wise to ensure that any customisations to the platform are using supported code, and that all plugin and workflow logic run in a sandbox mode. This will allow portability of the solution if at any point, the business chooses to move their hosting to the cloud.
Any hard integration is likely to be through the Dynamics CRM SDK (typically through manipulating data within the CRM Data Model or pushing data back to other line of business systems). Integrations almost always require a degree of programming logic. However, there are tools such as Scribe or KingswaySoft that enable CRM awareness of the source/target systems. Efforts to minimize integration efforts should always be evaluated.
The issue of supportability will likely come up, and the original development team may or may not be available to field queries about the construction of the solution. Clean customization code will enable better supportability, and any configurations that are made should always be well documented. The higher the degree of customization, (typically quantified by lines of code) the higher the support requirement is should something go wrong.
Third Party Components
As mentioned earlier, with the availability of tools that make integration easier, there are also many third party components and connected cloud services which integrate easily to Dynamics CRM. A cost benefit analysis should be made. For example, in a project where there are many dozens of templated custom mail merge documents, it may be worth investigating the use of a CRM Document Generator such as Xperido. Reasons for choosing a third party component may include product maturity, premium third party support, as well as lower development and internal support costs.
Well hopefully this information has been of some benefit to you, please drop me a message if you have any questions or comments in the box below. Thanks for tuning in, until next time.