Microsoft Dynamics CRM is an interesting and powerful business application. A core out-of-the-box (OOTB) benefit of Dynamics CRM is the ability to extensively tailor the application to address business needs, and here there are two approaches to consider: development or customization. Determining which approach to take is the key to maximizing the benefits of Dynamics CRM while keeping costs low.

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.

The first challenge my team encountered was the lack of support for team-based development in CRM. It seems CRM was designed primarily for a single developer or business analyst to rapidly churn out customizations. While that’s suitable for a small business, this model is inadequate for enterprise solution development using two or more developers. We were tripping over each other when creating functionality and running into frequent issues with version control and release management. We finally achieved order through the use of structured sprint planning and establishing a CRM development process. The latter uses Microsoft Team Foundation Server (TFS) for code and solution management, and custom development tools to create entities and fields using HTML, JavaScript and Typescript (a typed language version of JavaScript that compiles to plain JavaScript).

Our next challenge: As long as customer requirements stay well within the Dynamics CRM playing field, OOTB customizations should meet your business needs. However, if there’s any logic or relationships connecting fields in the data entry forms in order to support business rules, you may need to replace the OOTB forms altogether. Our developers tried using the existing CRM form structure and JavaScript plugins, but that led to complex code and unsupported solutions because we were trying to create relationships between entities and fields that were beyond the scope of OOTB Dynamics CRM. Based on the lessons learned from that experience, we’ve gone with HTML and JavaScript forms as a standard for our solution. The development team has reusable code to help speed things up so they’ve become quite efficient at building custom forms by leveraging TypeScript in our solution.

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?

[pullquote]Ultimately, these are questions of project management.[/pullquote]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.