Cobalt’s products have a unique characteristic that provides a huge benefit both to our customers and our internal development, implementation and support teams. The idea of platform independence for Cobalt’s products came out of years of experience working with MS Dynamics CRM.
In preparing for a recent demo to a client I was tasked with discussing a pivotal part of Cobalt’s architecture that over the years has proven its worth time and time again. As my mind swirled I decided it was worth writing a post since I wouldn’t necessarily be able to discuss all of the benefits during my short part of the demo and so I could flesh out the talking points I did want to discuss.
The unique problem platform independence was developed to solve for Cobalt was being able to maintain a product on a constantly changing platform. The first iteration of Cobalt’s products was built on CRM 1.2 but didn’t truly begin to take the form they do today until the release of version 3. With CRM 3 Cobalt made a few wise decisions early on, to structure our code in a way that led to greater reuse and a standard look and feel for our customers. This ultimately led to less rogue coding and interface design, but also created a layer on top of CRM’s integration points that abstracted away the details and limited the amount of control the programmers had on interacting with CRM.
When Dynamics CRM 4 was released we began upgrading our CRM 3 clients soon after because the functionality in CRM 4 was more in line with our client’s needs. Beginning with the first upgrade from CRM 3 to 4 it became evident that we had done something right in our design. The centralized nature of our code and the layer we had written on top of the CRM integration points served as a distinct location for our upgrade efforts. Rather than having to find and replace across hundreds of thousands of lines of code, our efforts were limited to the abstraction layer. Unfortunately, in this early stage this was limited to our CRM client side code and didn’t translate to the business logic and application layers.
Eventually, all of our existing clients were upgraded to CRM 4 with varying levels of effort, but successfully none-the-less. In that version CRM introduced the plugin architecture which effectively replaced the callouts of CRM 3. However, since CRM 4 continued to support callouts from CRM 3, we decided to keep that code intact and not spend the time required to switch to plugins. Regardless, our CRM 4 product code was no longer compatible with CRM 3 and getting all of our clients on the same version was a requirement.
The next step in the evolution of the platform independent architecture was the release of CRM 2011. This effort was far more significant than the CRM 3 to CRM 4 upgrade and proved the need for a better way to handle the changes that were certain to continue to come from the Dynamics development team. All of these changes to the integration points in CRM were positive changes and were pivotal to making the platform more extensible and flexible. However, the problem remained that our investments in products that relied on CRM as the platform were at risk of either becoming unsupportable, or worse, obsolete if we weren’t able to quickly adapt to changes in the architecture.