Insights
Bringing our best ideas and thinking to you.
Blog Post
February 10, 2017
Share this page:
Should we avoid Dynamics CRM customization?
By Richard Lund
Managed customization is a key element of a timely, well implemented and maintainable Dynamics CRM implementation.
Customization horror stories are not unfamiliar in software development - giant code-castles built by well-intentioned developers who didn't realize that in code terms, less is often more and that saying "yes" to every customer requirement just because it's possible can create a monster.
Inevitably the penalties of technical debt surface at some point as the monster grows uglier over time - adjustments, hacks and extensions are layered on with nobody ever having the time or bravery to tackle core deficiencies. Even worse, the overall solution may fail completely at some point, or become incompatible with a changes to the platform or a core component.
Customer experience with these challenges can lead to the requirement to "avoid customization" as a guiding principle in implementation of COTS products like Dynamics CRM. Is this a valid basis for the design and implementation of a successful solution? In short, no.
The "ideal" Dynamics CRM implementation sees all requirements fulfilled purely through OOTB functionality and product configuration - well-documented, vendor-defined settings available through the application itself and used to make the system fit the needs of the organization. This is typically quick to implement, upgrade-proof and low maintenance.
The reality is that almost all major implementations require more complexity and sophistication than configuration can provide, especially if we can't make significant changes to existing business processes and can't embrace the Dynamics CRM "way of doing things".
A blanket "no customization" rule is clearly going to be a problem when we know we need some customization, but at the same time, a developer free-for-all leads us to the gates of the code castle.
We promote a managed customization approach which considers customization as an option while avoiding the potential pitfalls, throughout the project lifecycle :
- Requirements: We review requirements carefully in light of the platform capabilities as part of the fit-gap process and continuously as detailed requirements are developed. This is crucial in a COTS scenario - creating "pure" requirements that don't consider platform capabilities is asking for trouble and often leads to a situation where customization is the only choice.
- Design: We go through a process of options analysis around all requirements that may require customization, assessing overall complexity and maintainability of both configuration and customization-based options. In many cases complex configuration (that doesn't break the "no customization" rule) may not be a better long-term option than a small amount of custom code.
- Design: Where we do decide on the need for significant configuration or customization, we advise the client of the implications and discuss whether a better long-term option may be adapting business processes to align with out of the box capabilities of the platform. Even if the answer is no, this ensures it's a conscious, informed decision rather than something uncovered during later phases or maintenance.
- Implementation: We operate technical review and quality processes to make sure that complex implementation components are high-quality and maintainable, especially through design peer review, code reviews and validated unit testing.
So our answer is no, we shouldn't avoid Dynamics CRM customization: What we should do use a managed customization approach to produce a sustainable solution with high technical integrity, high maintainability and no monsters in the closet.
Struggling with existing heavy customization? Embarking on a complex new Dynamics CRM/365 project which seems like it will be complex? Contact Richard [email protected] to talk about our approach and how we've tackled these issues in our implementations.