In this series of posts I’ve been discussing Cobalt’s platform independent architecture and how it came to be. In this post I will discuss the realized benefits of this model since its inception.
As discussed, we never set out to build products that were platform independent for the sake of running them on multiple stacks. Cobalt is, at its core, a Microsoft shop and our expertise are in the markets we serve and most specifically CRM. However, the idea of platform independent products does have some appeal. As new platforms come on to the scene or existing products mature its more than possible that our products could run on those platforms if they provide benefits over Dynamics CRM. The benefit to our customers would be great as they would have more choices and the benefit to Cobalt would be equally great since we would have a broader market to serve. However, if we take a step back we begin to see the immediate benefits of this model for our software right now.
Cobalt’s adapter layer contains 3,037 lines of code as of today. Compared to Cobalt’s product code, which contains hundreds of thousands of lines of code, it’s obvious that there is a need to maintain steady state in the product code while still allowing flexibility for future platform level changes. The less code that is “touched” by a fundamental change to the integration points the less likely it is that something will break without being noticed. This benefit was realized early on when we ran across significant performance issues with the CRM 2011 endpoints. Due to the severity of the issue and the fact that it was noticed in a production environment, under significantly more load than we had previously seen, it was important that we were able to react quickly and with the least amount of risk. The adapters were the answer. Once we dug into the problem we realized that we saw significant performance gains using the old CRM 4 integration points over the CRM 2011 endpoint. For whatever reason we needed to switch our Retrieve calls to the old endpoint to fix the performance issues. This could have been a full system rewrite if we had not had the adapter layer. Instead, since we had initially developed an adapter against the CRM 4 endpoints, as well as the CRM 2011 endpoints, we were able to leverage both in this case. The result was the Hybrid Adapter that can be seen in the project list above. The Hybrid adapter uses the old CRM 4 endpoint for Retrieves and the CRM 2011 end point for Creates, Updates, Deletes and Executes. Unfortunately, with the introduction of CRM 2013 the CRM 4 endpoints are no longer supported, but it was only a matter of swapping out the Hybrid adapter for the CRM 2011 adapter and we were immediately up and running on CRM 2013. So, what of the performance issues? I’ll save that discussion for another time.
Apart from moving quickly to new versions of CRM or to the rescue of a choking software application, the adapter architecture allows us to take our time as well. Earlier, I discussed our move from CRM 3 to CRM 4. I mentioned that we left the callouts intact during the move, but even still our products were no longer backward compatible with CRM 4. The reason, for the most part, was that the CRM specific code was now using the CRM 4 integration points and CRM 4 libraries as well as a different version of .NET 2.0 instead of 1.1. Aside from the benefit the adapters provide for moving quickly to a new version of CRM they also provide the ability for some customers to remain on a previous version while continuing to receive updates to our products. Some clients are more skittish about moving too quickly to new software than others and often it’s rightfully so. In the Cobalt model of product development, new features and bug fixes that get released to our products remain platform agnostic as long as the interfaces on the adapters don’t change in such a way that the older version can no longer support the functionality. What this means to our customers is they can choose when to upgrade to newer versions of Dynamics CRM and still receive updates and fixes to Cobalt’s products. Today, we continue to support CRM 2011 client installations on the same code base as our CRM 2013 installations with only the client left to decide when they want to move to the new version.
The final realized benefit of the platform independent architecture we’ve seen is maintaining parity between our On Premise and Online deployments. The CRM Online environment is much more restrictive than the On Premise environment for reasons I won’t go into here, but effectively, the ability to control your environment is removed when you deploy your solutions to CRM Online. So, one must account for processes that rely on their particular environment. The specific problems Cobalt ran across in this scenario were cross domain scripting issues and plugins which required resources not available to the Online environment. I documented how we resolved these issues in a previous post, so I won’t bore the reader with the details. Suffice it say we learn something new every day about the flexibility of our architecture and I’m excited about what the future holds.