Whitepaper [2009] ESB oriented integration landscape

Whitepaper

Author: Ritesh Arora Email: [email protected]

Department: EAI & BPM Team Company Wipro technologies

ESB Oriented Integration Landscape - A Business

Analysis

ESB Oriented Integration Landscape - A Business Analysis

Whitepaper Page 2 of 15

Table of Contents ABSTRACT...................................................................................................................................3 CURRENT STATE OF ENTERPRISE APPLICATION INTEGRATION .......................................................4 DRIVERS FOR SERVICE ORIENTED INTEGRATION............................................................................6 PLANNING FOR SUCCESSFUL AND AGILE ‘SERVICE ORIENTED INTEGRATION’ ...................................9 COMPARATIVE ANALYSIS - MIDDLEWARE BASED-ESB TRANSCENDENTAL AND ESB PRODUCT BASED ARCHITECTURE ...............................................................................................................10 CONCLUSION .............................................................................................................................14



Abstract

This whitepaper provides a comparative analysis of ESB Transcendental* Architecture as well as ESB product suites based architecture, to help choose a right Integration framework for Enterprise Organisations. It also covers the key drivers that are shaping the paradigm shift towards service oriented enterprise integration, by highlighting the technical and business challenges associated with the traditional integration programmes on organisation and programme level.



Current State of Enterprise Application Integration In the current scenario, enterprise integration is plagued with multiple issues that are resulting is excessive expenditure leading to under achievement of business goals of the organisations. The following diagram depicts a real life integration case study that highlights the peril of the point to point integration solution with its own flavour of connectivity leaving the organisations with the silos of proprietary integration domains

Figure 1: A Real life integration case study



The section below highlights various business and technical challenges with the current integration scenario, out which some of them may factor for resulting in integration architecture like one mentioned above.

Planning challenges • Obtaining the executive buy in and budget allocation challenges • Ineffective communication/translation of business goals from business to IT teams and vice -versa • Autonomous culture – business units/divisions making their own technological decisions • Lack of awareness regarding formal IT value management • Cost versus profit centre identification

Technical challenges • Lack of standard adoption • Vendor lock-in • Proprietary development interfaces and technologies (COM,DCOM,CORBA,MOM, J2EE, .NET etc) • Need for specialised, skilled and therefore costly resources • Promotes brittle and tightly coupled architecture. Changes in one application impacts others • Inadequate health monitoring of the information flow and therefore more time required for operational

diagnostic • No common and standard based uniform security model



Drivers for Service Oriented Integration Certain business and technical drivers are shaping up the new integration trends in the market to promote service oriented integration. The following section details those drivers and how they are promoting the need for service oriented integration. In the section below, these drivers have been detailed on their business and technical aspects

Business Aspect

Enforcement from regulatory compliances

Large enterprise organizations are subject to more oversight from more regulatory bodies than ever before. To keep up with regulations-such as Sarbanes-Oxley, the Patriot Act, and Check 21 in the U.S.; and MiFID, SEPA, and JSox, organisation must figure out how to build the internal infrastructure to retrieve business data in quick and detailed way than ever before.

New competition from deregulation

Deregulation has increased competition within the single industry vertical. A good example of the same could be financial services sector. Relaxing the rules has enabled consumer banks, for example, to move beyond deposit and lending services into selling investment products once offered only by other financial institutions. This dive into the other areas forces the existing organisation to offer more products to the market thereby accelerating the need for integration.

External industry vertical firms emerge as challengers

Competition is also arising outside the industry vertical. An example of the same could be wireless carriers, such as NTT DoCoMo in Japan, add direct payment technology to mobile phones, they become de facto players in the credit card arena. Retailers such as Wal-Mart also take business from traditional financial service providers. In the last couple of years these big-box companies are taking increasing steps to enter the consumer banking market.

Ongoing Mergers & Acquisitions



The merger-and-acquisition trend continues among services firms, presenting significant challenges that demand a high degree of agility. Figuring out how to integrate customers, cross-sell products to existing and acquired customers, and eliminate redundancies, requires newly merged companies to make the right moves, and make them swiftly.

