Sometimes an idea crosses your path that you have never considered before. One that is outside your field of awareness (an unknown unknown). A few weeks ago our guru, Dr. Peter (he prefers a simpler title, but that one makes the most sense) was talking about a communication model that described how complex layers of information might be built using a framework of “abstractions.”
Rapunzel: How to disentangle complexity?
While the whole thing can be wordy and a little vague, the main idea is sensible; how to disentangle complexity? You start at the point of emergent models and track the stage gates. At the beginning you have simple physical communication. As each layer is built it moves to a higher level of abstraction.
Layer one is simple, a communicator. Now imagine one computer connected to a storage device. Nice and simple, a cable and a communication protocol. But hold that thought (the communication protocol is level 2. This is the data link or “frames” layer). Once you hit the first network layer (two, or more) machines have to talk to each other over a “network” connection. You have to manage how that communication happens, when it happens and where (back in the old days you didn’t have full network coverage everywhere, so signal often “dropped out”).
You define a “transport” method; how a message is segmented, acknowledged and “multiplexed” (1-1, 1-many, many to 1, many-many) – pager, text, voice call, just ping me, 5 minute standup, boardroom boredom, town hall, etc.
Then we hit another stage of complexity. When you begin to add more nodes and traffic to a network. There has to be a kind of traffic planning level (prioritization); stop lights, go lights, be ready lights. That is called the “session” level. Then you hit another plateau; how the encoding and decoding should be presented (presentation level). Do you need encryption? In our traffic model, that might parallel a driver licensing system (user access), a toll system (payment gateways), a slow lane or cycle path (freemium, premium).
In our road traffic analogy you don’t need to use colored lights. You might track the honk level of car horns. You could lower a railway type crossing barrier across the carriageway. You could add an intelligent asset and position a policeman at your intersection.
At the top level, the user or receiver level, the concept mirrors the user interface queries in software development. How should the interface function; what must it do? How should the receiver use it. In our work, we often disregard this layer because we are primarily concerned with the connectivity, transport and sorting of data. The more involved work of understanding the business case of our customers is both time consuming and ultimately wasteful (…of our time).
The useful part of the OSI model is that it accurately maps onto a matrix. The abstractions increase as elements get more complex. This mirrors our communication in an IoT setting, when we discuss multiple machines, competing networks, industrial noise, connectivity and uptime . To the customer, all of this stuff is not particularly relevant (and wasteful of their time). Yet, in building a system to fit their needs we must attend to each layer.
References:
Wikipedia – OSI Model https://en.wikipedia.org/wiki/OSI_model
OSI Model – Caroline https://medium.com/@gwenilorac/understanding-the-iso-osi-model-a-blueprint-for-seamless-communication-5a9f615fc907
Coursera – OSI model – coursera.org/articles/osi-model
