eai: myths & reality

EAI Myths & Reality Levente Veres 2012.08.30 @ RABS.ro Cluj-Napoca 1

Upload: levente-veres

Post on 30-Nov-2014




0 download


Presentation about Enterprise Application Integration at Rabs.ro.


Page 1: EAI: myths & reality


EAI Myths & Reality

Levente Veres2012.08.30 @ RABS.ro


Page 2: EAI: myths & reality



What is EAI? The True Story.EAI frameworksEAI Patterns & TechnicsToolset on BattlefieldMyths & RealityThe future

Page 3: EAI: myths & reality


Whoami …

What I do :• Design Lead Past:• Solution Consultant• Business Process Management• IT Manager, PM, Developer• System administrator, Freelancer

Hobby:• Reading and apply: Leadership skills, Motivational approaches, Innovations• Continuous learning

Don't tell people how to do things, tell them what to do and let them surprise you with their results.

George S. Patton

Page 4: EAI: myths & reality


Organization vs Enterprise

the organisation is a legal structure, primarily conceptual/physical in nature, defined by rules, roles and responsibilities– the organisation does – it provides action, ‘how?‘

the enterprise is a social structure, primarily emotive/aspirational in nature, defined by vision, values and mutual commitments– the enterprise is – it provides motivation, ‘why?‘

Page 5: EAI: myths & reality


Enterprise Application?

Can you define?

Page 6: EAI: myths & reality


Enterprise Application

EA: is a business application

Complex, Scalable, Distributed, Component based


Used on different platforms

Data centric & user friendly

Stringent on Security and administration

Hundred requirements must be satisfy

difficult to understand or predict

Page 7: EAI: myths & reality


The Story

At the beginning : Data processing focus.

• Collect the data (financial, numeric, statistical)

On the way: Functional focus

• Calculate the salary, bonuses, incomes• Create invoices, generate reports• HR problems resolve (Resource management)• Logistical/Provisional problems resolve (ERP)

At the end: Process Focus• Enhance the business efficiency (BPM) • Predict more accurate the Income/Outcome (BPO) • Smart and fast decisions (BI)

Page 8: EAI: myths & reality


EA base domains

Business architecture Information system architecture

Data architecture (IS) Application architecture (IS)

Technical architecture.

Page 9: EAI: myths & reality


The Time Line

development of information architecture by P. Duane (Dewey) WalkeThe architectural documents base of Business Systems Planning (BSP)

1960A Framework for Information Systems Architecture” developed by John Zachman at IBM; published in 1987.

1980Extending and Formalizing the Framework for Information Systems Architecture" John F. Sowa and John Zachman

1992TAFIM -> ‘95 TOGAF (The Open Group Architecture Framework)

1991OBASHI framework for Business and IT digrams (Ownership,Business, Process, Application, System, Hardware, Infrastructure)


Department of Defense Architecture Framework


Zachman Fram


Page 10: EAI: myths & reality


The Zachman Framework

Why The

motivation description


The time description

Who The people description


The Network description

How The function description


The data description

Focus on fundamental questions




• (Why) Goal List – primary high level organization goals• (How) Process List – list of all known processes• (What) Material List – list of all known organizational entities• (Who) Organizational Unit & Role List – list of all organization units, sub-units, and identified roles• (Where) Geographical Locations List – locations important to organization; can be large and small• (When) Event List – list of triggers and cycles important to organization


• (Why) Goal Relationship Model – identifies hierarchy of goals that support primary goals• (How) Process Model – provides process descriptions, input processes, output processes• (What) Entity Relationship Model – identifies and describes the organizational materials and their relationships• (Who) Organizational Unit & Role Relationship Model – identifies enterprise roles and units and the relationships between them• (Where) Locations Model – identifies enterprise locations and the relationships between them• (When) Event Model – identifies and describes events and cycles related by time


• (Why) Rules Diagram – identifies and describes rules that apply constraints to processes and entities without regard to physical or technical implementation• (How) Process Diagram – identifies and describes process transitions expressed as verb-noun phrases without regard to physical or technical implementation• (What) Data Model Diagram – identifies and describes entities and their relationships without regard to physical or technical implementation• (Who) Role Relationship Diagram – identifies and describes roles and their relations to other roles by types of deliverables without regard to physical or technical implementation• (Where) Locations Diagram – identifies and describes locations used to access, manipulate, and transfer entities and processes without regard to physical or technical implementation• (When) Event Diagram – identifies and describes events related to each other in sequence, cycles occur within and between events, without regard to physical or technical implementation


