RSMUS.comIn the world of custom development, there is a lot of discussion regarding “technical debt,” a metaphor attributed to Ward Cunningham to describe obsolete code, anti-patterns, obsolete platforms and applications that may be part of an organization’s technology portfolio. Each of these items adds costs and inertia to the advancement of that portfolio, and if not managed, can stall efforts to keep technologically current.
Imagine a house filled with clutter where each time a resident arrives home they drop their keys in a random location. How much of their life would be wasted searching for their keys? (A discussion I have had at my house more than once…)
The process of implementing a new CRM system provides abundant opportunities to introduce technical debt that may prove increasingly difficult to eradicate. There may be others with more skill than I will ever possess, but I myself have never developed a schema of any real complexity, database or CRM, that was 100% correct on the first try.
Common CRM debris
The following areas relate specifically to custom development in Microsoft Dynamics CRM but some of the concepts can be applied to other CRM solutions.
Obsolete custom fields and relationships
It may be found that a single line of text is no longer sufficient for the required data, and a multi-line text field is required instead. Maybe a two-value option set was used initially, but the application really needs a ‘yes/no/maybe’ value using a custom option set. In both cases, it is easy to defer removal of the original field rather than tracking down its use throughout the system, and it may eventually be forgotten entirely.
Deactivated business rules
A change in interpretation or requirement may render a business rule unnecessary. If there is any uncertainty over whether the change could be reversed, the rule might be deactivated but not removed.
Invalid lookup and option set values
If valid records exist referencing these values, then they must retained, though hopefully inactivated in the case of a lookup value. Again, schedule constraints may encourage one to leave these be, rather than performing the queries required to determine if they may be permanently removed.
Unused functions in entity-specific JavaScript web resources
Refactoring of script functions or changes in forms may render functions an earlier set of functions unnecessary. Since a change to the event registration can permit the form to function properly, removal of the dead code may be deferred and forgotten.
Redundant processing of records
On a large project, duplicate tasks could be created and assigned to different individuals. While one may choose to implement a plugin, the other might realize that the requirement can be satisfied through a workflow process. There are now two elements in the system that perform the same function that will require maintenance. A change to the logic implemented in one may appear to be in error, as the other component would still perform the original logic until identified and corrected or (preferably) removed.
There are a number of reasons (a polite synonym for ‘excuses’) one may give to not remove obsolete items from CRM during development:
- “We might need this in the future”
- “We need to save the data in case there was a problem with the data conversion”
- “We don’t have time to remove these from the development and test environments”
- “We don’t know if it is still being used”
- “We don’t know what it does”
Yielding to these justifications, however, only enables an implementation to grow less manageable.
What are the costs?
Without proper care and feeding, a CRM implementation can sap hours of productivity from development and support teams. It may become increasingly difficult to identify how changes to one record will impact another, increasing the time and cost associated with error identification and resolution. Other impacts of technical debt can be easy to underestimate, as they can apply an imperceptible friction to the system and subsequent development:
- Time is lost each time a team member needs to determine which field is current and which is obsolete when changing system configurations, writing reports, scripts and custom development, or when mapping data migrations and performing integrations
- Solution exports and imports are larger and take longer
- The database footprint is larger and requires more server resources
- Responsiveness of the system is just a little slower
- More time is required to understand the potential unintended effects of a proposed change
While any single one of these delays might not add hours of effort to a single task, as the count of obsolete items increases, the frequency of such events increases, the overall impact accumulates and frustrations with the system slowly grow. By the time the effect of the built up mass of irrelevant items is noticeable, the cost and effort of a large-scale cleanup may be difficult for the business to accept.
Minimizing the Clutter
How can the CRM house be kept neat and orderly? Through a combination of discipline and planning. During a CRM implementation,
- Strive to remove unnecessary custom items as soon as they are identified as such
- Establish a standard process for removal of items from all environments in a systematic manner
- Use solutions to apply changes across different environments whenever possible
- Establish a set of guidelines to determine when a requirement should be satisfied through the use of Microsoft Dynamics CRM business rules, workflow processes, custom scripts, workflow activities and/or plugins
- Track all processes that can affect an entity behind the scenes, especially those that alter records other than those immediately visible to the initiating user
- Utilize source control to maintain the history of code artifacts, particularly web resources, custom workflow activities and plugin assemblies
These steps require some discipline and add a little more upfront effort to a project, but in the long run, a few minutes of prevention will save hours of cure. Custom programming using Microsoft Dynamics CRM as a development platform is also known as xRM. To learn more about xRM and how it can manage relationship for your organization, read our white paper, Extending CRM: Utilizing xRM to expand your relationships. You may also speak to a RSM professional at crm@mcgladrey.com or by phone at 855.437.7202.
By: Tim Resch – Great Lakes Microsoft Dynamics CRM partner