Need for single view for customers and cross selling

In the current market, any service firm would be drawing large customer attention that is able to provide a single view to its customer applications. This not only helps the customer from keeping track of their existing services, it also enables them to see the other related services that the organisation is offering and their relation to the existing services. In the similar capacity, it is helpful to the organisation to sell more of its services/products to the customers thereby promoting a win-win situation, both for the customers and the enterprise

For example Mortgages and Retail banking should be accessible to the customers from single interface.

High Agility

The competition is arising as more and more companies are able to ship their products faster than competitors. Therefore having a very flexible infrastructure to promote and support business agility is one of the critical business factors.

Technical Aspect

Adoption of open market standards.

The current focus is on adopting the open market standards to promote higher interoperability, reduce cost and reduce dependency. More proprietary the technology is, more inflexible it is to change and therefore it directly impacts the business agility as well as increases cost income ratio.

Scalability and Flexibility

In the event of unexpected volume, the infrastructure should be able to scale up in no time. At the same time, it should be flexible enough to support new business/technical requirements as per needs. Currently the integration products provide restricted support to the vertical and horizontal scalability. Also the current fray of integration



product offers more of development promotion than configuration promotion which requires more effort and therefore more time and cost

Disaster Recovery

Regulatory requirements from the centralised bodies have enforced the implementation of disaster recovery of critical business process to minimise outages and to ensure high availability. Additionally, in the current competitive scenario, it is imperative for an organisation to provide availability of its customer centric operations as much as possible. Therefore it is important to plan and implement the disaster recovery for critical business processes.

For the same, there has to be effective business process management around critical data processes. Also more transparent and distinct the service distribution is, easier it is for operations management to troubleshoot it.

Vendor lock in

Vendor lock-ins hampers the inter-operability as well as agility in a serious manner. The various back-end legacy applications/systems have been built using proprietary technologies/tools and are widely in use. Most of the enterprise organisations that integrated their enterprise solutions in the last decade, using the proprietary technology, have been facing the hazard and challenges of vendor lock-in.

Service Reuse

As the size of a company grows, the complexity of the IT applications typically increases. Subsequently, as the number of applications reaches a critical size, the cost income ratio starts getting impacted by the operational maintenance of those large numbers of applications iif there is no service reuse strategy designed. Therefore it is very important to define common infrastructure architecture with high service reuse index and SOA-XML based common information model. High service reuse based upon such framework not only helps in lowering the cost income ratio (from technical perspective) but also promotes easy maintenance and expedited operational diagnostic



Planning for successful and agile ‘service oriented Integration’

In order to deliver a successful integration programme, there has to be pre-emptive planning and governance around all the check points. The following are the key aspects that need to be considered for service oriented integration planning to ensure a successfully delivery for integration programmes

Business aspects

ü Need for Business and IT Alignment. Formulate a centre of excellence and ensure the participation of IT members in the decision making (budget, timelines, tool, product etc)

ü Establishing a clear line of accountability and ownership for business and IT entities

Technical aspects

ü First Consolidation, then Integration ü Enforcing a service oriented integration architecture ü Ensure a balance between loose-coupling and performance ü Early testing ü Re-factoring interfaces constantly



Comparative Analysis - Middleware based-ESB Transcendental and ESB product based Architecture

This section consists of the comparison and approach assessment between ‘ESB Transcendental’ Vs ESB products based Architecture to help IT architects and business teams to arrive at the solution that suits best to their business and technical needs. Both of above mentioned approaches come with their set of advantages and disadvantages

Middleware based-ESB Transcendental Architecture

Middleware based-ESB Transcendental Architecture is the integration architecture middleware architecture with the interfaces exposed as web services/services to facilitate market open standard and service based connectivity. As a part of transcendental framework, it hosts best of breed third party products to provide business process orchestration management and monitoring, service location and distribution, security management and other ESB features. An example of above could be using an IBM MQ based middleware, having a Weblogic application server to provide SOA functionalities and finally, fabricating middleware layer with BPM/BAM and SOA suites would give rise to ‘ESB Transcendental’. The diagram mentioned below shows the different products providing different functionality of ESB (Integration, SOA functionality and Business process management ) and all the functionalities fabricated together to give rise to a ESB Transcendental architecture