• (Why) Rules Specification – expressed in a formal language; consists of rule name and structured logic to specify and test rule state• (How) Process Function Specification – expressed in a technology specific language, hierarchical process elements are related by process calls• (What) Data Entity Specification – expressed in a technology specific format; each entity is defined by name, description, and attributes; shows relationships• (Who) Role Specification – expresses roles performing work and workflow components at the work product detailed specification level• (Where) Location Specification – expresses the physical infrastructure components and their connections• (When) Event Specification – expresses transformations of event states of interest to the enterprise


• Rules detail for (Why);• Process detail for (How);• Data detail for (What); • Role detail for (Who); • Location detail for (Where);• Event detail for (When).

Detailed Representation

Page 11: EAI: myths & reality



Figure 7. The TOGAF Architecture Development Method (ADM)

Business architecture

Application architecture

Data architecture

Technical architecture

Page 12: EAI: myths & reality


Where are we?

Relationship between the Enterprise Continuum and the Architecture

Development Method

Page 13: EAI: myths & reality


Federal Enterprise Architecture (FEA)

Published in September 1999

“ designed to ease sharing of information and resources

across federal agencies, reduce costs, and improve citizen


Page 14: EAI: myths & reality


Other Framework focus point

DODAFCapabilities Integration and

Development (JCIDS)

Planning, Programming, Budgeting, and Execution (PPBE)

Acquisition System (DAS)

Systems Engineering (SE)

Operations Planning

Capabilities Portfolio Management (CPM)

MODAF(base of NAF)

Strategic Viewpoint (StV)

Operational Viewpoint (OV)

Service Orientated Viewpoint (SOV)

Systems Viewpoint (SV)

Acquisition Viewpoint (AcV)

Technical Viewpoint (TV)

All Viewpoint (AV)



Business Process






Page 15: EAI: myths & reality


What & where :Top 10


Page 16: EAI: myths & reality



More at: http://www.ebizq.net/topics/soa_management/features/9869.html?page=1

Page 17: EAI: myths & reality


What we integrate?

Page 18: EAI: myths & reality


What is a integration?

In engineering, system integration is the bringing together of the component subsystems into one system and ensuring that the subsystems function together as a system.

 In information technology, systems integration is the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole.


Page 19: EAI: myths & reality


But the EAI?

Enterprise application integration is an integration framework composed of a collection of technologies and services which form a middleware to enable

integration of systems and applications across the enterprise.

lack of communicatios


identical data are stored in multiple locations

unautomatizable processes

Existence of information silos

Inefficient business processes

Page 20: EAI: myths & reality


Why we need EAI?

Data integration Process integration Vendor independence Common Façade 

Transaction management

Security management  Multiple Technology


 Real time information access  Streamlines business processes  Integrity across multiple systems


Page 21: EAI: myths & reality


EAI: Patterns & Technologies

Patterns• Integration patterns

• Mediation (intra-communication)• Federation (inter-communication)

• Access patterns• Lifetime patterns

Technologies• Bus/hub• Application connectivity• Data format and transformation• Integration modules• Support for transactions

Topologies• Hub/spoke

• Bus

• Point 2 Point

EIP - Camel: http://camel.apache.org/enterprise-integration-patterns.html

Page 22: EAI: myths & reality


The interpretations


Point-to-point integrationBroker-based integration

ESB-based integration

Page 23: EAI: myths & reality


Integration Models

Invoking Services

Method-based (COM/CORBA)


Accessing Services




Tightly Coupled

Loosely Coupled

Page 24: EAI: myths & reality


The language

• SOAP: Simple Object Access Protocol• WSDL: Web Services Description Language• UDDI: Universal Description, Discovery and Integration

Message/event oriented:

• BML: Business Modeling Language• BPMN: Business Process Model and Notation

Workflow oriented:

• EDI: Electronic Data Interchange• XML Trade VocabulariesB2B Integration

Page 25: EAI: myths & reality


The solutions provider

Oracle Fusion Middleware (all in one, ETL, BPM, SOA, Data Integration, BI, IM, WebCenter), Siebel , solution for all major problems, Cloud solutions

