Broadcasters have grown accustomed to bespoke systems that are built and fine-tuned to meet their needs. SDI has given us guaranteed network speed, latency and reliability. Routing matrices empower us to connect equipment in ways manufacturers could never have dreamed of, and even the humble GPI is known for making disparate systems work harmoniously together.

Hardware control systems have standardized on a few serial and ethernet protocols, allowing systems to be connected and operate together.

No GPI's in the Cloud

Hardware integration in the Cloud is almost impossible. We have no idea where the servers reside, and even if we did they could change without notice as virtualization takes over. Exchanging video, audio and metadata between Cloud services is a challenge, and integrating workflows becomes even more difficult. There are no usable serial ports or GPI’s in the Cloud computing, whether its public or private.

We can integrate into Cloud systems but we come across two big problems; firstly, we must think like Enterprise Software developers, and secondly, we must accept broadcasting is a small fish in a very big pond, and the days when manufacturers would fall over themselves to deliver bespoke systems are gone.

Your CEO will have by now been sold all the hype about SaaS services; how perfect they are, pay-as-you-go cost models, and systems with near 100% reliability. The harsh reality is to deliver SaaS systems at the price and reliability offered something must give, and this is mainly two things; support and customization.

Web-App Skillsets

There are SaaS companies out there that will provide customization services for you, but you must think like an IT developer to truly leverage their functionality and power. The reason for this is very simple; Universities are teaching software development to students so they can get a job at the end of the course, to get the best chance of a job the student will be taught Web architecture and programming. This is where the money is, whether its online banking or retail.

SaaS services geared towards broadcasting are better than those that are generic SaaS providers. But even these have their limitations as the skillset of most of their developers will be in the web-app domain, and the ones that can get every clock cycle out of the processor to improve video and audio processing are few and far between. The probability of getting a tweak to a core part of the video or audio processing is quite remote.

Business models for SaaS systems make two important distinctions from traditional hardware manufacturers; they want one configurable version of the software, and they offer “flow diagram” support. That is, the person offering the support will follow a list of questions to try and ascertain the problem, if they can’t help you then the query is passed on further up the chain. And the further you are passed up the chain, the longer the time the service level agreement allows for the problem to be resolved. If you use Amazon Web Services as your host, you’re competing with BMW or the US Department of State. SaaS providers will support you, but it’s not going to be to a level we’ve come to expect from hardware vendors in the broadcast arena.

Code Must be Maintainable

For this reason, some SaaS providers hook up with broadcast specialists who both understand their software, can convert between IT and Broadcast speak, and save many hours of learning time for the new broadcaster.

In the past, software in broadcast systems has taken on a complexity of its own as different versions are created to meet the customized requirements of individual broadcasters. The software soon becomes a nightmare to maintain as a new function for one customer may not find its way into the code of another customer. The knock-on effect is support and software upgrades become extremely difficult and testing all the different versions for different clients becomes almost impossible.

A solution is to build one software version which is configurable for all clients, so there is only one version of code to develop, test and support. A back-end database holds configuration information tied to specific user accounts, which is modified when different options are purchased and is completely automated.

Reliability and Reduced Costs

The downside is it lacks the kind of flexibility broadcasters have come to expect from vendors over the past fifty years. New feature requests can be submitted but they are put into a queue called the “backlog” in Agile terms, and then prioritized by the Product Director (PD) and Development Manager. The PD must decide which features will be developed next, this is usually related to increasing sales and supporting key clients.

The upside is improved reliability and significantly lower costs. Automated testing can be better implemented as the different combinations of features and users is easily accessible from the database, resulting in better defined test vectors and results.

Work with the New Technology

SaaS is new to broadcasting and will help many entrepreneurs achieve remarkable success due to its low entry to market costs, feature rich functions and ease of use. But it does have its limitations and we must understand these before we sign-up to a service. The cost per month pales into insignificance compared to the number of man-hours needed to understand how a service works. Time investment of technology teams is a hidden cost, but it’s one that must be factored into a project, along with support, before a new SaaS service is subscribed too.

Broadcasters must realign their expectations when using SaaS products. They are empowering entrepreneurs and broadcasters to deliver systems with incredibly short lead times and reduced cost, but this speed and lower cost comes at a price. If broadcast engineers accept and work with this new philosophy they will achieve remarkable success throughout their career.