Dynamics CRM is a basic web user interface fronting a SQL Server database that manages relational data. However, it is flanked by a built-in array of basic analytical tools and extensive administrative features, such as auditing, which give it enterprise-level credentials. Throw in a customizable user interface (UI), and you have a tool that is capable of supporting both small businesses and multinational corporations. So it would be logical to assume that Dynamics CRM has a developer-friendly, structured architecture to support customizations.
However, the reality is a little more complicated and brings up some curious paradoxes about Dynamics CRM.
This post is not meant to criticize Dynamics CRM but to underscore my evolution as a CRM Business Analyst as I’ve come to understand Dynamics better. I’m currently supporting a team of three developers and a subject matter expert in developing a human resources management application. Our CRM-based application is a replacement for an obsolete, WinForms-based tool that’s been refined over a decade of continuous development. Following the evaluation of several competing technologies in the marketplace, it appeared that Dynamics CRM offered the best package of OOTB customization and cross-application functionality at the best price. Ten months into the project, we have reproduced over 90% of the original tool’s functionality — but more importantly for the development team, we’ve come to understand the strengths and challenges of Dynamics CRM.
But then we also have the mash-up of managed versus unmanaged solutions, which brings us to a peculiar feature of Dynamics CRM.
Solutions in Dynamics CRM are classified as managed or unmanaged. Microsoft describes them this way:
A managed solution is a completed solution that is intended to be distributed and installed. An unmanaged solution is one that is still under development or is not intended to be distributed.
A fundamental distinction between the two is that unmanaged solutions cannot be uninstalled cleanly whereas a managed solution can be neatly rolled back out. Consequently, the development team would prefer to roll out only managed solutions and not have any BA-produced, unmanaged solution in production. While this assures stable and robust solutions deployed in a controlled process, it prevents the rapid, localized customization that is considered strength of Dynamics CRM.
This brings us to the third challenge and essentially the crux of choosing between (or blending) development or customization. CRM OOTB offers a lot of flexibility and ease of customization through the UI. It would even seem that Microsoft encourages this approach through the absence of team-development support and the “power” of a non-technical user to publish and manage heavily customized solutions for a customer. Cost wise, it would be a lot cheaper to have a BA customize and maintain a solution than a developer. However, if the customer requires some sophistication in their solution, a plug in (which is CRM’s version of an event handler) may be required and this inevitably pushes the customization back into the domain of the developer. So we now return the prior issues of the managed versus unmanaged mix mentioned earlier. To compound this issue, we also need to manage versions of the solutions developed by Business Analysts and Developers respectively, as well as determine which customization or configuration becomes part of the enterprise solution versus user-specific configuration. These questions may be best summarized in a single line: who is responsible for what and how?
Ultimately, these are questions of project management.
Ultimately, these are questions of project management. At the start of the project, scoping the solution is critical to determining some sort of framework, or governance, to structure the customization of Dynamic CRM and then maintaining those customizations. The scope should not be so restrictive that it cripples the strengths of CRM but it needs to be specific enough to keep solutions on the OOTB CRM field as much as possible. Anything that falls outside the OOTB parameters would then need to be managed by a specific, software-development driven process.
So what begins to develop is two sets of governance: the first being a business-driven governance catering to BAs, and a second governance covering developers when solutions cross a line of complexity. This has the benefit of allowing customizations to be deployed at the BA-level, meaning cheap, quick and user-targeted solutions. Simultaneously, this governance must also provide the necessary structure for developer-driven, enterprise-oriented development. My experience on this project indicates this is the best approach to realize the benefits of Dynamics CRM and find a way through its paradoxical attributes.