EAI: myths & reality

Post on 30-Nov-2014

1.839 views 0 download

Tags:

description

Presentation about Enterprise Application Integration at Rabs.ro.

Transcript of EAI: myths & reality

1

EAI Myths & Reality

Levente Veres2012.08.30 @ RABS.ro

Cluj-Napoca

2

Agenda

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

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

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?‘

5

Enterprise Application?

Can you define?

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

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)

8

EA base domains

Business architecture Information system architecture

Data architecture (IS) Application architecture (IS)

Technical architecture.

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

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

11

TOGAF

Figure 7. The TOGAF Architecture Development Method (ADM)

Business architecture

Application architecture

Data architecture

Technical architecture

12

Where are we?

Relationship between the Enterprise Continuum and the Architecture

Development Method

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”

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 …

15

What & where :Top 10

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

16

RUP & TOGAF

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

17

What we integrate?

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

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

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

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

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

23

Integration Models

Invoking Services

Method-based (COM/CORBA)

Message-based

Accessing Services

Synchronous

Asynchronous

Coupling

Tightly Coupled

Loosely Coupled

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

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:

26

From the base …

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

.NET (ESB)• NServiceBus• BizTalk

Other• RabbitMQ (Erlang)

27

What saying Gartner about tools?

28

What saying Gartner about providers?

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

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

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.

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?

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.  

34

BPM? Time to change …

2003 : Smith and Fingar

Business Process Management

(BPM): The Third Wave

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 .

36

Thanks!

thank you

RABS

Levente Veres | Software Design Lead

Mail: levente.veres@gmail.com

Twitter: @bergermanus

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