Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Enterprise Integration Architecture... or lessons learned along the way

Enterprise Integration Architecture... or lessons learned along the way

What are the components of a good Salesforce Integration Architecture? The Salesforce1 Platform offers architects and developers a wide array of integration technologies and recommended patterns. However, without the correct Integration Architecture and technology infrastructure your projects and solutions will be at risk for performance, scalability, data integrity, and many other problems.

On this session we are going to talk about the different lessons learned working on different enterprise integration scenarios.

Aldo Fernandez

August 13, 2015
Tweet

More Decks by Aldo Fernandez

Other Decks in Technology

Transcript

  1. 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.
  2. 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)
  3. Agenda ▪ What is an Enterprise Integration Architecture? ▪ Integration

    Architecture vs Integration Patterns ▪ Components of an Integration Architecture ▪ Enterprise Salesforce Integration Architecture scenarios
  4. 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
  5. 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 +
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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)
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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