OracleSAP NetWeaver, SAP Discovery system, solution for all major problems, Cloud solutions SAPBizTalk 2010 (messaging, a rules engine, EDI, BAM, LoB, HIS), Dynamics, SharePoint Microsoft:InfoSphere Platform, WebSphere (BPM, SOA, Portals, Data Management)IBM

SOA, BPM, BO, CloudTibco

BPM, SOA, Software AG:

Adeptia ESB Suite, Spring, Metastorm EAI, Others:

Page 26: EAI: myths & reality


From the base …

Java: • JMS• OpenJMS• Open MQ• JBoss ESB• Oracle Enterprise Service Bus• Mule

.NET (ESB)• NServiceBus• BizTalk

Other• RabbitMQ (Erlang)

Page 27: EAI: myths & reality


What saying Gartner about tools?

Page 28: EAI: myths & reality


What saying Gartner about providers?

Page 29: EAI: myths & reality


The benefits (Myths)

Operational:•Productivity increase•Cost savings•Data consistency, Data access• Focus on Process•Workflows /Automations

Managerial•Better control/ overview•Better and fast decisions•Automations on decisions •Performance evaluation (KPI)•VISIBILITY

Strategic• Long term planning (more companies can be integrated)•Knowledge sharing •Past, Present, Future information's (BI)

IT •Control• Scalability, Maintainability•Data transparency•Real Time data access• Standardize and organize systems and data•Robustness, High availability

Organizational• Less work /more efficiency•Better reaction to market changes• Focus on Business •New oportunities

Page 30: EAI: myths & reality


The truth (Reality)

Financial problems• 2002 : 70% of EAI project failed• 2003 : 25-30% of IT budget is allocated for EAI• HIGH COST on start, slow and invisible benefits

Added value problems• Lot of companies follow the trend, not the business• Long term running projects, no added values• CONSTANT CHANGES –Never ending stories

Make organization efficient• The EAI doesn’t reduce the complexity• Competing standard, doesn’t applied

Knowledge • Loss of details /focus point (Why we need this?)• Lot of DESIGN/ARCHITECTURAL/NEGOTIOTION TIME• Lack of specialist• Lack of managerial knowledge

Pitfalls• Missing integration strategy• Combine EAI with other

project• Lack of recognition that EAI is

an architecture• Neglecting security,

performance and monitoring; Internal politics

• poor communication

Page 31: EAI: myths & reality


Technical Reality

Multiple interfaces give flexibility / irreplaceability ?

Different applications can re-use the interfaces?.

Services exposed over web can be easily decoupled.

The IT/SW/HW doesn’t resolve the business problems.

Lack of software response to

Inconsistent data structure is transferred as a NORMALIZED?

EAI helps a better reusability? Maybe freezing the interface. One

Scope / One interface ?

Knowledge on BUSINESS side affects the technical implementation

Lack of ANALYSIS (business & system)

Lack of feasibility analysis & risk analysis.

Page 32: EAI: myths & reality


TIPS: Aks! Ask! Ask!

SCOPE of EAI? Why do you what to do this?

Why this EAI add value and how can materialize in COST (for ROI calculation)?

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 you what to maintain the old systems? Why?

Infrastructure, locations, peoples who access?

How important is scalability to organization?


Critical factor? What is you uptime?

Process/Workflows : Do my integration needs include routing, forking, or aggregation?

Does my integration situation require asynchronous messaging, publish/consume messaging

models, or other complex multi-application messaging scenarios?

Decision makings: BI/ data aggregation, data collection, modelling?

Page 33: EAI: myths & reality


The Future

Cloud Migration / IntegrationCloud & Premise IntegrationEnterprise Social Networking IntegrationsFocus on Business ProcessFocus on: – Human centric Proces– Document Managent– Comprehensive integration (integrate the twitter with

facebook and CRM and financial systems)  Collaborations between Enterprise in real


Page 34: EAI: myths & reality


BPM? Time to change …

2003 : Smith and Fingar

Business Process Management

(BPM): The Third Wave

Page 35: EAI: myths & reality



“Nature laughs at the difficulties of integration.” Pierre-Simon Laplace

“A goal without a plan is just a wish.” Antoine de Saint-Exupéry

“Vision without execution is hallucination.”Thomas A. Edison .

Page 36: EAI: myths & reality



thank you


Levente Veres | Software Design Lead

Mail: [email protected]

Twitter: @bergermanus