Interfaces - No application is an island

In most organisations, there is a monstrous web of interfaces. This tangle gets periodically reviewed by application developers as they replace some of the creaking legacy systems.

There are many ways that systems may interface with one another, and have attempted to collect together the many ways into a single document. Of course, you may have one or two extra up your sleeve and I would be delighted to hear from you, to add them to my document.

I have organised the choices about interfaces into the following broad categories:

  • Transport mechanism
  • Organisational data definition
  • Triggers
  • Detection of changes

We will visit each of these areas and see what possibilities there are for each one.

Transport Mechanisms

  • Batch file
  • Simple
  • Auditing almost "built in"
  • Not responsive
  • Tools to analyse are simplistic

There are obviously variations on this theme. The interface file format could be fixed width (although easy to produce - very limited), delimited (choose the delimiters carefully and account for the possibility that a delimiter could appear in the text), HTML table (can be read directly into browser or Excel), or XML (read directly into IE5, can be processed by XSL queries, and more tools wll be available).

Database table

  • Very similar to batch file interface
  • Tools are more sophisticated
  • Both systems need to be ready at same time

Online Procedure or Encapsulated View

  • Very responsive
  • Needs contingency if sending system not available
  • Security and control issues (particularly performance)

Publish and Subscribe

  • Asynchronous
  • Messages can be responsive
  • Security of subscription needs to be controlled
  • Requires purchase of middleware (e.g. IBM's MQ Series)

Client based interface

Data is pulled from one system by a human operator and loaded into another

"Rekeying" interface

Argh! A person takes a paper or electronic report and renters the data into another system.

It happens very often around a "real" interface for those "exceptions" not handled by the interface.

Data Definition

Central Enterprise Model

  • Repository of enterprise wide definitions

As Required

  • Agreed between parties involved in interface.


  • Groups of systems form their definitions (often at country level) and these are then mapped to each other or central values.


Time based

  • Run interface at a specified time.
  • Either the interface sends all data that fits a particular criteria or is "changes only".

Event trigger

  • A particular type of transaction in the sending system generates a "message" to the receiving system.

Event detection

  • An agent runs periodically, or in a paralell thread that detects particular criteria and runs the interface.

Manual trigger

  • A user requests the interface. Either because of dependancies that are difficult to code (e.g. cross system), external to the systems themselves or simply beyond the scheduling software in use.

Receiving system trigger

  • The receiving system triggers the interface. This is common in interfaces that read from database views or stored procedures in other systems.

External trigger

  • A condition outside of the receiving or sending system causes the interface to run. This is often the case where dependency checking is allowed in the scheduling software.

Detection of changes

Audit trigger

  • Changes to data and their time stamps are stored for perusual by the interface when it runs.
  • Changes often have to be categorised into simple events by determining groups of changes that have occured and reconstructing "what happened".

Storing interfaced information and detecting changes

Store previous values

  • As an interface runs, it stores the values it sends to a receiving system. A subsequen interface can then check values it obtains with previous values, if they are different, it sends the value.
  • There are variations - the changes can be held in one area for all interfaces or in interface specific repositories.

Storing "event stubs"

  • The application stores the fact that an event occurred and some key information about that event. Key information needs to be kept up to date or key adjustment events need to show the value of new keys. Events may be stored separately, on original records or as foreign keys to event groups.
  • This can be a useful technique if the interfaces reconstruct events from stored data. It does take interface design deeper into the structure of the application - an acknowledgement that no application is an island.

As they happen

  • Events are sent as messages more or less real time. These may go to a message hub or may be sent directly.


Interfacing can be done in many different ways. The technique(s) used for interfacing can have an affect on the success or otherwise of the resulting systems.

Computing Articles