Hybrid & Multi Cloud Integration Principles

This is a collection of Work in Progress Hybrid and Multi Cloud Integration Principles. These principles are NOT meant to be used as is but as the basis for discussion, selection, modification, and alignment

Application OVER Technology OVER Custom OVER Direct Connectivity
  • 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
Availability via Fire/Forget
  • 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.
Business Process Separate from Technical Orchestration
  • 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.
Business Process
  • Contains Business Level Processing
  • Changes When the Business Changes
  • Does NOT Change when Back-End Systems Change
  • Should NOT Include Technical Details
Technical Orchestration
  • 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
Minimize Application Modifications
  • 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.
Minimize Integration Technical Debt
  • 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.
Platform Deployment Driven by Locus of Applications
  • 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.
Pre-Built Direct OVER Platform OVER Custom Direct Integration Flows
  • 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.
Pre-Built Direct
  • 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
Platform Based
  • 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
Custom Direct
  • 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
Prebuilt OVER Customized OVER Custom Platform-Based Flows
  • 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
Put the Ugliness in One Place
  • 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.
Reduce Dependencies via Loose Coupling
  • 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
Standards Based Integration
  • 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.
Well Defined, Standardized APIs
  • 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.