ESB product based Architecture

There are certain products in the market that have been built upon SOA and Webservices architecture from the ground up. To name a leading few of them would be

• Cape clear • BEA • Fiorano • BEA • IONA • Polarlake

The above mentioned products promote componentisation and have the built in functionality for providing end to end ESB functionality with the single framework. They are capable of providing integration, transformation, routing (static

Application Server

Middleware

System Admin services

Application Server

Portal server

Figure 2: Disparate yet fabricated ESB ‘ Transcendental’ Architecture

Portal server



and dynamic), service invocation and invocation and business process orchestration & management and more features service oriented integration features.

Pros The following sections details the pros of both ESB transcendental architecture as well as ESB product based architecture

Middleware based ESB-transcendental implementation ü Building the IT landscape with ü Best of breed service based products (BPEL Engine, Application server et al) on top of existing middleware

solution ü Promotes plug-play of Service components ensuring flexibility ü Promotes selective need based usage ensuring low cost and effective usage. ü Need not install the complete product stack

Figure 3: ‘ESB product based’ Architecture



ü More suited for small integration solutions with less budget

ESB product based implementation

ü Standard based Integration ü Highly distributed Integration and selective deployment ü Distributed data transformation ü Promotes plug-play of best of breeds components ensuring flexibility ü Integrated BPM ,BAM and event driven SOA

Cons The following sections details the limitations of both ESB transcendental architecture as well as ESB product based architecture

Middleware based ESB-transcendental implementation ü Non-centralised control of various components/engines ü Different security models for all the components ü No common ground on which to build enterprise wide best practices

ESB Product based implementation ü Not time tested in the market ü Requires complete product stack to be installed ü Based upon certain standards/specifications that are still evolving ü By and Large, difficult to build up a viable business case and obtain

executive sponsorship as to why ESB product implementation should be preferred over already running EAI and cheaper ‘ESB like’ solution

ü Different definitions of ESB promoted by different products and even further different definitions promoted by IT architects



Conclusion Both the above mentioned approaches have been practiced by IT managers and have been successfully implemented and both of them come up with their share of advantages and disadvantages. It is up to the business and IT teams to weigh/evaluate the above mentioned advantages and disadvantages against the following business goals and plan the strategy accordingly. The business goals that needs to be considered are

ü Degree of regulatory compliance needed – Short term and Long term ü Cost Vs Income ratio ü Time to market the new services and products ü Security and Confidentiality needed for critical business process ü On demand capacity

About the Author Ritesh Arora is working as EAI consultant in EAI & BPM team in Wipro technologies. He has experience in architecting, designing and implementation integration solutions using multiple tools and technologies for various industry vertical. His earlier whitepaper on Enterprise Service Bus in Telecommunication domain can be accessed at IT research page of Forbes at http://itresearch.forbes.com/detail/RES/1129898582_86.html For any queries/question regarding the whitepaper, he can be reached at [email protected]

About Wipro Technologies Wipro Technologies is a global services provider delivering technology-driven business solutions that meet the strategic objectives of our clients. Wipro has 40+ ‘Centers of Excellence’ that create solutions around specific needs of industries. Wipro delivers unmatched business value to customers through a combination of process excellence, quality frameworks and service delivery innovation. Wipro is the World's first CMMi Level 5 certified software services company and the first outside USA to receive the IEEE Software Process Award.



References

1. Integration consortium http://www.integrationconsortium.org

Acknowledgment During the course, when this whitepaper was being written, I would like to acknowledge the guidance from Srinivas Deshpande, who has always motivated the team to perform better every time. Also I would like to thank Hemendr Kumar, my colleague, with whom, rounds of informal technical discussion seeded the thought of this whitepaper

Technology

Whitepaper [2009] ESB oriented integration landscape