CRM integration design – the options

March 23, 2018March 23, 2018 Mark Payne

Often, one of the most technical parts of a CRM implementation project is the integration of the CRM platform to other back or front office systems. In my experience, organisations are often happy to let their implementation partners worry about the technical detail as long as the business outcome is achieved. That is fine when you are working with a partner that you already trust but what about when it comes to choosing a partner or choosing between several proposals during a tendering process. Do you know the relative pros and cons of different integration approaches so that you can make an informed decision as to what solution will fit your business’ appetite for risk? In this blog article I hope to be able to make you more informed!

Integration generally comes in two flavours. I tend to refer to them as tightly coupled and loosely coupled. In a tightly coupled scenario, the two integrated systems will talk directly with one another often at a database level. Conversely, in a loosely coupled scenario there is some degree of separation between the two systems. For example, there may be a piece of middleware that marshals the data between the two systems.

 

What are the relative advantages and disadvantages of the two approaches?

A tightly coupled system generally has less “moving parts” so is normally cheaper to implement and maintain. You could also argue that there is less to go wrong. The biggest disadvantage with a tightly coupled system is that each system relies heavily on the other not changing. This can quickly lead to problems when it comes to upgrades of either system and may mean you needing to significantly re-work the integration. Another issue to bear in mind when looking at a tightly coupled setup is what will happen if one of the systems goes down. Will the integration “catch-up” with the changes when both systems are back online or are you likely to lose data?

Tightly coupled integrations have their place. In my experience, this tends to be where an “out of the box” integration is offered. For example, integration between Microsoft Dynamics and other Microsoft products or the various integrations available between CRM platforms and eMarketing software. In these cases, the integration itself is a product and you are mitigating the risk associated with upgrades by making the vendor responsible for the re-work as part of their normal product release cycle. They are also the only real choice if true real-time integration is a must as any loosely coupled systems will always rely on some sort of scheduling to run, even if that scheduling is set to run every 30 seconds. I have yet to come across a genuine use case that requires true real-time integration but I am sure they are out there!

As previously mentioned, in a loosely coupled setup there is a degree of separation between the integrated systems. This may or may not involve some sort of staging database that acts as a stopping off point for the data on route between the two integrated databases. Setups of this nature have two big advantages; firstly, they are easier to adapt if one or other of the integrated systems changes and secondly, they tend to be more resilient to one or other of the integrated systems failing. The exact amount of benefit you can derive from this setup depends on the exact architecture and, largely, if you choose to implement the aforementioned staging database.

In all types of loosely coupled architecture there will be less to change if, for example, you upgrade one of the integrated systems. This is particularly true in a setup that includes a staging database as you will only need to re-work one “side” of the integration. This makes upgrades of your systems far less risky and normally less costly from an integration point of view.

Because they have some independent moving parts marshalling the data, loosely coupled systems are almost always more resilient to source system failures. Again, the introduction of a staging database is the best possible setup. If one of the target systems goes down data will essentially “queue up” in the staging tables until it is back online at which time it can work through all the changes gathered during the outage. A nice fringe benefit of using a staging database is that, with careful design, they can also act as a data warehouse and/or reporting database.

For the most part, loosely coupled systems tend to be more complex and therefore more expensive to implement but I have seen time and time again the initial investment returned when it comes to the scenarios described above. As I mentioned earlier, they also cannot implement true real-time integration. For me, they work best where you have systems from different vendors that need to share or swap data.

The final item to consider for any integration design is the method that will be used to implement it. This can either be a “black boxed” bespoke solution or via some sort of middleware product. By their very nature, tightly coupled setups will generally be of the former type but loosely coupled setups could be either. Although the introduction of a piece of middleware may mean additional licence, maintenance and support overheads, in my opinion they are worth the money for the speed of deployment and portability that they provide.

Clearly, every integration use case is unique and there are many nuances to any solution but hopefully you now know a little more about integration design and feel better able to critically evaluate any proposal being put to you.