Integration Approaches

My former post explained how to go about using the "mash up" technique for integrating CRM with other applications. In so doing, it also touched on other approaches to integration. I thought I'd delve into that topic a little more in this post.

In essence I mentioned that there are 3 high level approaches when it comes to combining two applications together. Although technically - when it comes to it - there are in fact only 2 high level approaches to integration. But we'll come to that. This topic is not limited to Microsoft CRM but can apply when integrating any two systems together.

The first approach is physical integration. That is, data in one system is physically moved to another system. This is perhaps the most common form of integration and is most often what people think of when they refer to the term "data integration". Of course there are many different methods of going about physical data integration be it real time integration, close to real time integration, batch integration, and file imports/uploads. And there are various mediums/formats that can be used for integration such as web services, XML, CSV, stored procedure, direct database querying/updating and so on. But at a high level these all represent a single approach to integration - that being the physical transfer of data from one system to another. Perhaps at another time we can perhaps delve into these different methods, mediums and formats for integration highlighting pros/cons to each of them and when they may or may not be appropriate.

Physical integration is required in any one of  the following use cases:

• Data Continuity - The data starts in one system and needs to be "embellished" on via the CRM user interface and perhaps passed back to the original application to form a 2-way integration or onto another application.
• Data Accessibility - Sometimes data needs to be updated in 2 systems because that's just the requirement. For example, accounting personnel will need to update an account record in the back office accounting system and the sales team will be updating the same information (perhaps with checks/balances) via the CRM front end.
• Reporting - Data needs to be reported on from within the CRM database
• Workflow - Data brought into CRM is used to trigger workflows. For example, an escalation or approval workflow being triggered off an account billing status.
• Offline requirements - If the data is required offline then it will need to flow into CRM in which case, CRM's syncing capability with Outlook can be used to bring the data offline 
• Mobile requirements - Similar to the offline requirement. If the data needs to be synced with a mobile application it will need to be passed into CRM.
• Security - Not a very common scenario, but if the data coming in has security restrictions in terms of who can view it, then CRM's security model can be applied against it if the data physically resides in CRM.
• No other way - It could be that the source system is not accessible by any other means than via data integration. This could be if the application has some flat file format, is stored in a spreadsheet, or some other variation that makes connecting to the information through any other means other than data extraction/integration impossible.
  

Physical integration may not be a good idea in the following scenarios:

• Size of data - If the data on the other side is very large (in the millions, tens of millions and beyond) or changes very rapidly it might be unwise to do physical data integration due to the volume of information that will constantly be flowing back and forth. This could be true of invoices or supply chain information.
• Simplicity - Physical data integration may just not be necessary or it might be simpler to use a different approach either for the short term effort or long term maintenance effort or both. Remember that integration is something that over time needs to be maintained and if having a more "static" approach will work then this may be the better option.
• Tools - If you don't have the right tools for integration and have budget restrictions in that regards then you should probably look into other alternatives.

As alluded to by the last point above, when physical integration is required then you are best off ensuring that you have the right tools for the job. I have already discussed this topic in depth  a former post in case you want to get a perspective on this.

I will discuss the other integration approaches in separate postings.