Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
18 October 2005

Minimal integration 3: send the right information

By Andrew Clifford

Integration projects struggle because they send the wrong information between systems. Adopting simple rules for data content and structure can greatly simplify integration.

Many integration projects naively accept the data content and structure of existing interface formats. Later they find that the interfaces do not meet their needs, but it is too late to change them. To avoid this, we need rules for data content and structure.

Some rules come from our need to run and change systems independently once they are integrated.

  • To allow for technology change, interfaces should only ever use display format data, so that it can be translated to different coding schemes easily. Never send numbers using their internal binary representation. Provide escape sequences for special characters.
  • To allow for data changes, encode interfaces using only common business data. Never send meaningless internal identifiers in interfaces (these are often used in database design), only send the true business keys. If you must send an internal identifier, dress it up as something meaningful such as a "sender's reference for product".
  • To allow for timing and processing changes, pass all the information that is required to complete the job in a single instance of the interface.

This last rule is the most important. Each instance of the interface should be a logical unit of integration (LUI), an indivisible business transaction that the recipient can and should action in its entirety, or completely reject.

This avoids "chatty" interfaces, where the sender makes multiple calls to the recipient to achieve one meaningful business transaction. Chatty interfaces require more control code and do not give the systems the separation they need.

This also helps understand batch interfaces. The LUI can be a whole file, as in a daily sales summary, or a series of transactions enclosed within control totals. The whole file is accepted or rejected. Alternatively, the LUI could be each individual record. The receiver can accept and process some records and reject others. The important thing is that both ends agree on the LUI, and implement the necessary controls based on this.

Where both systems are custom systems, both can implement the LUI directly. Usually the receiving system should drive the definition of the interface. If the sending system publishes to multiple recipients, then it should drive the definition of the interface.

If one system is a package and one a custom system, implement the LUI directly in the custom system. Develop an interface layer around the package so that it implements the LUI. Never implement a package-specific interface in the code of an independent system.

Where both systems are packages, define the LUI and then build an interface layer at both ends to implement it. Be cautious of vendors' claims to have interfaces to other packages: I have never seen one that works.

However you define it, you end up with a parcel of data which is meaningful in terms of your business, that needs to be sent from one system to another. We need to find a way of turning this into an implementable interface definition.

Next week I will describe how extensible markup language (XML) meets this need so effectively.

Next: Minimal integration 4: XML is beautiful

Subscription

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Find out more