Any organization that relies on more than one system or application will find the need to integrate those systems and applications. Yet, as common as this need is and as many software packages have been released to help the process, a lot of teams still lack an understanding of the fundamental process of performing application integration. They may deliver a solution that transfers data between systems, but often the systems will end up tightly coupled and fragile as a result. Successful integration projects don’t just transfer data from system A to system B; they also allow each system to independently change and grow without breaking anything.

So, to help, I’ve put together a cheat sheet. It breaks down the application integration process into a handful of primary steps and offers some suggestions for what to keep in mind for each step. It’s a contract-first development process.

  1. Define the contract. Establish precisely and explicitly the minimal information each system needs and when. Confirm that the partner system can and will provide this information under the proper circumstances. This is the contract.
    • How should each datum be identified? Integer, string, GUID?
    • What values/fields are needed in each datum, in the form of name and data type?
    • What are the semantics of the data, beyond the names and basic data types of the fields?
      • What do the normalized values look like? E.g.
        • Are all datetimes in UTC?
        • Have domain-specific values (e.g. product names) been canonicalized?
      • How would the data be categorized?
        • Commands
        • Queries
        • Query results
        • Telemetry
        • Notifications
    • How long must the data be retained by the source system?
      • If the data is transferred once, must it be transferrable again?
    • What are the necessary performance characteristics for the contract?
      • Frequency
      • Load
      • Latency
      • Throughput
  2. Build the interface that implements and represents those contract details.
    • The key is that, whatever it is, the interface:
      • explicitly represents the contract to the best of its technical abilities, and
      • hides the implementation details in the partner system from the source system.
    • Different techniques and patterns are available at this stage, including but not limited to:
      • Database tables, views, or functions with the appropriate field names and datatypes
      • Pub/sub queues containing messages matching an appropriate schema
      • Direct connect web services
  3. Connect each system to the interface. Each system will be attached independently because the interface is a clean break between the systems.

If you find this useful, or have any suggestions or changes, please let me know.