enterprise application integration

Enterprise Application Integration

White Paper Enterprise Application Integration

Introduction

Earlier, automation was custom developed. But today, all the tasks are executed through

packaged applications that have reduced software development significantly. It makes Infor-

mation Technology critical for successful functioning of several enterprises to automate

business processes. The requirements for the next-generation software systems mandate the

integration of these stovepipe applications with new forms of business logic.

The term, “Enterprise Application Integration” (EAI) is the recent entrant into the jargon of the

active software industry. It represents the task of integrating various applications so that infor-

mation and processes can be shared freely. Thus, EAI is the creation of robust and elegant

business solutions by combining applications using common middleware and other viable

technologies. With these realizations, EAI was created by industry analysts to help information

technology organizations understand the emergence of a unique software solution that

eliminates the bottlenecks of integration.

Starting with a brief history of the origins of EAI, we'll walk through all the major developments

in the EAI architecture, and learn how traditional "hub and spoke" broker-based EAI systems

are now being replaced by agile, distributed, standards-based Enterprise Service Bus

architectures.

SPAN


Need for Enterprise Application Integration

Enterprise architectures consist of many systems and applications that provide various services a

company relies upon to conduct its day-to-day business. An organization may choose to

implement separate systems, either a third-party licensed version or an in-house version to

effectively manage its customer relationships, supply chain, business logic and employee

information. Segregating business tasks into a number of sub-functionalities enables for simplified

implementation of latest technologies in diverse areas, and adapt to evolving business

requirements.

Problems presented by Enterprise Architecture

Interoperability: Various components of the infrastructure may use different operating

systems, data formats, and languages, preventing connection via a standard interface.

Data integration: For a modular, distributed system to be functional, a standard method of

handling the flow of data between applications and systems to enforce consistency across the

database is crucial.

Robustness, Stability and Scalability: These are the functions that hold together a modular

infrastructure, and hence, integration solutions must be highly robust, stable, and scalable.

Standalone Enterprise applications to Integrated Enterprise Applications

Another important factor that is driving enterprises toward the promised land of EAI is the broad

acceptance of packaged applications, such as Enterprise Resource Planning (ERP) applications.

These, called as stovepipe applications that address and solve very narrow problems within

departments, have ruled several functions in enterprises for a long time. It has been found that EAI

has the wherewithal to link many disparate systems including ERP applications. This has helped

package vendors and enterprises realize the importance of applications integration to face the

daunting tasks ahead.

Enterprise

GRC

Commu-nication

Environ-ment

Asset Manage-

ment

Finance

CRM

HR

Supply Chain

EAI

Business Partners/Vendors

Application

Portals Databases

Internal Applications

Packaged Third-Party Applications


Reduced time to market

Enhanced performance and reliability

Extension of the legacy system lifecycle

Reduced development and maintenance costs

Implementation of a centralized information bus

EAI Approaches and Techniques

As an enterprise consists of many heterogeneous systems, organizations had started integrating

applications in the most naive form, connecting each application with every other application. But,

as the volume and complexity of applications to be integrated was increasing, traditional integra-

tion techniques were evolved to take maximum advantage of the concept of application integration.

The following section depicts the evolution of EAI from the most traditional point-to-point integra-

tion to the most popular bus architecture of integration.

Traditional Integration

Point-To-Point Integration

In a point-to-point integration model, a unique connector component is implemented for each pair

of applications or systems that must communicate. This connector handles data transformation,

integration, and any other messaging related services that must take place between only a specific

pair of components.

When used with small infrastructures, where only two or three systems must be integrated, this

model can work quite well, providing a lightweight integration solution tailor-made to meet the

needs of the infrastructure. However, as additional components are added to an infrastructure, the

number of point-to-point connections required to create a comprehensive integration architecture

begins to increase exponentially.

Vendors

Customers

Suppliers

Web Portals

Warehouse

Legacy Applications

Custom Applications Partners Process People Data Applications

EAI

Messaging Layer

Database Layer Application Layer

