SPAN 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 Information 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 information 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.
Enterprise Application Integration
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.
GRC Asset Management
Business Partners/Vendors Application
CRM Databases
Environment
HR
Enterprise
Supply Chain
Communication
Portals
Packaged Third-Party Applications
EAI
Internal Applications
Finance
Standalone Enterprise applications to Integrated Enterprise Applications
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.
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 Application Integration
Define
|
Design
Vendors
|
Implement
|
Deploy
Business Process Layer
Customers
|
Support
Messaging Layer
Suppliers
EAI
Web Portals Warehouse
Application Layer
Database Layer
Legacy Applications Custom Applications
Applications
Data
People
Process
Partners
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:
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 integration 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 integration 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.
Enterprise Application Integration
SCM
SCM
CRM
ERP
Billing
ERP
EAI Billing
HR
HR
CRM
Reporting
Reporting
Fully Meshed point-to-point connections N(N-1)/2
Simplified N Connections
Reduction of integration complexity from N(N-1)/2 to N
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 integration 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 functionalities 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.
Connectors SCM
Billing & Reporting
CMS CRM
ERP
ERP Billing
HUB
CRM
HR
Reporting
SCM
Enterprise Application Integration
HRMS
Hub & Spoke / Broker Model This approach involves a HUB - a central integration engine that resides in the middle of the network, 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.
Pros
Loose coupling between applications, which means that applications are able to communicate 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.
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. Enterprise Application Integration
Point-to-Point
Hub and Spoke
Enterprise Service Bus
Spoke SCM CRM
CMS
ERP
Billing & Reporting
CMS
CRM
SCM
Runtime Engine
Billing & Reporting
Routing Mediation
ERP Billing
HUB
Integration
HRMS
Security
HR
Invocation SCM
Reporting
HRMS
CRM
Standard Based
ERP
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 destination.
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.
Enterprise Application Integration
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 organization 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 infrastructure. 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 geographically 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, continuing 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 adoption of integration architecture as the resources become available, and helps meet unexpected futuristic needs.
Point-to-Point
Traditional Integration
connection between applications Simple basic connectivity Used messaging
Interoperability
Connects Applica-
Enterprise Application Integration
tion using Centralized hub Easier to manage larger number of connections
Integration and
Service Oriented Integration
Flexibility
Evolution Trends of Enterprise Application Integration
Enterprise Application Integration
Reusability
choreography of services through service bus Flexible connections with welldefined standardbased Interfaces
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 techniques, 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
Enterprise Application Integration
In SPAN, we use the following lifecycle from the commencement of any Enterprise Application Integration project till its delivery, and support. Business Focus
Requirement Specification
Functional Specification
Presales Estimation Proposal and Contract Sign-off
Req. Management & Sign-off Req. Modeling
Functional specs & Sign-off Concept visualization
Environment Setup
Test Strategy
Design
Infrastructure setup Application Management setup Configuration Management
Initiate Middleware Test Strategy Middleware Test Design Middleware Test Data
setup
High-Level Design Process Simulation Concept Visualization Detailed Design
Coding
Testing
Production Rollout
Test Data Preparation Integration testing UAT support
Checklist Preparation for
Develop framework Configure Implement & Unit test Code Maintenance
different phases Post-Production Support
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, standardized foundation upon which highly integrated applications may interact. By leveraging on the existing business and technology assets, resources, and, supplementing wherever appropriate with new business processes, the technologies and resources become extremely necessary to complete the job successfully. In today’s organizations, highly workable enterprise integration has become more realistic and achievable.
Enterprise Application Integration
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.
For more information on our entire range of solutions and related offerings, get in touch with SPAN at: sales@spanservices.com
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). 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 >>>
www.spansystems.com
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.
Enterprise Application Integration
A part of the Nordic IT group EVRY