SPAN White Paper 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, (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.
Need for 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. Asset Management GRC Business Partners/Vendors Application Databases Portals Environment Enterprise HR Communication Finance Supply Chain Packaged Third-Party Applications EAI Internal Applications 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 () 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 applications. This has helped package vendors and enterprises realize the importance of applications integration to face the daunting tasks ahead.
Define Design Implement Deploy Support Vendors Customers Business Process Layer Messaging Layer Suppliers Web Portals EAI 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.
Billing EAI Billing HR HR Fully Meshed point-to-point connections N(N-1)/2 Simplified N Connections Reduction of integration complexity from N(N-1)/2 to N 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 CMS Billing & HUB Billing HR 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.
Point-to-Point Hub and Spoke Enterprise Service Bus CMS Spoke Billing & CMS Runtime Engine Routing Billing & Mediation HUB Integration HRMS Billing HR Security HRMS Invocation Standard Based 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.
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. Traditional Integration Point-to-Point connection between applications Simple basic connectivity Used messaging Enterprise Application Integration Connects Application using Centralized hub Easier to manage larger number of connections Service Oriented Integration Integration and choreography of services through service bus Flexible connections with welldefined standardbased Interfaces Interoperability Flexibility Reusability Evolution Trends of
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 and 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
In SPAN, we use the following lifecycle from the commencement of any Enterprise Application Integration project till its delivery, and support. Business Focus Presales Estimation Proposal and Contract Sign-off Requirement Specification Req. Management & Sign-off Req. Modeling Functional Specification Functional specs & Sign-off Concept visualization Environment Setup Infrastructure setup Application Management setup Configuration Management setup Test Strategy Initiate Middleware Test Strategy Middleware Test Design Middleware Test Data Design High-Level Design Process Simulation Concept Visualization Detailed Design 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 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 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.
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). www.spansystems.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 >>> 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. A part of the Nordic IT group EVRY