The document provides an overview of enterprise application integration (EAI) and the Zachman Framework for enterprise architecture. It discusses the evolution of enterprise applications from data processing to business processes. It also summarizes the Zachman Framework, which provides a standard way to describe and define an enterprise based on six fundamental questions (what, how, where, who, when, why) and perspectives (contextual, conceptual, logical, physical).

1. Levente Veres
2012.08.30 @ RABS.ro
Cluj-Napoca
1

2. Agenda
 What is EAI? The True Story.
 EAI frameworks
 EAI Patterns & Technics
 Toolset on Battlefield
 Myths & Reality
 The future
2

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
3

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

5. Enterprise Application?
Can you define?
5

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
6

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)
7

8. EA base domains
Business architecture Information system architecture Technical architecture.
Data architecture (IS) Application architecture (IS)
8

9. The Time Line
1960 1980 1992 1991 2001 2003
development of A Framework for Extending and TAFIM -> ‘95 TOGAF OBASHI framework DODAF
information Information Systems Formalizing the (The Open Group for Business and IT
architecture by P. Architecture” Framework for Architecture digrams Department of
Duane (Dewey) developed by John Information Systems Framework) (Ownership,Business, Defense Architecture
Walke Zachman at IBM; Architecture" John F. Process, Application, Framework
The architectural published in 1987. Sowa and John System, Hardware,
documents base of Zachman Infrastructure)
Business Systems
Planning (BSP)
Zachman Framework
9

