System A needs to talk to System B. Standards are the ideal to achieve that, but pragmatics often dictate otherwise. Let’s have a look at what approaches there are, and their pros and cons.

When I looked at the general area of interoperability a while ago, I observed that useful technology becomes ubiquitous and predictable enough over time for the interoperability problem to go away. The route to get to such commodification is largely down to which party – vendors, customers, domain representatives – is most powerful and what their interests are. Which describes the process very nicely, but doesn’t help solve the problem of connecting stuff now.

So I thought I’d try to list what the choices are, and what their main pros and cons are:

A priori, global
Also known as de jure standardisation. Experts, user representatives and possibly vendor representatives get together to codify whole or part of a service interface between systems that are emerging or don’t exist yet; it can concern either the syntax, semantics or transport of data. Intended to facilitate the building of innovative systems.
Pros:

• Has the potential to save a lot of money and time in systems development
• Facilitates easy, cheap integration
• Facilitates structured management of network over time

Cons:

• Viability depends on the business model of all relevant vendors
• Fairly unlikely to fit either actually available data or integration needs very well

A priori, local
i.e. some type of Service Oriented Architecture (SOA). Local experts design an architecture that codifies syntax, semantics and operations into services. Usually built into agents that connect to each other via an ESB.
Pros:

• Can be tuned for locally available data and to meet local needs
• Facilitates structured management of network over time
• Speeds up changes in the network (relative to ad hoc, local)

Cons:

• Requires major and continuous governance effort
• Requires upfront investment
• Integration of a new system still takes time and effort

Ad hoc, local
Custom integration of whatever is on an institution’s network by the institution’s experts in order to solve a pressing problem. Usually built on top of existing systems using whichever technology is to hand.
Pros:

• Solves the problem of the problem owner fastest in the here and now.
• Results accurately reflect the data that is actually there, and the solutions that are really needed

Cons:

• Non-transferable beyond local network
• Needs to be redone every time something changes on the local network (considerable friction and cost for new integrations)
• Can create hard to manage complexity

Ad hoc, global
Custom integration between two separate systems, done by one or both vendors. Usually built as a separate feature or piece of software on top of an existing system.
Pros:

• Fast point-to-point integration
• Reasonable to expect upgrades for future changes

Cons:

• Depends on business relations between vendors
• Increases vendor lock-in
• Can create hard to manage complexity locally
• May not meet all needs, particularly cross-system BI

Post hoc, global
Also known as standardisation, consortium style. Service provider and consumer vendors get together to codify a whole service interface between existing systems; syntax, semantics, transport. The resulting specs usually get built into systems.
Pros:

• Facilitates easy, cheap integration
• Facilitates structured management of network over time

Cons:

• Takes a long time to start, and is slow to adapt
• Depends on business model of all relevant vendors
• Liable to fit either available data or integration needs poorly

Clearly, no approach offers instant nirvana, but it does make me wonder whether there are ways of combining approaches such that we can connect short term gain with long term goals. I suspect if we could close-couple what we learn from ad hoc, local integration solutions to the design of post-hoc, global solutions, we could improve both approaches.

Let me know if I missed anything!