The document outlines the fundamental concepts and strategies of application integration, defining it as the process that allows different business applications to exchange information effectively. It discusses various integration methods such as point-to-point, message-oriented middleware, and middleware platforms, as well as integration protocols like file, database, application, and business process integration. The document highlights the challenges and goals of integration, emphasizing the need for a central team and an evolving architecture to ensure successful enterprise integration.

1. Introduction to Integration

2. Outline
Definition
Terminology
Protocols
Integration – The Problem
Integration – The Goals
Integration – The Strategy
Integration – Architecture

3. Integration
Integration combines the technologies and processes
that enable custom-built and/or packaged business
applications to exchange business-level information in
formats and contexts that each understand
Application integration is necessary whenever a new
application is purchased, enhanced, or developed.
Integration is more than middleware programming –
the middleware platform is an enabler
Integration is complex and technical – setting it up
requires cooperation between several application
teams, several types of skills, lots of patience and
coordination

4. Integration - Definitions
Definition: “Integration” means making
independently designed systems work together.
Application-to-Application (A2A)
Business-to-Business (B2B)
Business-to-Consumer (B2C)
Other: mobile devices, video and cellular phones, digital
set-top boxes, electronic books and game consoles.

5. Integration Terminology
Common terms - A2A, B2B, EAI, MOM, XML,
Request/Reply, asynchronous, etc.
Examples of integration
Different modules of same application (Oracle CRM,
Oracle Financials)
Siebel with Oracle or SAP - Applications
WAP or voice technologies with applications
Business to Business or Trading Partners

6. Integration Methods
Integration methods
Point-to-point
Message oriented middleware
Middleware platforms

7. Integration Methods
Integration methods
Point-to-point

8. Point-to-point
One application talks to another directly
Most prevalent & it works for most
Serves specific business need
Not enterprise wide
Maintenance nightmare
Not scalable

9. Integration Methods
Integration methods
Point-to-point
Message oriented middleware

10. Message oriented middleware
Use a messaging infrastructure for message transport
Application logic resides in applications
Guarantees delivery
No problems if one application is down
But,
Integration essentially point-to-point

11. Integration Methods
Integration methods
Point-to-point
Message oriented middleware
Middleware platforms

12. Platform Middleware
Application Adapters
Data Transformation
Delivery guarantees
Usage of standard messages
Centralized management of integration
Process management
System monitoring
Enterprise wide
But,
Not an out-of-box solution
Still have a lot of work to do to make it all work

13. What does Middleware provide?
Middleware provides the framework and gets you
 Guaranteed delivery
 Higher transaction volumes
 Near real time messaging
 Decoupled applications
 Multiple applications sharing same information
 Transformation infrastructure
 Connectivity to application APIs
 Monitoring of the integration, maybe resend failed messages
 Workflow integration – integrated applications behave like a single
entity
 Ability to add more applications that need to share same
information

14. Integration Protocols
File level integration
Database level integration
Application level integration
Business process integration

15. Integration Protocols
File level integration

16. File level integration
Exchange files between applications
Used to integrate legacy & other applications
Used mostly in batch mode, not real time
Disadvantages
Not very secure
Files may get corrupted
They may get lost
Dependent on the system infrastructure

17. Integration Protocols
File level integration
Database level integration

18. Database level integration
Exchange information at database level
“Better” than file based integration
Secure
Database Event based
Guaranteed, to an extent
Can program in some process management
But,
DBs may be different
Data type matching required
DBs may be down

19. Integration Protocols
File level integration
Database level integration
Application level integration

20. Application level integration
Applications exchange information
Use the application infrastructure
APIs available for integration – applications
manage a lot of the logic
E.g., TIBCO calling BAPI to interface with SAP

21. Integration Protocols
File level integration
Database level integration
Application level integration
Business process integration

22. IP Integration - Transactions
ERP
Orgs and Reference Codes
Internet
Procurement
PO Add, Change and Hold
Requisition
Receipt
Approved Journals
PO Status
PO Number
Cancel PO and Req
Supplier Add and Change
Item Add and Change
Units of Measure
Chart of Accounts
Daily Rates
Freight Terms
Confirmations

23. Integration – The Problem
Enterprise Resource Planning (ERP) suites purchased to
replace multiple legacy systems. Issues still remained:
Didn’t replace all legacy apps
Difficult/Expensive to implement & maintain
Do not fulfill all functions of the enterprise, hence the
need for other applications

24. Need for Integration
 Differences in data definitions among applications
 Complexity of the programming environment
 Sequencing of data and processing (in other words the Business
Logic)
 Difficulties with sharing code among applications
 Security
 The need to provide information from integrated applications to better
serve customers
 Reduce the lag time in processing business requirements
 Thereby reducing cost and improving productivity
 Hence the pressure to make applications work together is intense
 As businesses leverage the Web and attempt the transition to
becoming “e-businesses,” the need to collaborate across
organizational boundaries has emerged as paramount

25. Integration – The Problem
Application Integration Spaghetti:
When enterprises have undocumented, complex, high-
maintenance integration paths. And each connection is
LOCALLY rather than GLOBALLY optimized
difficult to modify or reuse
uses batch file transfer (some non-automated)
data may be re-keyed

26. Integration Spaghetti

27. Integration - Goals
To reduce the development effort needed to
document and code interfaces between systems
To reduce redundancy in the integration
middleware
To shorten the time it takes to add or change
applications and their connections with other
applications.

28. Integration – the goal

29. Integration – The Strategy
 Successful integration strategies require three
things (besides budget )
 a central integration team
 an evolving enterprise integration architecture
 a shared technical infrastructure

30. Integration - Architecture
An Enterprise Integration Architecture brings consistency
to inter-application exchanges without interfering with the
intra-application design decisions.
Enterprise Architecture
Information Architecture
(Blueprints for interfaces)
Message, file, document and
method schema
Communication model
Volume and frequency
Transformation rules
Governance
Relationship to
application groups,
central technical support,
steering committee
Throughput, latency, and
other quality-of-service
SLAs
Infrastructure Standards
(Building materials and tools)
Enterprise standards for
integration middleware and
administration, monitoring,
security and integrity tools

31. Integration - Architecture
Decision Framework: The integration
infrastructure offloads functions from the
application programs and simplifies application
development and maintenance by supplying
middleware-based “intelligent network” services.
It may include
Basic communication facilities
An integration broker
Business process managers
Business activity monitors

32. Integration Architectures

33. Questions?