Business Process Layer

Define | Design | Implement | Deploy | Support

Also known as ‘middleware’, EAI provides the infrastructure to connect information sources, acting

as a go-between for applications and their business processes. In implementing EAI solutions,

organizations have been able to understand its various benefits such as:



To avoid the complexity and fallibility of integrating complex infrastructures using the point-to-point

approach, EAI solutions use various models of middleware to centralize and standardize integra-

tion practices across the entire infrastructure.

Rather than each application requiring a separate connector to connect to every other connector,

components in an EAI-based infrastructure use standardized methods to connect to a common

system that is responsible for providing integration, message brokering, and reliability functionali-

ties to the entire network.

EAI loosens the tightly coupled connections of point-to-point integration. With the help of EAI, an

application can send a message without any details such as knowledge of the consumer's location,

data requirements, or use for the message. This allows for a more flexible architecture, where new

parts can be added and removed as needed, simply by changing the configuration of the EAI

provider, and simplified modular development, where a single service can be reused by multiple

applications.

EAI

SCM

HR

Billing

Re-porting

ERP

CRM HR

ERP

SCM

CRM

Billing

Re-porting

Fully Meshed point-to-point connections N(N-1)/2 Simplified N Connections

Reduction of integration complexity from N(N-1)/2 to N

HR

ERP

SCM

CRM

Billing

Re-porting

HUB

CMS Billing & Re-porting

CRM

HRMS

ERP

SCM

Connectors


Pros

Loose coupling between applications, which means that applications are able to communi-

cate asynchronously.

Less repetitive configuration i.e. all integration configuration to be accomplished within a

central repository.

Cons

HUB becomes a single point of failure for the network.

Under heavy loads, the broker can become a bottleneck for messages.

Broker models are often heavyweight, proprietary products, aimed at supporting a specific

vendor.

Hub & Spoke / Broker Model

This approach involves a HUB - a central integration engine that resides in the middle of the net-

work, and facilitates message transformation, routing, and any other inter-application functionality.

All the communication between applications must flow through the hub, allowing it to maintain data

concurrency for the entire network.

Typically, implementations of this model also provide monitoring and auditing tools that allow users

to access information about the flow of messages through their systems. Other tools are also used

to speed up the complicated task of configuring mapping and routing between large numbers of

systems and applications.

Bus Architecture - A New Approach to EAI

In an attempt to eliminate the problems caused by a brokered hub and spoke EAI approach, a new

EAI model emerged - the bus. The bus architecture is sought to lessen the burden of functionality

placed on a single component by distributing some of the integration tasks to other parts of the

network.

These components could then be grouped in various configurations via configuration files to

handle any integration scenario in the most efficient way possible. It could be hosted anywhere

within the infrastructure or duplicated for scalability across large geographic regions.

The Enterprise Service Bus Is Born

As the bus-based EAI evolved, a number of other necessary functionalities were identified, such as

security transaction processing, error handling, and more. Rather than hard-coding these features

into the central integration logic, as required by the broker architecture, the bus architecture allows

these functions to be enclosed in separate components.

The ultimate result - lightweight, tailor-made integration solutions with guaranteed reliability, which

are fully abstracted from the application layer, follow a consistent pattern. These solutions can be

designed and configured with minimal additional code with no modification to the systems that

need to be integrated.

This mature version of the bus-based EAI model eventually came to be known as the Enterprise

Service Bus, or ESB.


Core ESB Features

There are a number of different ESB products available in the market today. Some, such as the

WebSphere Message Broker or the TIBCO Business Works, are traditional EAI products that have

been re-factored to offer ESB-like functionality, but still function in a broker-like manner. Others,

such as MuleSoft's Mule ESB, Oracle ESB, OSB, JBoss ESB, Sonic ESB, are designed from the

ground up using open messaging and integration standards to implement the ESB model.

Despite the differences, most ESBs include all or most of the following core features / services:

Location Transparency: A way of centrally configuring end-points of messages, so that a

consumer application does not require information about a message producer to receive

