This document outlines steps for integrating a large ERP deployment, including mapping applications, establishing integration objectives, defining integration patterns, assessing messaging requirements, and establishing an integration architecture and decision flow for reusing vs building new integrations. Key steps are breaking integration into logical steps, reusing existing integrations where possible, and establishing governance guidelines to reduce complexity and costs long-term.

1. Integration Strategy for Large ERP
Deployments
Arup Dutta
April 2016

2. Output
Steps to Solving a Complex Problem
Integration is a complex challenge in any ERP implementation. For
a large ERP implementation, Integration is among the top concerns
along with Data. It needs to be broken down into logical steps
interlaced with key decisions to get a grip on the complexity.
Input
Build To Be Application Map
Group Messages with
Application Groupings
Establish Objectives and
Evaluate Current
Technology against Market
Leaders to achieve
Objectives
Establish Message Pattern
/Requirement- Volume,
Sequencing, Prevention of
Message loss, Queuing etc.
Extend Existing
Technology or
Replace with
Industry Leader or
combination
Decision criteria for
Build New Vs Re-
Use Existing
Define Governance
Rules and SLAs and
Message
Prioritization Rules
Integration
Architecture and
Guidelines
New vs Existing
Decision Flow
Message
Catalogue, SLA,
Monitoring etc.

3. Integration Objectives
Objective
Low Cost of Ownership Use minimum set of integration tools/framework. In
other words use existing Integrations or Enhance
existing integrations- Publish Once and Subscribe
Multiple times
Speed over Elegance Leverage out of box. Use Existing. Minimize
Transformation. Publish Once and Subscribe Multiple
times
Reusability Use Standard Formats. Have a long term view.
Catalogue.
Reliability Inbuilt Error Handling, Early Warning, Decouple
source and target.
Secure Industry Standard for secure End to End
Transmission

4. To Be Application Map
Lay out the To-Be Application Footprint Map
• Arrange Application by Process Groups
• Applications may span Process Groups
Idea to
Launch
Market to Sell Order to Cash Procure to Pay Plan to Deliver Record to Report
Single Instance ERP
MES App 1
PLM App 1
PLM App 2
PLM App 3
PLM App 4
PLM App 5
PLM App N
MES App 2
MES App 3
MES App 4
MES App 5
MES App N
CRM App 1
CRM App 2
CRM App 3
CRM App 4
CRM App 5
CRM App N
Reusable
Interfaces
Provides Reusable
Interface Groups for
Publish and Subscribe
Cloud
Apps
• Prioritize
• Standardize
• Catalogue

5. Patterns of Integration
Possible patterns of integration Business object
Asynchronous
Pub-Subscribe
 XML message to XML message
 Target application has capability for messages
 Sales Order
 Purchase Orders
 Project Revenue.
 XML message to File
 EI queues messages and delivers as file.
 Target application does not have the capability to
process messages.
 Any business object
Asynchronous
FileIntegration
 File to File [through middleware]
 Asynchronous.
 Business object needs file (batch process)
 Journals
 Revenue earned on projects
 File to File [FTP/SFTP]
 Asynchronous
 Business object makes it mandatory to be sent as
file
 Integration exists today and was not changed.
 Target application integration capability irrelevant.
 Ledger balance
nc.
 Web Service [through middleware/direct]
 Web Service call through Middleware layer
 Credit card transactions
Its important to establish possible patterns as an input to
decisions on New vs Re-use

6. Messaging Requirements
Gathering Messaging requirements provides the input to SLA, Monitoring
and pother Technical specifics. Some Messaging requirements are
Application agnostic. Others are very dependent on Source to Target.
Below are some examples:
• Message Volume – Thresholds can be defined as
• High (20,000 plus messages / day)
• Medium ( Less than 20,000 and more than 1000/day)
• Low (Less than 1000/day)
• Message patterns- MQ, File, IDOC etc.
• Stateful message processing- End to End vis a vis
Publish/Subscribe
• Synchronous vs Asynchronous
• Queuing/Sequencing requirements
• Real-time vs Batch
• Error Handling Rules
• Security Considerations- especially sensitive data like personal
records, financials, product information that can be leaked to
competitors.

7. Guiding Principles to achieve Objectives
• Leverage standard out of the box content
• Use Middleware by default for integration
• Build and develop a Business Object Repository for reusability
• Use XML as default integration format
• All integrations by default are to be Asynchronous
• Maintain cross ref tables and value maps in middleware (if AIF is not
used)
• Do not maintain business logic within middleware
• Maintain target determination logic within middleware
• Provide end to end monitoring and alerting capabilities (down to
interface level)
• Transfer of sensitive data via middleware should be through a
secured protocol in addition to encryption

8. Integration Architecture
Type Inner Ring Outer Ring
Application & integration from same
vendor

Application from other vendors 
*Bolt on Application 
External application (Cloud, WAN) 
Integration Patterns Message Based
Remote Procedure Calls
File Based
Message Based
Remote Procedure Calls
File Based
Adaptors/Connectors Application Adaptors
JDBC, SOAP, JMS, SFTP,
etc.
Application Adaptors
JDBC, SOAP, JMS, SFTP,
etc.
This establishes a baseline Technology layer for messages to flow.
Once this decision is taken subsequent designs/decisions fall into
place as they are dictated by the technology layer.

9. Decision Flow for New vs Re-Use of Messages
Start
Is the
Interface
Existing
Yes
No
Functional
Fit
Technical
Fit
Yes
Yes
No
Re-Use
No
New Re-Use with
Modification
Evaluate
Fit/Gap
Large/Unsustainabl
e GAP
Small/Sustainable
GAP
• Functional Fit- No Changes to existing functional Specs
• Technical Fit- Meets SLA, Performance Requirements, Sender/Receiver
Protocols
Simple Schematic of Decision flow of Message Evaluation whether
to Build New or Re-Use. Its important to set this up early on to
avoid re-work later and loss in critical project hours

10. Message Catalogue/SLA/Monitoring
App Group Message Priority Volume Source Target
PLM Maintain Material Critical High
PLM Maintain BOM Critical High
App Group Message Priority Volume Source Target
CRM Maintain Customer Critical High
CRM Create Sales Order Critical High
Monitoring Attributes:
• End to End or Component
• Alerts
• Performance
• Sequence
• Logging and Tracing
• Background Job Monitor
• Adaptor and Connector Monitors……..etc.
Following shows a possible structure of a message catalogue with
attributes for monitoring and SLA. Functional and Technical details
are captured in individual design documents

11. In Summary & Recap
• The Integration Challenge can be broken down into logical steps with proper
decision guidelines for resolution of conflicts.
• The goal should be to avoid point to point integration.
• Enforcing through Governance the Reuse of Messages will pay back in the
long term by reducing complexity. Duplicity of messages increases the
requirements for performance, support, monitoring etc. Taking time early in
the design cycle to work through the Governance Mechanisms save $$ in the
long run.
• A simplified Integrated Landscape allows for mergers and divestitures to be
executed quickly.
• Following a few simple principles reduces complexity and overall cost of
ownership.