eai: myths & reality
Post on 30-Nov-2014
1.839 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
37
References
1. http://www.eaipatterns.com/2. http://en.wikipedia.org/wiki/Enterprise_application_integration3. Enterprise Architecture: http://
msdn.microsoft.com/en-us/library/bb9774684. Microsoft Enterprise: http://
www.microsoft.com/en-gb/enterprise/default.aspx5. http://www.column2.com/category/bpmhistory/6. http://
www.oracle.com/us/products/engineered-systems/index.html7. Thanks for Google Search ;)
top related