The fact that broadcasting is transitioning at breath taking speed is a statement of the blindingly obvious. It’s difficult to keep up with the pace of change whether it’s IP, COTs, cloud, HDR, or metadata. But what’s not so obvious is some of the interesting challenges we have around supply chains, even for software.
Hardware has stood the test of time, we can touch it, feel it, and even smell it, especially if the power supply’s C1 goes short. However, development cycles can be many months or even years, and the pace of change is relatively slow. Although we now laud the arrival of the rapid change of software and all the advantages this provides in keeping up with the viewers demands, one massive advantage of hardware is that it has provided a longevity of business and established supply chains.
Many businesses that were established pre-IP were born out of a passion for hardware. There are numerous stories of innovators burning the midnight oil developing their products in their back rooms or garage. This led to an emotional attachment to the business that guaranteed its existence for at least one generation, and sometimes even more. It’s psychologically difficult to throw away your first design with all the wired modifications, track cuts and spuriously mounted components. As the pace of change was slow, spares could be procured thus futureproofing the broadcast facility.
Agile has taught us to only develop what is needed and release new features every sprint, and in most cases, this is often every two weeks. Code is being developed so fast that we’re being encouraged to use SaaS so that vendors can upgrade code directly on their servers with alarming speed, often without our knowledge.
It’s difficult to argue how hardware as we once knew it will ever make any meaningful resurgence. Even if broadcasters run their own on-prem datacenters, the core of their infrastructure will promote IP, software defined networks, and SaaS processing. Even knowing this, something that causes me sleepless nights is how do we guarantee the longevity of the software the broadcast infrastructures are adopting?
Escrow has been traditionally used to store copies of the source code to give broadcasters peace of mind, but in this fast-paced change we live in, is this a viable option? It maybe that a software repository can be held in Escrow, but this would be a bit of a logistical challenge.
One major value all designs have is through their intellectual property. Even though we can’t touch, feel, or smell software, it has an inherent value to other investors and design companies. We may take solace in knowing that should the vendor of a particular service we’re using cease to trade, there is some hope that another vendor may want to buy it.
For me, the most important aspect of any system is the data. We can always rebuild processes and redesign infrastructures, but when the data is gone, it’s gone forever. In this context, the data takes many forms. It might be infrastructure designs, API specifications, and even media assets.
It may seem unfair to single out software products in this way, and to a certain extent it is. However, software services have only highlighted a challenge that has been accelerating towards us for at least ten years. Although hardware designs may have a long shelf life, the FPGA and microcontroller code running on them has the potential to change as quickly as any SaaS solution.
Understanding our supply chains, and how we can maintain them, has always been important, it’s just that now, their potential fragility is a bit more obvious.