eai: myths & reality

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

Upload: levente-veres

Post on 30-Nov-2014

1.845 views

Category:

Technology


0 download

DESCRIPTION

Presentation about Enterprise Application Integration at Rabs.ro.

TRANSCRIPT

Page 1: EAI: myths & reality

1

EAI Myths & Reality

Levente Veres2012.08.30 @ RABS.ro

Cluj-Napoca

Page 2: EAI: myths & reality

2

Agenda

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

Page 3: EAI: myths & reality

3

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

4

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

5

Enterprise Application?

Can you define?

Page 6: EAI: myths & reality

6

Enterprise Application

EA: is a business application

Complex, Scalable, Distributed, Component based

Mission-critical

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

7

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

8

EA base domains

Business architecture Information system architecture

Data architecture (IS) Application architecture (IS)

Technical architecture.

Page 9: EAI: myths & reality

9

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)

2001DODAF

Department of Defense Architecture Framework

2003

Zachman Fram

ework

Page 10: EAI: myths & reality

10

The Zachman Framework

Why The

motivation description

When

The time description

Who The people description

Where

The Network description

How The function description

What

The data description

Focus on fundamental questions

The

Mod

els

• (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

Contextual

• (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

Conceptual

• (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

Logical

• (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

Physical

• 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

11

TOGAF

Figure 7. The TOGAF Architecture Development Method (ADM)

Business architecture

Application architecture

Data architecture

Technical architecture

Page 12: EAI: myths & reality

12

Where are we?

Relationship between the Enterprise Continuum and the Architecture

Development Method

Page 13: EAI: myths & reality

13

Federal Enterprise Architecture (FEA)

Published in September 1999

“ designed to ease sharing of information and resources

across federal agencies, reduce costs, and improve citizen

services”

Page 14: EAI: myths & reality

14

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)

OBASHI

Ownership

Business Process

Application

System

Hardware

Infrastructure

BPM, BTO, CM, ITIL, ITS …

Page 15: EAI: myths & reality

15

What & where :Top 10

http://msdn.microsoft.com/en-us/library/bb466232.aspx

Page 16: EAI: myths & reality

16

RUP & TOGAF

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

Page 17: EAI: myths & reality

17

What we integrate?

Page 18: EAI: myths & reality

18

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.

http://en.wikipedia.org/wiki/System_integration

Page 19: EAI: myths & reality

19

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

Inefficiencies

identical data are stored in multiple locations

unautomatizable processes

Existence of information silos

Inefficient business processes

Page 20: EAI: myths & reality

20

Why we need EAI?

Data integration Process integration Vendor independence Common Façade 

Transaction management

Security management  Multiple Technology

Benefits

 Real time information access  Streamlines business processes  Integrity across multiple systems

Purpose

Page 21: EAI: myths & reality

21

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

22

The interpretations

http://www.richardhallgren.com/what-kind-of-integration-patters-do-you-implement-in-biztalk/

Point-to-point integrationBroker-based integration

ESB-based integration

Page 23: EAI: myths & reality

23

Integration Models

Invoking Services

Method-based (COM/CORBA)

Message-based

Accessing Services

Synchronous

Asynchronous

Coupling

Tightly Coupled

Loosely Coupled

Page 24: EAI: myths & reality

24

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

25

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

26

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

27

What saying Gartner about tools?

Page 28: EAI: myths & reality

28

What saying Gartner about providers?

Page 29: EAI: myths & reality

29

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

30

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

31

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

32

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?

Security?

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

33

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

time.  

Page 34: EAI: myths & reality

34

BPM? Time to change …

2003 : Smith and Fingar

Business Process Management

(BPM): The Third Wave

Page 35: EAI: myths & reality

35

Quotes

“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

36

Thanks!

thank you

RABS

Levente Veres | Software Design Lead

Mail: [email protected]

Twitter: @bergermanus

LinkedIn:http://ro.linkedin.com/pub/veres-levente/2/b40/56