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 middle-ware technology is then highlighted, followed by the importance of a business evaluation (the critical first step) is expanded upon. Need for Best of Factors Drives Integration Efforts The challenges of best of factors When choosing between an middle-ware technology and vendor, 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 a best of Integration solution that requires the talking between various cross platforms 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 business requirements of the needs .
3. Managing Versions Of Connecting Systems
Many times, additional hardware and/or software are required to integrate a source application with 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 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 the same reason the Integration solution providers have made a generic Templates of “plug and play” which allows the buyers to set up interactive connections between source and target applications for ready use.
5. Data Mapping Considerations
Another key factor to consider is 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 the data synchronization should not be considered as a one-time task. It is really a process which needs to be planned, owned, managed, scheduled and controlled.The requirement today is that the systems are real time, Main challenge with real time data synchronization is to work with systems which 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 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, mapping and give an consent to Actual 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.
Defining Integration, Business Requirements, Managing Software Version, Customising Core System, Data Mapping, Data Synchronisation, QA Process, Plan of Go-Live, Go-Live
Through the compilation of practices based on the available reference models and an understanding how these can help, any organization can adapt and customize as per their project requirement . DBSync is one such ideal platform which follows all of the aforementioned steps.