What does it mean for one enterprise application to 'talk' to another?

Pick a technical conversation, any conversation, going on in your enterprise between pure IT people and business IT people. If my experience is anything to go by, about 50% of the technical terms being bandied about in that conversation have incompatible definitions in the minds of the conversants.

Here are some choice words/phrases which are regularly the subject of silent misunderstandings in IT conversations: secure
workflow
content management
scripting
compatible
standard
configurationIf only I could reclaim the time wasted in conversations I've had thanks to misunderstandings of words like these! It's scary how close you can get to committing time and money to a project where some of these terms are critical to, but not part of the shared vocabulary of the stakeholders.Some quite benign sounding words deserve to be on this list too. How about this one: talkWe all know what it means to 'talk' right? There can be no ambiguity about what we mean when we say that system A talks to system B, right?

In recent years, I've formulated the opinion that this four letter word is the most misunderstood, misconstrued word in the whole pantheon of IT-speak.

Somehow in this industry, we have developed a forked universe culture between business people and IT people. We just don't speak the same language. We do not communicate well. Instead, we relate to each other by means of a shared suspended disbelief about the gaping inadequacy of our shared vocabulary. A linchpin of that illusion is that we claim to understand what both sides mean when it is said that System A "talks" to System B.

To see this in action, all you need to do is get yourself into a room with some business people and some IT people. The business people will white board a vision for the new business IT system that involves systems "talking" to each other all over the map. The depiction will most likely feature data flowing between discrete business processes to form aggregated business processes.

While this is going on, the IT people will be nodding vigorously and perhaps even throwing in staccato "yes, yes" phrases to speed the business person along. After all, what is being expressed is (a) *obvious* and (b) that is not how systems will talk to each other in practice. The poor "suit" doesn't understand IT.

When the process of explaining the business process from the business' perspective has completed, the technical people will take to the floor and draw their own diagram for how the business vision can be realized. It too will feature lots of systems "talking" to each other. However, this incarnation of the vision will be heavily infused with instantiated objects, sub classed singletons, protocol bindings and persisted state spaces.

It's around now that a glaze, thick enough to baste a turkey with, descends over the eyes of the business people who leave the meeting feeling short changed by it all. The IT people claimed to understand the business picture and then proceeded to draw the IT picture. The business people understood the business picture but did not catch a single syllable of the IT picture. Final score? 2-1 to the techies.

Now obviously, in commercially-driven IT, this scoreboard is precisely the wrong way around. To turn the score around, we need to establish a shared vocabulary. Key to that shared vocabulary is the word 'talk'.

To the business, the word 'talk' means that individual systems that house data can flow that data into and out of other systems. To the business, the most important thing is the data - not the algorithms that process that data. Simply put, 'talk' is data-centric in business-speak.

To the IT guys, the word 'talk' means that individual systems expose APIs through which their internal algorithms can be invoked. Invoking these APIs has the effect of changing the data. Simply put, 'talk' is algorithm-centric in IT-speak.

Are the two world-views irreconcilable? I don't think so. I strongly believe it is possible to build systems from a data-centric interpretation of 'talk'. Perhaps that is why I'm so fond of open data and open data standards such as XML. Perhaps it's also why I despair when I see XML being used as an API technology as in SOAP. To my mind, all this does is increase the dissonance between the business and IT world views. When a business persons says "just use XML" they are referring to data flowing around processes. When a technical person says "just use XML" they are more likely referring to function calls flowing through APIs.

Cutting to the chase, I think we need to get to the point where we can implement business systems using the same vocabulary as the business people who dreamt them up in the first place. Sadly, I think from that perspective, we were better off in the '70s - back in the days of data flow based approaches to system development. Unfortunately, it's an approach that has been steamrollered by the algorithm-centric fascination with objects and procedural decomposition of more recent times.

To build a system from the diagram that the business people draw, we need to build the system to be data-centric. As long as we allow the pre-dominantly API-centric world view of the IT community to dominate the discussions, we will continue to talk past each other instead of with each other.

Join the newsletter!

Error: Please check your email address.

More about IT People

Show Comments

Market Place