SPAN. White Paper. Enterprise Application Integration. Introduction

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.

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.

 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 applicaintegra-tion integraintegra-tion. The following section depicts the evolution of EAI from the most traditional point-to-point integra-tion to the most popular bus architecture of integraintegra-tion.

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

Enterprise Application Integration

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

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

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.

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 Reporting Billing &

HRMS

ERP

SCM

CRM

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 integraorganiza-tion soluorganiza-tion. 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 existcontinu-ing systems while pluggcontinu-ing 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 integratadopt-ion 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 Enterprise Application 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

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

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

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.