9 Important Steps for Successful Integration Projects

System integration involves integrating existing (often disparate) subsystems and then creating unique and new value for the customer or end user. Successful integration planning efforts must encompass a broad scope to ensure that an initiative meets all specific business requirements. In order to maximize success and minimize re-work, a business evaluation should start and guide each system’s integration effort.

This blog first describes the desire for best of factors which drive integration projects. It then elaborates on the required steps within a successful integration effort. The role of enabling middleware technology is then highlighted, followed by the importance of a business evaluation (the critical first step), which we'll expand upon below.

Need for Best of Factors Drives Integration Efforts

The challenges of best of factors when choosing between middleware technologies and vendors can be difficult. A customer should consider the following issues:

• How will the solution affect the employees?

• Which vendor will support which applications?

• How much will it cost to integrate the applications and what will be the impact?

• How quickly can I go to market?

These are just a few of the fundamental questions that should be considered in planning your integration solution between various cross-platform applications.

1. Defining Integration

Each vendor involved in the project will have its own definition of an integrated solution. To some, it means that they have standard Application Program Interfaces (or APIs) used to perform specific functions within their application. For others, it means they can create and/or receive file interfaces in specific formats to exchange data with other applications. Both these and other approaches constitute a form of integration with other applications. But buyer beware—you must ask vendors some very pointed questions relative to their definition of integration.

2. Understanding Business Requirements

Most third-party vendor applications are feature and function rich, providing banks with a host of configurations from which to choose. In addition, each bank’s operations and specific product offerings may differ for a number of reasons. This richness allows each bank to implement and use the functionality best suited to meet the business need; but, it also means that no two implementations are alike. As a result, real-time and batch interface points that are required for one organization may not be required for another organization. The integration for two different organizations using the same application may be very different; in fact, there may be no such thing as a "standard" integration. Hence, it is very important to start every integration by understanding the specific business requirements and needs.

3. Managing Versions of Connecting Systems

Many times, additional hardware and/or software are required to integrate a source application with the target system. And usually, it’s the buyer’s  responsibility and expense to purchase, install, and support these components. A frequent cause for this scenario is when clients choose not to upgrade their systems and, consequently, run an older or no longer current version of the application. In some cases, older versions of their source application are "integrated" with the target applications, but newer versions have not been. Therefore, two key questions to ask any integration vendor providing are: “Which versions of source and target application does your solution support?” and “Which versions are you currently selling?”

4. Customizing the Core Setup

Any integration solution provider offers clients the ability to create highly customized  solutions which will meet their requirement through their core processing platforms. As a result, no two core customers' integration solutions are exactly the same. Moreover, the unique combination of features and functions may make integration exceptionally difficult—and in some cases, impossible—and for this same reason, integration solution providers have made generic “plug and play” templates which allow buyers the ability to set up interactive connections between source and target applications for ready use.

5. Data Mapping Considerations

Another key factor to consider is the data structure between two systems. If one system has fields that are longer than another system, there will be truncation of data. In addition, data types and data formats could differ between two systems. To prevent this, any integration needs to acknowledge and take into account a design that addresses this issue.

6. Data Synchronization

This step helps in establishing consistency among systems and subsequent continuous updates to maintain consistency. The word ‘continuous’ should be stressed here as data synchronization should not be considered a one-time task. It is really a process which needs to be planned, owned, managed, scheduled, and controlled. The requirement for today is that systems need to speak to each other in real time, and the main challenge with real-time data synchronization occurs when working with systems that do not provide any API to identify the changes. In such cases, data synchronization helps an analyst to check whether data fields which are mapped are moved correctly between source and target systems .

7. QA Process

Integration quality control has to be different from traditional quality control processes of phased unit, system, and integration testing as a resource who is performing the integration testing process should have the knowledge of source and target system and their behaviors under defined scenarios and record the test results appropriately which will not only save time and effort of the company but also of the client.

8. Plan for Go-Live

The production readiness outlines the list of criteria needed from a project before an integration project is deployed in the production environment (e.g. data quality, go-live dates, staging/production environment readiness, or as determined by the project sponsor and/or production support manager). The list is to be used as a guide by a project manager and client manager to check on agreed data migration and mapping, and give consent to actually go live.

9. Go-Live and Support

The purpose of this phase is to cut over to live productive operation and to continuously support and improve live operations. The Go-Live and Support phase consists of two distinct phases. First, the project is completed with a formal “Project Closing.” During this time, the system is used productively in day-to-day operations, all issues and problems are resolved, transition to the production support team finalized, knowledge transfer completed, and the project signed off. Subsequently, the “Support” phase begins during which the production support team monitors the system and resolves live business process issues depending on the mutually agreed SLA.

Through the compilation of these practices, any organization can adapt this advice to fit their specific project's requirement.