Why Choose ESB Based Integration Platform

ALM / SDLC Tool Integration Approaches

Point-to-Point Integration

Point-to-point Integration

Single Vendor Tools Integration

Single Vendor Integrated ALM Tools

Enterprise Service Bus

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.

Point-to-Point Integration

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.

Enterprise Service Bus Architecture

How Kovair Omnibus tool works

Kovair Omnibus Integration Framework is SOA-based and applies its own ESB based integration technology to provide bi-directional synchronization between best-of-breed ALM and IT tools. It enables setting up of various Omnibus adapters for integration with various tools being used in the environment. The dataflow between these tools can be completely configured by the end user though the Kovair application.

Value Proposition with ESB based Integration Solution

Easy accessibility

An ESB-based integration platform must support common tools that application developers are familiar with, such as Maven, JUnit, Eclipse, and Spring. It should also provide the option to write custom codes in a variety of languages, such as Java, JavaScript, Python, Ruby, and Groovy.

Solution beyond mediation

An ideal ESB solution does not start with or end at coupling separate ALM or IT tools. It should not be driven by a vendor-specific bus technology. The users must be able to use both synchronization and a linking model as it fits in their particular use case. There is no point in considering an ESB model as a combination of separate products for hosting business logics and publishing services.

Support for OSLC

Not all ALM tools act as providers for Open Services for Lifecycle Collaboration while integrating with Jazz-based IBM Rational tools such as Rational Requirements Composer, Rational Team Composer, and Rational Quality Manager. The integration platform must enable users to view, manage, and track artifacts of non-OSLC tools from the new-generation IBM Jazz tools by using the bus technology.

Lightweight integration

The benefits of using an integration platform weighing less than 40 MB are many. A lightweight container model hosts integration components as remote services and allows you to strip out unnecessary modules as per the integration needs. This also helps control the cost of making changes to existing integrations. Modularization, quick deployment, and ease of configuration are among the other essentials.

Easy referencing of services

The distributed service architecture of an ESB acts as an interconnected system of lightweight service containers, which allows users to configure, deploy, manage, and monitor remote services. These service containers provide scalability, security, and consistent availability as well as ensure quality of service throughout an application lifecycle. A coherent piece of ESB infrastructure must perform all kinds of activities for external and internal services.

100 percent web-based

Whether a project is developed on premise or on the cloud, developers should feel no difference in working on either. A cloud-ready integration platform should not limit its capability to facilitating integrations between applications. The objective is to create a platform that supports application development as well as integration between tools—the way platform as a service works.

Open messaging models

Though XML is the preferred format of messaging in any ESB model, users may still need to use Cobol Copybooks, JSON, flat files, streams, Java objects, binary, and file attachments for message queuing and publishing or subscribing. The graphical data mapper of an ESB product should be open to all kinds of data.

Support for long-running business processes

Transforming a significant volume of data through a service bus as a large number of individual messages is often problematic. Ideally, BPEL and BPMN technologies are used to implement stateful business processes. However, a good ESB solution must support this for stateless message flow.

Process management across tools

Not all ALM tools have their own process-mapping capabilities. However, it is of utmost importance that a developer can view how an event occurring in one tool triggers the process diagram, which in turn modifies the status of the other related artifacts in other connected tools. An integration platform that includes workflow management can automatically generate tasks for users based on their roles, availabilities, and the required plan of actions.