ALM / SDLC Tool Integration Approaches

Point-to-point Integration

Single Vendor Integrated ALM Tools

ESB Based Tool Integration
Comparison of Integration Approaches
Item | Point-to-point Integration | Single Vendor Integration | ALM Integration Platform |
View artifacts managed by one Tool from another Tool | Medium – Fair | High – Good | Very High – Excellent |
Create relationship between any two Artifacts | Limited – Fair | High – Good | Very High – Excellent |
Automate a process cutting across the tool boundaries | None – Poor | Limited – Fair Hard coded | Very High – Excellent |
Manage Projects and Resources across the tools | None – Poor | Limited – Fair | Very High – Excellent |
Create Cross tools Analytics and Dashboards | Limited – Fair | Limited – Fair | Very High – Excellent |
Effort to create and maintain integration with a tool | Very High – Poor | Medium – Good | Low – Excellent |
Utilizing existing tools | Very High – Excellent | Low – Poor | Very High – Excellent |
Migration and Training Effort | Low – Excellent | Very High – Poor | Low – Excellent |
Point-to-point Integration
Though apparently simple, point-to-point integration is fraught with the following major problems:
Complexity of combinations:
In order to have a point-to-point integration between every pair of n tools, we need n x (n-1) / 2 number of integrations. It thus becomes extremely difficult to create and maintain each individual integration code between the pairs of tools.Handcrafted business integration rules, and replacement dilemma:
Business rules of integration are all hardcoded in the integration code. This means that any change in that logic necessitates changes in that code. Any change in code means a full cycle of development, test, and deployment cycle making it impossible to implement even the smallest change quickly.
Further, replacement of any tool by another tool of same function or even by a new version will involve high effort maintenance of all the integration code for that tool.

Single vendor Tools Integration
Integration tools, based on this approach, have the following major limitations:Rip and Replace:
The requirement of replacing existing tools by a single vendor tools does not sit well with any development manager.Limitation in Tool Usage:
All the tools from a single vendor are pre-integrated, therefore do not allow one to use best-of-breed tools. Moreover, you have less control over integration rules.One Size Fits All :
It is highly unlikely that built-in tools from a single vendor can serve the needs of a wide range of development groups. However, due to the very nature of the solutions, the users are forced to use these tools even when better and often less expensive (sometime free open source) tools are available and appropriate for their needs.Technology Islands of Development:
Single vendor integration tools create a technology island with little or no chance of working together.Multi Vendor Best of Breed Integration Tools
Integration tools, based on the ALM platform approach of multi-vendor tools integration, do away with complex and costly integrations, overcoming the limitations of the above two approaches.
Kovair Omnibus Platform applies its own ESB based integration technology to provide bi-directional synchronization between best-of-breed ALM tools. Enterprise Service Bus (ESB) based architecture is built with server side integration in mind. ESB is the foundation of Cloud based and on-premise integration technologies – as mentioned by Gartner. It enables enterprises to realize the value of SOA by reducing complexity in integrating applications and providing better control on tool usage.
ESB architecture complements all the core principles of integration such as Orchestration, Transformation, Transportation, Mediation and Event Handling. It facilitates complex event processing; provides support for synchronous and asynchronous transport protocols; validates messages; governs business rules and provides interoperability between applications irrespective of operating systems and programming languages used in each of the tools.
This eliminates point-of-contact to and from each application, takes part in seamless message exchange between applications and thus enabling communications across stakeholders, toolsets and their locations.
