Last time I discussed the need for easy transferability of the ongoing management of integration solutions from development to production. I will now discuss the fourth capability essential to a collaborative integration platform, Supportability.
Moving an integration process into production introduces the same set of challenges as moving any application or solution out of QA into production. Users always use application in ways that were not contemplated by the original integration design, resulting in unexpected errors and exceptions. Modifying the design of the end point applications after the integration is implemented may disrupt the integration processes. Changes to the overall IT environment may interrupt connections between the various applications. In short, business happens and things stop working or not work as intended. Your integration approach should include a robust set of error detection, diagnosis and remediation tools.
Is there a way to proactively monitor the health of the integration and raise alerts when things are not functioning properly? Are there meaningful execution and error logs that enable someone to quickly identify the root cause of any issue? Does the integration process have built in re-try mechanisms that address any timing issues (for example, attempting to process an order transaction before the related customer record has been created in your target application)?
A major area to consider with any integration solution is the ability to handle gracefully upgrades to your business applications. For example, if a customer moves from Dynamics CRM 4.0 to Dynamics CRM 2011, what will the impact be on the integration? Is the upgrade simply a testing exercise where things for the large part continue to work or does it require a re-write of the integration? The best integration solutions create an abstraction layer between the integration processes themselves and the API of the endpoint applications. The process only sees the abstracted interface and when the endpoint application is upgraded, it is simply a matter of modifying the interface between the API and the abstraction layer. If you are looking at 3rd party adapter products, make sure you interrogate this question fully. You will be glad you did later.
At the risk of stating the obvious, the integration approach needs to be very reliable. In other words, "It just needs to work". The best integration is one that no one ever knows about or notices (of course, until it stops working and then it gets a lot of attention). Integration solutions that are not rock solid are disruptive and costly to your business as well a significant drain on your resources. Users may not trust the data they are looking at and go to other methods that may be more time consuming and costly to the business. They may stop using the CRM system all together and cobble their own "system" which completely defeats the purpose of your CRM implementation and integration. Your resources that could be on other, more important projects are now working on fixing that integration – again.
In the next and final installment, I conclude with a discussion of the need for expandability.
Comments