10. The Zachman Framework
Focus on fundamental questions
What How Where Who When Why
The
The data The function The Network The people The time
motivation
description description description description description
description
• (Why) Goal List – primary high level organization goals
• (How) Process List – list of all known processes
Contextual •
•
•
(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
Conceptual •
•
(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
Logical • (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
The Models
• (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
Physical •
•
•
(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);
Detailed •
•
Process detail for (How);
Data detail for (What);
• Role detail for (Who);
Representation •
•
Location detail for (Where);
Event detail for (When).
10

11. TOGAF
Business Application Data Technical
architecture architecture architecture architecture
Figure 7. The TOGAF Architecture
Development Method (ADM)
11

12. Where are we?
Relationship between the Enterprise Continuum
and the Architecture Development Method
12

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”
13

14. Other Framework focus point
MODAF
DODAF OBASHI
(base of NAF)
Capabilities Integration and Strategic Viewpoint (StV) Ownership
Development (JCIDS)
Planning, Programming, Budgeting, Operational Viewpoint (OV)
Business Process
and Execution (PPBE)
Service Orientated Viewpoint (SOV)
Acquisition System (DAS) Application
Systems Viewpoint (SV)
Systems Engineering (SE) System
Acquisition Viewpoint (AcV)
Operations Planning Hardware
Technical Viewpoint (TV)
Capabilities Portfolio Management
All Viewpoint (AV) Infrastructure
(CPM)
BPM, BTO, CM, ITIL, ITS …
14

15. What & where :Top 10
http://msdn.microsoft.com/en-us/library/bb466232.aspx
15

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

17. What we integrate?
17

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
18

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
19

20. Why we need EAI?
Purpose
 Data integration  Transaction management
 Process integration  Security management
 Vendor independence  Multiple Technology
 Common Façade
Benefits
 Real time information access
 Streamlines business processes
 Integrity across multiple systems
20

21. EAI: Patterns & Technologies
Patterns Topologies
• Integration patterns • Hub/spoke
• Mediation (intra-communication)
• Federation (inter-communication)
• Access patterns
• Lifetime patterns
EIP - Camel: http://camel.apache.org/enterprise-integration-patterns.html • Bus
Technologies
• Bus/hub
• Application connectivity • Point 2
• Data format and transformation
Point
• Integration modules
• Support for transactions
21

22. The interpretations
Point-to-point integration
Broker-based integration
ESB-based integration
http://www.richardhallgren.com/what-kind-of-integration-patters-do-you-implement-in-biztalk/
22

23. Integration Models
Invoking Services Accessing Services Coupling
Method-based
Synchronous Tightly Coupled
(COM/CORBA)
Message-based Asynchronous Loosely Coupled
23

24. The language
Message/event • SOAP: Simple Object Access Protocol
• WSDL: Web Services Description Language
oriented: • UDDI: Universal Description, Discovery and Integration
Workflow • BML: Business Modeling Language
oriented: • BPMN: Business Process Model and Notation
• EDI: Electronic Data Interchange
B2B Integration • XML Trade Vocabularies
24

25. The solutions provider
Oracle Fusion Middleware (all in one, ETL, BPM, SOA, Data
Oracle Integration, BI, IM, WebCenter), Siebel , solution for all major
problems, Cloud solutions
SAP NetWeaver, SAP Discovery system, solution for all major
SAP problems, Cloud solutions
BizTalk 2010 (messaging, a rules engine, EDI, BAM, LoB, HIS),
Microsoft: Dynamics, SharePoint
InfoSphere Platform, WebSphere (BPM, SOA, Portals, Data
IBM Management)
Tibco SOA, BPM, BO, Cloud
Software AG: BPM, SOA,
Others: Adeptia ESB Suite, Spring, Metastorm EAI,
25

26. From the base …
Java:
• JMS
• OpenJMS
• Open MQ
• JBoss ESB
• Oracle Enterprise Service Bus
• Mule
.NET (ESB)
• NServiceBus
• BizTalk
Other
• RabbitMQ (Erlang)
26

27. What saying Gartner about tools?
27

28. What saying Gartner about providers?
28

29. The benefits (Myths)
Operational: Managerial
•Productivity increase •Better control/ overview
•Cost savings •Better and fast decisions
•Data consistency, Data access •Automations on decisions
•Focus on Process •Performance evaluation (KPI)
•Workflows /Automations •VISIBILITY
Strategic IT
•Long term planning (more companies can be integrated) •Control
•Knowledge sharing •Scalability, Maintainability
•Past, Present, Future information's (BI) •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
29

30. The truth (Reality)
Financial problems Pitfalls
• 2002 : 70% of EAI project failed • Missing integration strategy
• 2003 : 25-30% of IT budget is allocated for EAI • Combine EAI with other
• HIGH COST on start, slow and invisible benefits project
Added value problems • Lack of recognition that EAI is
an architecture
• Lot of companies follow the trend, not the business
• Long term running projects, no added values
• Neglecting security,
performance and
• CONSTANT CHANGES –Never ending stories
monitoring;
Make organization efficient Internal politics
• The EAI doesn’t reduce the complexity • poor communication
• 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
30

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.
31

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

33. The Future
 Cloud Migration / Integration
 Cloud & Premise Integration
 Enterprise Social Networking Integrations
 Focus on Business Process
 Focus on:
– Human centric Proces
– Document Managent
– Comprehensive integration (integrate the twitter with facebook
and CRM and financial systems)
 Collaborations between Enterprise in real time.
33

34. BPM? Time to change …
2003 : Smith
and Fingar
Business Process
Management
(BPM): The Third
Wave
34

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 .
35

36. Thanks!
Levente Veres | Software Design Lead
Mail: levente.veres@gmail.com
Twitter: @bergermanus
LinkedIn:
http://ro.linkedin.com/pub/veres-levente/2/b40/56
36

37. References
1. http://www.eaipatterns.com/
2. http://en.wikipedia.org/wiki/Enterprise_application_integration
3. Enterprise Architecture: http://msdn.microsoft.com/en-us/library/bb977468
4. Microsoft Enterprise: http://www.microsoft.com/en-
gb/enterprise/default.aspx
5. http://www.column2.com/category/bpmhistory/
6. http://www.oracle.com/us/products/engineered-systems/index.html
7. Thanks for Google Search ;)
37