Skip to content
Software Architecture Guide

Integration Style

Explanation

Section titled “Explanation”

Companies often run several applications that must work together. An integration style is the general approach used to connect them.

Four classic styles exist (the fourth, remote procedure call, is covered in its own article):

  • File transfer. Each application writes files with data that others need. It also reads files that other applications wrote. See the article File Transfer.
  • Shared database. Applications store the data they want to share in one common database. See the article Shared Database.
  • Remote procedure call. See the article Remote Procedure Call.
  • Messaging. Applications connect to a common messaging system. They use messages both to exchange data and to trigger behavior. See the article Messaging.

Messaging moves packets of data frequently, immediately, reliably and asynchronously, in formats you can customize. Asynchronous means the sender and receiver do not have to be up at the same time.

Choosing a style is an architectural decision. Teams can record it with the options considered and the reasons for the pick. See the articles Architectural Decision and Architecture Decision Rationale.

Example

Section titled “Example”

A shop’s order system must pass new orders to a warehouse system. The warehouse system is sometimes offline for maintenance. The team compares the four styles. The two systems are not always running at the same time, so they pick messaging. The order system sends a message and carries on. The warehouse system reads it later. The team records the choice and the reason in the architecture document.

Trade-offs

Section titled “Trade-offs”

Each style gives up something to gain something else.

  • File transfer needs data to be transformed between the formats of different applications. Output from one application rarely fits another exactly. Mature tooling exists around file formats, though.
  • Shared database gives strong consistency through transaction management. But designing one schema (the structure of the data) that serves many applications is very hard. Some critics call the shared database a deep coupling point. It raises the risk of changing the applications. Many respected architects advise avoiding it.
  • Messaging keeps much of the decoupling that file transfer offers. It also lets sender and receiver work at different times, which improves reliability.

Checks

Section titled “Checks”
  • The document records which integration style was chosen, the alternatives considered, and the reason for the choice.
  • If a shared database is used, the document explains how one schema serves all applications and how changes are controlled.
  • If file transfer is used, the document describes how data is transformed between application formats.
  • If messaging is chosen for loose coupling in time, the document states that sender and receiver need not be available together.
Section titled “Related”

Sources

Section titled “Sources”