Closed vs Open Systems by Dave Weatherhead

This took me back to a presentation I gave to the ITEAC conference in London in 2018.  This was on this exact subject of open vs closed architectures and, given the audience and the conference stature, I had tried to make it as even handed and fair as possible.  I went back through that presentation and the arguments it put forward; they were necessarily brief given the time to present but I still think they stand up today as the key issues to consider. 

I have summarised those below:

Pros	Example
Allows most things to work with most other things	Means a supplier can build a part of a system confident it can work with other parts without having to test with every conceivable combination
Specialisation is possible, suppliers can focus on making just one thing	In lighting a company can specialise on building the best lights without also having to develop consoles to control them
Customers can pick and choose what’s best for them	If you like one automation console but someone else’s drive systems and machines you can pick and choose
Cons
Can limit choice to those suppliers who do not use proprietary protocols or features	Dependant on the discipline a significant percentage of suppliers will have features in their systems which rely on them providing all aspects of the system. Apple is the classic example of this
Increased testing requirements, you must check any change works with everyone	Suppliers must implement every aspect of an open protocol, even if they don’t intend to use all of it. If a protocol is revised by an external body all suppliers need to spend time and money to upgrade all their equipment
Who do you call if things aren’t working	If a winch moves to a different position to that you expected, do you call the console supplier or the drive supplier? Either could be at fault, how do you know which?

Open Architectures

Closed Architectures

Given all those considerations I boiled it down to what I felt were the three biggest questions from a customer’s perspective.

• Does an open architecture limit rapid innovation in the short lead-time world that entertainment inhabits?
• How important is a la carte to you? If an open architecture is the common denominator what sacrifices might that involve?
• What is your comfort level for co-ordinating support?

At this point I should confess something of a bias.  As co-founder of Kinesys I helped build a company that chose to provide an end-to-end automation solution to customers.  This was in part from necessity but more honestly was from a place of ensuring the best experience, service, and support for customers.  By having control of all aspects of the systems, we were able to adapt quickly to customer requests for features, address any bugs quickly and most importantly be able to ‘own’ any issues when they occurred, because they always occur.  There was no danger of confusion as to whose issue it might be, who should diagnose or fix it.  It was our gear top to bottom so our problem to own and fix.  It also meant we could certify the safety of our systems in a way that has become increasingly important over the last 20+ years of Kinesys.  Systems made from a combination of different suppliers’ equipment need an overall person/entity to take responsibility for the safety and compliance of the entire system, whether they supplied all the component parts or not.

The technical entertainment industry has been a digital industry for a long time now, with the exception of some aspects of audio, almost every signal and piece of data is digital, binary ones and zeros.  The glue that sticks it all together are protocols.  An agreed format of data that is shared between devices.  Some of these are open, published to the world and available for anyone to use to allow for maximum inter-operability.  Others are closed, proprietary, created by companies to meet a specific need and/or deliver a certain function or service.  These are the property of the companies that create them, they choose not to share them with the world for a number of reasons.

If you choose to try and implement a closed protocol without the permission and support of the original developers, who is going to provide the timely support you need and in the worst case accept the liability if a system fails to perform as required?

At Kinesys we have used, and continue to use, open and closed protocols.  We see the benefits of both.  When we do create and use a proprietary protocol however, we do so for a reason, the very same reasons that I articulated earlier.  We believe it ensures the best outcome for our customers which means the safest and the most supported experience for them.  That is our choice, and our customers decide if they agree. It is also a closed protocol; it isn’t made public for a reason.