“Make everything as simple as possible, but not simpler.” -- Albert Einstein.
There is a recurring tendency to simplify complex systems in ways that will add complexity. Over the course of an evening with systems engineers, I have heard “Which one control protocol will we use? Will it be able to go all the way to the enterprise? When will all systems in a building be integrated into one system? How long before every sensor has an IP address?”
Metcalf’s law is misunderstood.“The value of a network goes up as the square of its nodes.” That is true for social networks. It is true for systems. It isn’t necessarily true for points. Too many points can actually reduce the value of a network.
On un-switched Ethernet networks, we used to manage what I called the cocktail party syndrome. Response would be nearly linear as you added nodes until the network reached a tipping point when response collapsed entirely. Packet collisions would increase. Re-transmittals would begin bouncing off re-transmittals. Like adding one more couple and one more bottle to a cocktail party, and suddenly you can hear the party from six blocks away—and effective communication is over for the evening.
Take that same network and split it in two, and communication throughput soars. Let half the party gather in the kitchen, and half in the living room, and the quality of conversation improves—Unless you divide the crowd wrong, and most conversation is between rooms. In that case, you made the problem worse.
The composition of partiers in each room of this cocktail party seem to break down on pretty traditional lines. There are exceptions, but they tend to prove the rule. In the same way, the traditional building system functions belong in different rooms. We need open communication between the rooms – but the intimacy of those communications should be socially defined and limited, both at the party and in building systems. These social constraints are the system interface.
Behind each interface, there should be one protocol. Inside that room, a domain expert should define the system, and make it performant. Even if the system in the other room happens to speak the same language, it should still be installed according the constraints of its own domain, and by its own domain expert. This simplifies the job, and the performance, and the warrantability of each building system.
The interface enforces the social rules. Some points may need to be protected. Some points may need to be interpreted, or combined, to be useful outside their domain. Those constraints make the society better…
And as most folks discover some time at their second college mixer, when some insist on violating that interface contract, and insisting on inappropriately intimate contact between the rooms….eeeeewwwww