There’s no room for uncertainty in the software that responds to a machine’s “Emergency Stop” button. At first sight, software inspired by nature (biomimetic software) delivers more uncertainty than answers. But maybe that’s an illusion.
Software development is full of new, reinvented and changing concepts, items and structures. One concept that has always captured the imagination is to mimic nature, inspiring advances from neural networks and genetic algorithms, to walking and running robots.
I’d like to focus on the humble message, its role in software, and what nature can offer as pointers to new ways that messaging systems can work. I need to use a rather general and broad definition of “message”: It’s a way of moving information.
(Related: IoT is a good place to be developing in right now)
In nature, it is usually a chemical pathway that conveys a message. Yes there are other mechanisms, from electrical signals in nerves to bees that dance. But at the fundamental level of cell operations, it is sequences of chemical reactions that run the show.
And here, I think, is the interesting type of biological message: The message is not directed to a particular recipient. It is just launched into the environment.
Remember SOA? Service-oriented architecture was and is a way of organizing component-based and distributed systems, in which each system interacts by providing and/or consuming services. The communication between providers and consumers may be by message (asynchronous) or by API (synchronous), and there may be a broker that mediates the connection. But the result is that every sender addresses the message to an identified recipient.
Compared to biological systems, this makes software (a) more predictable and (b) more constrained.
In the Internet of Things, many “things” generate messages in a semi-biological way—the once-a-minute temperature message, for example. (Note to software writers: Reporting changes can also be quite successful—for example, frogs eyes, where certain detector cells fire in response to a change, with no response to a steady state. This helps frogs see their food moving against a static background.)
Whether it’s a regular report or triggered by a change, the point is that the software to generate the message can be written without knowledge of how or when any external system is going to process the message: immediately, tomorrow, or not at all. Naturally, the system doesn’t work until the void contains software receivers to handle the messages.
So as a software designer, you have a choice: You can structure software to shout into the void with undirected messages, or you can require it to find and make use of the services you expect to be available.
Shout-into-the-void software just announces whatever it can, using status or status-change messages. This achieves great levels of decoupling, so it will get high scores if the review meeting likes modularity. But you’ve also got to deliver a system that works, so you will need to provide the modules that find and respond to the messages… and that word “find” will consume resources that wouldn’t be required if you had directed each message to its intended recipient.
Directed messages can be decoupled using a broker or a publish/subscribe approach. But there are cases where hard coupling is preferred; most people expect a machine’s emergency stop button to trigger an exact and predictable sequence of actions within nano- or microseconds.
Could undirected messages ever pass the emergency stop button test? Maybe. Biological systems have evolved schemes where certain reactions can be fast by avoiding central processing. For example, I flinch before thinking in response to some unexpected sounds.
But trying to solve an outlier (the emergency stop) may be the wrong task. A biomimetic message system will require genetic algorithm-like creation and testing of many feasible receivers. So one receiver will respond to the concentration of temperature change messages; another will combine unusual temperature messages with “loud” messages being issued by the microphone to diagnose a bearing failure. The characteristics of the best performer will be passed through to the next generation. Each generation of development will get closer to the goals of the system.
This is an attractive outcome, and it doesn’t have to be an automated genetic development process; you could use agile sprints to create the next generation of receivers.
A message system that guarantees message delivery appears to be an essential underlying capability, and probably is essential to building predictable subsystems. But the overall system may be too complex for predictability to be a reasonable expectation. In that case, the robustness and flexibility we will need may well have its roots in the humble undirected message.