messages.

Transformation: The ability of the ESB to convert messages into a format that is usable by

the consumer application.

Protocol Conversion: The ESB must be able to accept messages sent in all major protocols,

and convert them to the format required by the end-consumer.

Routing: Capacity to determine the appropriate end-customers based on both pre-configured

rules and dynamically created requests.

Enhancement: The facility to retrieve missing data among incoming messages, based on the

existing message data, and, append it to the message before delivering to its final destina-

tion.

Monitoring / Administration: The goal of ESB is to make integration a simple task. As such,

an ESB must provide an easy method of monitoring the performance of the system, the flow

of messages through the ESB architecture, and a simple means of managing the system, in

order to deliver its proposed value to an infrastructure.

Security: ESB security involves two main components - making sure that the ESB itself

handles messages in a secure manner, and negotiating between the security assurance

systems used by each of the systems that will be integrated.

HR

ERP

SCM

CRM

Billing

Re-porting

HUB

CMS Billing & Reporting

CRM

HRMS

ERP

SCM

Spoke

Enterprise Service Bus

Routing

Mediation

Integration

Security

Invocation

Standard Based

Runtime Engine CMS

Billing & Reporting

HRMS

ERP

SCM

CRM

Point-to-Point Hub and Spoke


The Advantages of ESB

Here's a look at the advantages offered by an ESB approach to application integration:

Lightweight: An ESB comprises of many interoperating services, rather than a hub that

contains every possible service. ESBs can be as heavy or light as an organiza-

tion needs them to be, making them the most efficient integration solution.

Easy to expand: If an organization needs to connect additional applications or systems to its

architecture, an ESB allows it to integrate all of its systems easily instead of

worrying about whether or not a new system will work with the existing infrastruc-

ture. When the new application is ready, the organization needs to hook it up to

the bus to get it working with the rest of its infrastructure.

Scalable and Distributable: ESB functionality can easily be dispersed across a geographi-

cally distributed network as needed. Additionally, as the individual components

are used to offer categorical features, it is much simpler and cost-effective, and

ensures high availability and scalability for critical parts of the architecture.

SOA-Friendly: ESBs are built with Service Oriented Architecture in mind. This implies that an

organization seeking to migrate towards SOA can do so incrementally, continu-

ing to use its existing systems while plugging in re-usable services while

implementing them.

Incremental Adoption: At a first glance, the number of features offered by the best ESBs can

seem intimidating. However, it is best to think of the ESB as an ‘integration

platform’, of which you only need to use the components that meet your current

integration needs.

A large number of modular components offer unrivaled flexibility that allows incremental adopt-

ion of integration architecture as the resources become available, and helps meet unexpected

futuristic needs.

Integration and choreography of services through service bus

Flexible connec-tions with well- defined standard- based Interfaces

Traditional

Integration


Service Oriented

Integration

Point-to-Point connection between applications

Simple basic connectivity

Used messaging

Connects Applica-tion using Centralized hub

Easier to manage larger number of connections

Interoperability Flexibility Reusability

Evolution Trends of Enterprise Application Integration


When to Use an ESB?

Making Informed EAI Decisions

All the integration solutions have strengths and weaknesses, often attributable to the environment

in which they are deployed. For this reason, making informed decisions about the EAI strategy to

be used is vital to the success of your integration initiative.

The Advantages of ESB

Before an organization makes a decision about EAI, it is important to considers questions like:

How many applications do I need to integrate?

Will I need to add additional applications in the future?

How many communication protocols will I need to use?

Do my integration needs include routing, forking, or aggregation?

How important is scalability to my organization?

Does my integration situation require asynchronous messaging, publish / consume

messaging models, or other complex multi-application messaging scenarios?

SPAN EAI Lifecycle

SPAN extensively works on various integration projects using a wide variety of integration tech-

niques, with solutions ranging from integration of legacy applications in mainframes to most

popular ERP and CRM applications.

Solutions are developed using a wide variety of tools available for application integration.

Oracle Service Bus

