Hybrid & Multi Cloud Integration Principles

• Statement: Choose application adapters over technology adapters over direct (adapter-less) integrations
• Rationale: Application adapters simplify integration by providing easy access to the business objects and business functions provided by the application. Technology adapters are widely reusable, but provide no application-specific help to integrate to an application. Direct connections to applications provide no opportunity for reuse and are likely to break with any change to the application.
• Note 1:
  Pre-Built Application Adapters (e.g. Oracle, SAP)
  OVER
  Pre-Built Technology Adapters (e.g. REST, SOAP, JMS, FTP)
  OVER
  Custom Developer Adapters (Using adapter SDK)
  OVER
  Direct API Calls
  

Adapters

• Simplified Integration with Applications
  • Rich and Intuitive Designer Wizard
  • Business-Centric View of the API Interface
  • Bidirectional Integration
• Automatic Discovery of Application Assets
  • Business Objects, Services, Events
  • Support for Standard and Custom Objects
• Plug and Play
  • Run on-premise and in the Cloud
  • Point and Click to Start Using New Adapters

• Statement: Utilize Fire/Forget for distributed application integration with different SLAs where no response is expected
• Rationale: SaaS Applications in different clouds have different schedules for updating and patching, making synchonrous integration not always possible. Using an asynchronous fire/forget is a potential appriach to address this challenge.

• Statement: Keep business process logic separate from the technical orchestrations.
• Rationale: Making a clear distinction between technical aspects and business aspects facilitates maintenance of both. Technical aspects change when the underlying systems change whereas business aspects change when the business changes.

• Contains Business Level Processing
• Changes When the Business Changes
• Does NOT Change when Back-End Systems Change
• Should NOT Include Technical Details

• Contains Lower-Level Technical Details
• Can Be Exposed as a Business Service Where it Isolates the Business Process from the Technical Details
• Dependent on the Underling Back-End Systems
• Should NOT include Steps that will Change if the Business Changes

• Statement: Extensive, intrusive modifications to existing applications should be avoided.
• Rationale: Some minor modifications may be required to support connectivity, but requiring extensive modifications defeats a major reason for integration, namely to make use of existing functionality with minimal development effort.

• Statement: Avoid integration implementation short cuts that will create the need for extensive refactoring at a later date.
• Rationale: Time and budget pressures commonly cause developers to implement an easy short-term solution instead of a better long-term solution. Over time these short cuts accumulate and create the need for extra development effort to correct the problems introduced by the short-term solutions.

• Statement: The platform used to integrate applications should be deployed to the location (cloud, on-premises) where the majority of applications being integrated are deployed.
• Rationale: Deploying the platform “near” the applications reduces latency and bandwidth requirements. Security may also be simplified.

• Statement: Choose pre-built direct integrations over custom integrations using a platform over custom-built direct (point-to-point) integrations.
• Rationale: A pre-built integration is the fastest and easiest way to integrate systems. Custom-build direct integrations cause tight coupling and maintenance problems. Custom integrations using an integration platform isolate changes to the platform.

• Primarily SaaS Focus
• Therefore Vendor Supplied and Maintained
• Commonly Utilized and Mature Information Flows
• Adapter NOT Required
• Reduced Maintenance
• Quicker Time to Deployment
• Limited Integration Flexibility

• Increased Flexibility
• Commonly Makes Use of Adapters
• Can Assist with Exposing Existing Functionality as Services
• Be Aware of Business Logic Bleed
• Be Aware of Business Process vs Technical Orchestration

• Direct Custom Integration Flow
• Enterprise Maintained
• Increasing Complexity
• Technical Debt Builds Up Over Time
• Fragmented Intelligence and Monitoring
• Quicker Initial Time to Market
• Adapter Not Commonly Utilized

• Statement: Choose a prebuilt integration flow over customizing an existing integration flow over building a custom platform-based integration flow.
• Rationale: An existing, prebuilt integration flow is the fastest and easiest way to integrate two applications. Customizing an existing integration flow is faster and easier than building a new integration flow

• Statement: When a elegant integration is not possible, keep the ugly aspects of the integration in a single place.
• Rationale: Putting the ugliness in one place reduces maintenance costs by keeping the rest of the solution clean.

• Statement: A communication intermediary between Cloud services should be utilized to separate the concerns of location, implementation platform, the time of communication, and the used data format
• Rationale: Reducing the dependencies between distributed cloud services and between individual components of the cloud services increases the flexibility to address concerns such as cloud service failure, replacement, update, and removal

• Statement: Integration architecture must be based on open standards, wherever possible
• Rationale: The integration strategy should embrace open and widely adopted standards in order to promote interoperability and avoid vendor lock-in.

• Statement: Formally define and standardize the APIs that are used for application integrations.
• Rationale: Using well defined, standardized APIs for integrations creates more stable integrations, limits the impacts of changes, and facilitates reuse.