Some time ago I wrote a post where I did a little thought experiment. I toyed with the idea of ​​using the structure and logic behind Twitter to manage the transfer of information within the transport system. Since then, I thought pretty hard about this. Many have also contacted me and expressed interest in these ideas. So, now a little while later, it is time to revisit this topic and – perhaps – drill a little bit deeper than last time.

I think when I write. Or rather, think by writing. And this is what happened as I wrote the last post. I’ve always liked to turn the perspective around, and when I wrote the last post, I decided to let Twitter work as a communications structure for freight transport. The purpose of this exercise was to change the known and familiar and to explore something from a different angle. And now, when this first post has marinated for a while I realize that the idea refuses to leave me alone. But instead of continuing to talk about Twitter and find similarities, I think it is time to try a generalization of the concept.

Normal communications in B2B (business to business) is in most cases done the traditional way. With a sender and one or more recipients. The sender sends messages to recipients. Everyone involved is in agreement on how information should be structured. All agree on the semantics (what the various concepts and data means). It is this that makes the integration of information systems so incredibly complex. That every single relationship must be specified in advance in every detail.

Of course, we try to standardize. I myself am active in a large standardization project. The problem with standards is that they all require everyone else to join their particular dialect of reality. And that will not happen. The work of the many standardization efforts is of course not made in vain. On the contrary. With the help of standardization more are able to step into the electronic world. But standardizing messaging feels a bit like building a rocket to the homing pigeon, which will still be a pigeon when finished.
A homing pigeon - this is in essence how communication still works

A homing pigeon – this is in essence how communication still works

Let us review the main concepts a bit. Consignor. Recipient. Message. Structured information, agreed details. Sounds safe, right?

Well…

I would actually like to scrap the concept altogether.

I want us to stop talking about the sender as someone who sends messages to predefined recipients.

I want us to stop talking about messages that have pre-defined layout and content.

I want us to stop talking about recipients that must agree with each possible sender on how to communicate.

I want us to stop talking about how to find the ”universal message” that is generic enough so that it can be adapted to any situation (which I believe is impossible).

I want us to introduce new concepts.

I wish that when we talk about the sender, we mean someone who publishes/broadcasts information.

I want us to talk about data streams that are published and documented by the sender.

I want us to talk about subscribers that choose which streams they wish to access.

I want us to talk about exactly what I wanted to try to explain in my last post. Imagine if we had a non-hierarchical, hyperlinked, sender-centric information system! 

The transporter subscribes to data streams from the vehicles, barcode readers, order systems, vehicles, computers, etc. The consignor subscribes to data streams from the carrier and the receiver. Everyone that produces data makes it available via APIs (an interface that enables IT systems to communicate with each other). These APIs are documented and published, and anyone who wants to join can be there once for all design their subscription. This is where we can learn from the pros. Of Twitter, Google and Facebook. But also about how this is already done by the now quite old (!) RSS technology.

The social networks are built on data sharing. The publisher of the data does not know how this data is used by the subscriber and the subscriber can bring together multiple data sources to create new data sets and new value.

All APIs will not be public, of course. Some will require identification and special access. But it does not matter. Once we’ve changed to an information infrastructure based on these principles, we’ll never want to go back to an electronic version of the homing pigeon.

And you know what the best part is? This change can be gradual, from relationship to relationship. Thus, we can capture the benefits from scratch. For senders, this will be a big change that will save money. For the former recipients (now subscribers), it is about building on existing receiving system so that they can handle a data stream that may need to be filtered. The information received could be combined with several other data sources, even in real time. All without any of the senders needing to be asked first!

I will continue thinking about these concepts and maybe, just maybe, write additional posts later on. Until then, please comment below!

0