Open ESB

GlassFish ESB

Mule ESB

Java Caps

SeeBeyond Integrator

BizTalk Server


Conclusion

Irrespective of the journey, one must plan each step carefully in order to reach the desired

goal. The same holds true for implementing an Enterprise Application Integration solution. The

following checklist must be kept in mind while choosing EAI:

Clear ownership of the overall program and identification of the business case must be

established.

Comprehensive business process and technology architecture reviews must be

conducted.

Consolidation and integration should be executed in steps.

Management of an EAI solution’s design, development, and deployment carry equal

importance as the solution.

Post-deployment periods must be tightly controlled to ensure current and future viability of

the integrated environment.

Appropriate technologies must be brought in to support the business needs.

Of these technologies, Application Server Platforms stand ready to provide a common, stand-

ardized foundation upon which highly integrated applications may interact. By leveraging on

the existing business and technology assets, resources, and, supplementing wherever appro-

priate with new business processes, the technologies and resources become extremely neces-

sary to complete the job successfully. In today’s organizations, highly workable enterprise inte-

gration has become more realistic and achievable.

In SPAN, we use the following lifecycle from the commencement of any Enterprise Application

Integration project till its delivery, and support.

Functional Specification

Functional specs & Sign-off Concept visualization

Business Focus

Presales Estimation Proposal and Contract Sign-off

Requirement Specification

Req. Management & Sign-off Req. Modeling

Coding

Develop framework Configure Implement & Unit test Code Maintenance

Testing

Test Data Preparation Integration testing UAT support

Production Rollout

Checklist Preparation for different phases

Post-Production Support

Design

High-Level Design Process Simulation Concept Visualization Detailed Design

Test Strategy

Initiate Middleware Test Strategy Middleware Test Design Middleware Test Data

Environment Setup

Infrastructure setup Application Management setup Configuration Management

setup

Enterprise Application Integration A part of the Nordic IT group EVRY

For more information on our entire range of solutions and related offerings, get in touch with SPAN at: [email protected]

About SPAN: SPAN is an established Software Services Company offering comprehensive IT services since 1994. Our clients include Fortune 1000 companies, Independent Software Vendors and start-ups. SPAN’s Offshore Development Center in India is CMMI Level 5, PCMM Level 3, ISO 9001:2008 and ISO 27001:2005 certified. SPAN has a global footprint with offices in the US, Europe and India. There are multiple offshore development centers in Bangalore and Chandigarh, India. SPAN is ranked #7 Best IT Employers in India by a leading IT publication. SPAN’s Relationship Management (RM) Model is a well-defined, yet flexible framework, which provides ongoing business value to both, the client and SPAN. SPAN is wholly owned by $2.3B Norwegian IT services major EVRY (www.evry.com).

About the Author

Anjali Gupta is a leading EAI consultant with over 7 years of experience in the IT

industry. She has extensively worked on Java and has delivered projects for

many clients in the software, healthcare, postal services, and real estate sectors.

Anjali has international exposure through her work at client sites in the US and

Norway. Presently, she leads the integration team in SPAN Chandigarh.

USA Headquarters >>>

SPAN Systems Corporation,

30 Knightsbridge Road, Suite 525,2nd Floor, Piscataway, NJ 08854

Phone: 732-384-3361/1-800-SPAN-SYS,Fax: 732-384-3365

India Headquarters >>>

SPAN Infotech (India) Pvt. Ltd.

18/2, Vani Vilas Road, Basavanagudi, Bangalore 560 004, India

Phone: +91-80- 40219600, Fax:+91-80- 40219632

Copyright © 2014 by SPAN. All rights reserved. The contents of this document are protected by copyright law and international treaties. SPAN acknowledges the proprietary rights of the trademarks and product names of other companies mentioned in this document. The reproduction or distribution of the document or any portion of it thereof, in any form or by any means without the prior written permission of SPAN is prohibited.

www.spansystems.com

mailto:[email protected]

http://www.evry.com

enterprise application integration

Documents