This document presents a technical overview of enterprise integration architecture, emphasizing lessons learned and best practices for integrating disparate systems within organizations. It covers key components, scenarios, and integration patterns, and outlines the importance of aligning business strategies with technical capabilities. The presentation also discusses different integration architecture scenarios, including cloud-to-ground and ground-to-cloud integrations, while highlighting that there is no one-size-fits-all solution.

1. Enterprise Integration
Architecture
Lessons learned along the way
August 13th 2015

2. Aldo Fernandez
Technical Consultant
@aldoforce

3. Safe Harbor
Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve
risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com,
inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of
historical fact could be deemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items and any
statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or
upgraded services or technology developments and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our
service, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in
our Web hosting, breach of our security measures, risks associated with possible mergers and acquisitions, the immature market in which we operate,
our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and
successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers.
Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the
most recent fiscal quarter ended July 31, 2011. This document and others are available on the SEC Filings section of the Investor Information section of
our Web site.
Any unreleased services or features referenced in this or other press releases or public statements are not currently available and may not be delivered
on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available.
Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

4. Follow UYSDUG for the latest news
@uysdug #uysdug
/Uruguay-Salesforce-Developer-User-Group/
www.uysdug.com

5. Join us and share your knowledge!
▪ Got something to share with the world?
▪ We are open for talks/sessions
▪ Check www.uysdug.com/cfp or get in contact with
someone from the Technical Board for more information
▪ UPCOMING EVENTS:
▪ August 25th (Independence day + Salesforce global
event!)
▪ September 3rd (DF15 countdown talk)
▪ October 1st (DF15 survivors wrap up)

6. Agenda
▪ What is an Enterprise Integration Architecture?
▪ Integration Architecture vs Integration Patterns
▪ Components of an Integration Architecture
▪ Enterprise Salesforce Integration Architecture scenarios

7. What is an Enterprise Integration Architecture?
▪ It’s about being reactive
▪ It’s an architecture to facilitate integration of applications that were never designed
to work together
▪ Synchronize data/processes among disparate systems.
▪ Controlled data redundancy (redundancy friendly)
▪ EIA is not SOA!
▪ Should improve:
▪ Time to delivery
▪ Total cost of ownership
▪ Business agility/accurancy

8. Integration Architecture vs Integration Patterns
▪ Designing the
highway
▪ Focus on
infrastructure
▪ Driving the cars
on the highway
▪ Focus on
technologies and
patterns
catalogue
Integration
Architecture
Integration
Patterns
Performance + Scalability + Data Integrity
+

9. Components of an Integration Architecture (1/4)
▪ The best architectures are NOT based on incumbent technologies,
singular approach or corporate politics
▪ The best architectures are based on delivering business value
▪ Requires deep analysis of Business requirements and roadmap
▪ Figure out which “highways” or “roads” are necessary (traffic/usage/LDV)
▪ Avoid idealistic architectures /o
The Integration Architecture aligns business strategy
with technical capabilities

10. Components of an Integration Architecture (2/4)
▪ Define SLAs for data and process integration ASAP: sync/
async, processing time, etc (trust is your friend)
▪ They will set: technology and integration pattern
▪ Look for real needs!
▪ Beware of Salesforce multi tenant design when defining SLAs
(@future, batch)
The Integration Architecture is based upon Business
SLAs

11. Components of an Integration Architecture (3/4)
▪ Goal is to define a set of capabilities and standards for all
salesforce integration projects (reusability, remember?)
▪ Each project should not need to define what/where technology
to use on common business scenarios.
▪ Look for the CoE, or higher-level IT authority
The Integration Architecture has a clearly defined
standard for applying different integration use cases

12. Components of an Integration Architecture (4/4)
▪ The best designs support both: batch and service based
patterns.
▪ Support at the same time, multiple types of middleware at work
▪ Not a single solution to meet the requirements
▪ Avoid idealistic architectures (Remember the SLAs!)
The Integration Architecture supports a mix of batch
and real-time processing services middleware

13. Enterprise Salesforce Integration
Architecture scenarios

14. Cloud to Ground (Salesforce originated)
▪ Remote service is relayed to a DMZ
▪ Firewall
▪ Gateway
▪ Reverse proxy
▪ Dual firewall architectures
▪ Inbound/Outbound Security
▪ Whitelist IPs
▪ 2-way-SSL
▪ HTTP authentication
▪ Salesforce can be a consumer and then a producer
▪ Hits an ESB (transformations, translations, mediation, orchestration) or a queue
▪ On premise data access (typically read)

15. Ground to Cloud (On-premise originated)
▪ All inbound traffic should go thru an ESB (promote re-use,
centralized integration middleware, security, etc)
▪ Authentication: choose wisely
▪ Bi-directional ETL for batch is always cheap with bulk API
▪ Off-load data into replicated copy as backup (scalability: get diffs
or deltas only)
▪ ETL for data-warehouse

16. Cloud to Cloud
▪ Multiple orgs:
▪ Salesforce2Salesfoce
▪ REST API
▪ Hub/Spoke
▪ Heroku/Lightning Connect
▪ Salesforce as hub, be warned: don’t use Apex as primary integration
technology (it’s a trap!)
▪ Evaluate existing cloud based Integration-as-a-Service (IaaS) solutions
▪ View the Middleware as a long term invest

17. Summary
▪ There is no “one size fits all”
▪ There is no best solution that meets ALL your requirements
▪ Use a SWOT analysis approach as much as you can
▪ 4 habits of a good Integration Architect:
▪ Analyze,
▪ Implement,
▪ Recommend,
▪ Repeat

19. Resources + Kudos
▪ “Enterprise Architecture series” @salesforcedocs
▪ “Enterprise Architecture with Force.com” Greg Cook
@gregheartcloud
▪ “Enterprise Integration: EAI vs SOA vs ESB” Anurag Goel
▪ “Integration Patterns and Practices” @salesforcedocs
▪ “Chapter 6 - Firewall Architectures”; Building Internet
Firewalls (2nd ed); Zwicky, Cooper, Brent; O’reilly 2000

20. Thank You!
Enterprise Integration
Architecture
Lessons learned along the way
Uruguay
Salesforce Developer Group
August 13, 2015 #UYSDUG
Aldo Fernandez
Technical Consultant
@aldoforce
#uysdug
#integration
#architecture