Perfect Integration 3 - Common language: semantics first

This post will elaborate on messaging and transformation (part I), and explain how information exchange works in the daily world, considering simple or complex information exchanges. That will then be related to IT, and the basic ways of “writing down” information in IT will be explained.

If you want to have a chat with someone else, what do you do?
First, a common theme to discuss has to be found - usually not that hard. The favourite ones in e.g. IT usually are new technologies, cars, and the occasional sports.
The topics then have to be found, which is a bit harder. Do we discuss hardware technologies, or software technologies, or is it architecture or open source we want to discuss?
If the topics have been identified, last but not least the definitions have to be checked: are we talking about the same subjects?

The Greek philosopher Socrates filled entire conversations, and books, with merely trying to establish that he and his counterpart were talking about the same thing. There are numerous occasions on which he talked half a dozen times or more to someone, only to mutually agree on the fact that they didn’t mean the same thing while using the same word, and then end the discussion.

Nowadays this is a serious topic in integration: establishing a common mindset and “dictionary”. Semantic Interoperability is a very interesting and worthwhile item to closely investigate and embrace, before engaging any inter-company integration. Even when conducting integration within a mid-sized enterprise itself, it is very valuable to have a common dictionary that explains in detail what words mean to all parties involved.

After all, what is the use of a service-oriented enterprise and its service repository if the function of a certain service can be interpreted in more than one unambiguous way?
So, for argument's sake, let's assume that you have

• an elaborate dictionary of all the relevant business words used in your enterprise
• and their full, unambiguous meaning
• complete with the structures they fit in
• and the order in which they do so
• for each and every business process they occur in

Now, on a semantical level, everything is clear: the most important part has been successfully completed. Secondly, agreement has to be reached on another level: the syntactical part

When setting up information exchange between two parties, life can be simple. A common form will have to be chosen, with which both parties feel comfortable: is it OK to converse by fax only, or is the topic so intimate that it can only be done face-to-face? When living in entirely different time zones, it will be practical to have a way of conversation that is not that interactive, e.g. writing old-fashioned letters or sending emails. And when living far apart, it is a costly business (well, at least it always used to be) to make long phone calls.
In IT, this common form is (again) called an interface. The interface chosen should always be a message, a static representation of an event. The idea is that an information system itself takes its dynamic, internal data, and exports that outside of its own system in the form of a static message. That message will always reflect the state of that small subpart of the system at that specific time.
The other system is expecting a similar message, and will import that into its own system, using the static data to update its own dynamic data.
To bridge the gap between the two systems, the one static message will have to be converted to the other static message, preferably outside the systems

This transformation of messages, which involves designing and creating interfaces, also known as interfacing, can be compared to the day-to-day world of translation of languages. People who speak different languages can’t understand each other unless one speaks the language of the other. However, the scale on which a language should be mastered differs considerably from that of a simple interface or service.
On the other hand, if you just met this mysterious foreigner and only want to exchange a few romantic words over a warm campfire, usually a 30-minute crash-course suffices.

But, being an application or system in an enterprise IT-landscape, there regularly is a need for far more than just mere pleasantries: it therefore is fair to compare interfacing and servicing to the every-day art of translating and interpreting languages

That, we'll do in part 4. Put on your outside-in hat please