The COTS transition: What does hardware-software decoupling offer?
Inavate’s Tim Kridel explores the move of software to COTS IT gear, as well as the challenges and considerations for hardware-software decoupling in the AV industry with Vanti software developer, Ben Jacobs.
Back in January 2020, Inavate explored why AV vendors are drawn to off-the-shelf hardware. Tim Kridel sits down with Ben Jacobs, software developer, Vanti, to learn more about the transition to COTS IT gear and how the trend of 'everything as a service' could present exciting opportunities for the AV industry.
TK: QSC’s running of Q-SYS software on standard Dell hardware is an example of how some AV vendors are moving their software off of purpose-built hardware and onto COTS IT gear. What kinds of IT certifications and skills (e.g., coding) will AV integrators and consultants need to have in order to accommodate this latest trend? For example, will they need to know C#, HTML, JS and Python?
BJ: The move to non-proprietary software languages will have huge benefits in my view. In fact, this trend is not just related to COTS, for example Crestron now allows you to run C# code on their custom hardware. This opens up new possibilities and allows those with software experience to create richer experiences and more easily follow programming industry standards.
For example, Crestron have already been demoing HTML5 for use with their systems. Similarly C# and Java can already be used with Crestron and AMX, and I expect others to follow with existing industry standard programming languages. In terms of hardware, more IT-focused skills will be needed to support the hardware and associated systems.
TK: What considerations and challenges does this hardware-software decoupling trend create for AV vendors and AV integrators? For example, when a vendor no longer controls the hardware, what additional steps does it have to take to ensure that there aren’t bugs and other problems when launching a new software product, or issuing a major update to an existing one? Do integrators have to do their own testing to catch bugs that the vendor might have missed, or that the vendor couldn’t have anticipated?
BJ: Interesting question, and I certainly think you raise a valid point. Where before firmware and the associated software is written for (and tested on) specific hardware by the vendor, when these are decoupled more testing is certainly required.
I imagine to alleviate this to some extend there will be suggested or supported hardware always available from the vendors. This may require more collaboration between the vendors and the integrators, perhaps vendors could give opportunities to test beta software and help reduce bugs in the final version. There needs to be open channels with the vendors for them to take feedback and bug reports.
TK: With device as a service options in the IT world, I wonder if an AV integrator could do the same thing for AV software and/or COTS IT gear that a vendor has stopped supporting. Or maybe you have some additional insights into how AV integrators could do what IT firms such as CDW do to help customers as products reach end of life.
BJ: This is a trend seen across many industries: Everything as a service! This is a huge potential for integrators, who could indeed offer services which includes the hardware and upgrades when required.
This is one area where decoupling hardware and software needs care: integrators need to not just pick the cheapest hardware available, but something which has been well tested. I think refresh cycles come into play here too: often if hardware is end of life, or not supported, it may be time for an upgrade anyway to take advantage of new features.