Perfect Integration 5 - Common language: indirect translation

Number 5 in the series, this post is about indirect translation, in contrast with the direct translation shown in the previous post, which came with costly, exponential dependencies

When looking towards large-scale use of translators, e.g. the European Committee in Brussels, it is easily observed how these dependencies can be greatly reduced: all languages are first translated into English, French or German, after which either one of those is translated into the final destination language

Of course this is doubling the effort involved, as everything has to be translated twice. However, an intermediate channel is created that everyone can use: compare that to villages and towns, each digging and building their own roads in order to travel towards each other, or a municipality that builds a highway for all to use; in this case, all that has to be done is just construct a small piece of road to connect to the highway, considerably reducing the effort, time and money involved

Thus, in the European Parliament a common language is defined, viz. English, French and German. In the specific example of the European Parliament the more than 500 possible combinations are now reduced to 75.

For political and linguistical reasons the choice is made to support more than one intermediary language in the European Parliament for the purpose of interpretation: real-time translation between humans. Spanish and Italian are languages that are very closely related, but Serbian and Chinese have nothing in common. The chance of finding an interpreter that speaks Italian as well as Spanish is far greater than finding one that speaks Serbian as well as Chinese

In general any language would suffice for discussing any topics: grammar and syntax allow for carrying across messages that are complicated as well as simple. Languages that couldn't be compared to or fit onto each other could be languages that are far apart on an evolutionary scale, for instance languages that are only used by a few people living in tribes in the Australian bush and only have a small vocabulary and no noticeable grammar, in relation to an average language in the modern world with a vocabulary of tens of thousands of words and a complicated grammar that allows for a few different past tenses.
In IT, there are such differences as well: if you have to hand-translate in between an old-fashioned mainframe and XML, the distance would be simply too great. You can land a Boeing on a highway in case of emergency, but if you do so on a trail you're a lot less likely to succeed

So what needs to be done in information exchange, after establishing the semantics, is finding a common language: in interfaces, this common language is formed by a common, or rather generic, intermediate form. Both parties can (and rather, should) still speak their own language, but the translation is done "in the middle".
This interface, like the languages, needs to be able to hold the logical structure of the desired information interchange, and the functionality desired.
When this logical and functional structure has been designed, a format needs to be chosen in which this can reside. As with languages themselves, it doesn’t really matter what exactly this format is, as long as it is easily accessible, commonly available, as simple as possible and fit-for-purpose

Translating that to IT, first of all a logical and functional design has to be made to determine the scope of the common subset, and determine which exactly is the definition of the various (sub)topics and functional entities, as shown in Perfect Integration 3 - Common language: semantics first
Such constructs are generally referred to as Canonical Models, or Common Object Models.They effectively establish a business language that is spoken within the enterprise, making the extreme diversity of the underlying IT-landscape fully transparent, or rather, from a business point of View, irrelevant

Canonical Models do, what IT should have done ages ago: let the business not bother about the trivialities of IT.
Direct translation enables this in an efficient way: rather than sending specialised applications on a language course and teach them the business language of their freshly-joined company, the translators will do that work for them.
Indirect translation perfects this in the best cost-efficient way: professional translators translate the diverse application mumbo-jumbo to the generic company business language: a win-win-win situation

This concludes the first 5 posts, dealing with the semantical level. The next two posts will go one level deeper, and drill down to the syntactical level. After that, we'll resurface to the semantical level again, to deal with addressing in general

In post number 6, a word about interface message formats, or rather: if I were to define such an interface, what are my choices?