Perfect Integration 2 - Common subset and transformation

Number two in the series, this post deals with the common subset found on all levels in the previous post:

• what is the shared interest (Business)
• which information do you want to share (Information)
• which definitions are mutually exchangeable (Information Systems)
• how do you want to exchange ideas (Infrastructure)

Information exchange form: messaging
After having agreed on mutual business and information to be exchanged, transferring information in a certain message layout from and to systems is the logical next step.

As different systems almost always produce different message layouts, there has to be a conversion in between these different message layouts: this conversion is called interface, where a message that originates from one system is converted to a message that has another system as destination

This conversion is purely on a physical level: the logical and functional information in the message should not be altered. Good interfacing doesn’t involve more than simple formatting changes like periods to comma’s or vice versa in decimal fields, and translation from and to solid standards such as ISO and EAN. There are many, many standards on the business document level such as EDIFACT and X12, HL7, SWIFT, ClieOp, etcetera. Normally, in mature and high-volume high-frequency industries such as banking, automotive and logistics, these standards are easy to find and hard ( = expensive) to deviate from.
In less mature industries or those closer to government and non-profit, one will find that people find the leisure to play around with non-interoperable standards by usually inventing their own XML and SOAP. More about that 2-3 posts up

Information exchange method: transportation
Messages need to be transported from the originating system to the destination system (and vice versa). Ideally, a communication protocol must be chosen that is supported by all parties involved. A communicastion protocol is nothing more than a worldwide standard: telephone, television, fax, telex, the internet: all thouse wouldn't have been possible without simple, static, clear and unambiguous standards.
Fortunately there aren’t as many communication protocols as there are application systems, so a choice can be made. Communication protocols are, as opposed to information systems, highly standardised on a global scale. Therefor a choice can be made, instead of having to convert one transportation protocol to the other. Next to that, almost all (simple) transportation protocols are free. The ones that are more complex and offer a higher degree of functionality and built-in reliability usually aren’t free

However, when integration is considered to be “door-to-door”, meaning starting at the very originating system at e.g. one company, and ending at the very destination system of e.g. another company, there almost always is some kind of conversion involved, as chances are slim that both systems are connected end-to-end on the exact same common communication protocol. From a security point of view there also are many restrictions that simply won't allow for a direct connection between an internal system and external system

The integration topic: transformation
Information exchange is the only goal of integration.
The only purpose is doing business on a cost-effective basis in order to make or save (more or better) money.
The integration theme is to establish a common subset, and this subset can physically be realised via transformation.
Messaging and Transportation can be defined as the two main methods of integration.

Transformation is the sole integration topic: business, nor information, nor information systems, nor infrastructure are alike when integration is exercised on an enterprise scale

Standardisation: dynamics and statics
Standardisation is key to integration. Standardisation makes matters static, and worth the effort of translating. Not standardised or volatile things are dynamic, and impossible or at least very costly to automate, and keep automated

Gas, electricity and water are so standard that we can actually put the plumbing in our floors, ceilings and / or walls. Gasoline is so very standard that we can get it everywhere, because it will always be the same.

The fact that these products are so very static as well as standard, is no coincidence. Electricity, gas and water nor gasoline have changed over the last decades or centuries.
Like I have argued in every single post so far, standardisation resides in the lower architectural IT layers, and not in the top ones, as dynamics at the top, in the business where people are involved, are far larger than at the bottom, the infrastructure where machines are involved.
No one has rewritten the TCP/IP stack or the HTTP protocol. Have databases significantly changed?

So, standardisation in IT can be achieved, and already is partially achieved. But, it will only be achieved “down below”, and not in the business area. Business simply is way too dynamic for that

So how do we achieve standards between dynamic businesses? That, in the next post