Posted by: Sasirekha R
Application, best practice, Integration
Integration – Standard Best Practices
There are multiple options available for integrating multiple systems not designed to work together. The major classifications are Data / Functional / Service Integration with choices on Push vs. Pull, Inbound / Outbound, Synchronous vs. Asynchronous, Online vs. Batch, EAI vs. ETL, use of Messages / files etc.
Each form of integration has its own advantages and disadvantages – and there is no silver bullet. The challenge is in choosing the right kind of integration based on the specific context thereby achieving the right balance among the trade-offs. In any enterprise, combinations of Integration approaches have to be used depending upon the context (“one-size-doesn’t-fit-all!”).
While choosing the integration approach, the following are the standard best practices to be considered:
Be as non-invasive as possible – try to keep the changes to the existing system to a minimum. Any change to an existing production system is a risk – and at the minimum needs testing effort.
Isolate applications so that changes to one application’s internal structures or business logic do not affect other applications. Without isolation, a small change inside an application could cause a ripple effect and require changes in many dependent applications.
When making updates to another application’s data, make use of that application’s business logic that performs validations and data integrity checks (i.e., at the minimum, use Functional Integration to integrate systems at the logical business layer).
Most third party products provide documented programming interfaces allowing access to the business functionality that is incorporated in their application. Exploit the APIs provided by the vendors specifically to support integration with external software. These public APIs are typically backward compatible – and can minimize impact the external applications even when the database schema changes.
For internally developed applications, try providing documented programming interfaces (APIs) that are abstracted to a maximum possible extent so that every database change in your application doesn’t impact the external applications.
Messaging and Queuing is a simple and yet powerful way of integrating between applications. Messages in addition to sending data can be used to send instructions on what needs to be done. More powerful conversations also allow an application to more specifically describe the functions and services it can provide to other applications.
Usage of commercial ESB tools can influence the integration strategy – as they provide multiple options and are relatively easy to use as against creating a custom solution (especially so if a point-to-point Integration has to be avoided).
Take into consideration, the life span of the solution – Short-term solutions, that are designed to be replaced or easily removed, can be hard-wired and can have low performance. Long term solutions must be standardized, adaptable, and engineered for high performance.