On Integration

On numerous occasions I've had the question posed to me whether it is necessary to use a tool such as Scribe for building integrations vs. using CRM web services (or using eConnect for integrating to GP as opposed to Scribe and so on and so forth).

I think the question itself indicates that there is perhaps a misunderstanding of what the term "integration" really is all about.

First of all, by way of disclosure, my company, Sentri, highly recommends using an integration tool for tying systems together. Scribe is an excellent example of a tool for building integrations with MSCRM that I fully endorse. The rest of this blog entry will attempt to both answer the question as well as justify this recommendation.

In short, when it comes to integration, it is really not a question of Scribe vs. CRM web services but rather Scribe and CRM web services. In short, there is nothing stopping you from creating an "integration" using the CRM SDK and web services but to do so is reinventing the wheel to a large extent. It needs to be remembered that "integration" is not just the act of making one system talk to another - that is arguably the easiest part of the long term effort. A successful integration strategy has a number of other components, including:

 

• Loosely tying systems together. We do not want the source application to be tied to the target application in such a way that if the target application is down, the source application is down too. Such would be the case if we were to build a simple “synchronous plugin” integration approach (an "asynchronous plugin" would result in the integration disappearing into the good night when the second system is down).
• Queueing. It is important to be able to queue integrations up such that under load or under the scenario described above where one system is down – items get written to a queue and are integrated as soon as the target application can accept them.
• Retries. When an integration fails it is important to be able to have an effective automatic as well as manual retry mechanism. Sometimes an integration fails for a condition that will self correct and will succeed on the next retry. For troubleshooting purposes, it must be easy to have a way to retry an operation to get to the root cause. In short an integration must either succeed or if it fails it should fail “noisily” so it can be proactively addressed.
• Alerts. It’s important to be able to set up a proactive alert mechanism if there are issues with integration. This helps to quickly identify and resolve issues as they arise.
• Customizability – It’s important to be able to easily modify an integration for changing business needs. It’s equally important to use a tool that is supported, has easy access to training and/or qualified resources. It also helps for the tool to be a “configuration” rather than “development” tool.
• Console Management. It’s important to have a console that provides a single view of integration activity (especially when there are multiple integrations going on) as well as an ability to stop and start integrations in a simple manner.

A product like Scribe brings all of these capabilities out of the box. Scribe also leverages what are referred to as "adapters" for integrating to products such as MSCRM. And when we refer to the Scribe adapter, we mean the capability of Scribe to automatically expose and talk to all MSCRM web services; similarly when we refer to the Scribe adapter for GP we mean the capability to automatically expose and talk to all GP eConnect routines. It's not a matter of either/or as posed above but rather whether you want to build a robust integration strategy using off the shelf tools that will stand the test of time.

Comments

[Jeffrey Davis]

These are the things I love about Scribe. Definitely bookmarking this post should the discussion come up in the future.