The role of orchestration in live video has changed considerably over the past few years. When we first started building Livelink, much of the challenge was about making IP-based contribution and distribution easier to manage. Broadcasters and service providers were moving more live workflows away from fixed infrastructure, public cloud was becoming a practical option for broadcast workloads, and protocols such as SRT and Zixi were opening up new possibilities for transporting content.
Those changes created significantly more choice, but they also meant more things to configure, connect and manage. Orchestration provided a way of bringing those elements together and giving operators a more consistent way to build and control a workflow.
Today, the technology landscape has moved on again. Cloud and IP are established parts of many broadcast operations, often working alongside existing infrastructure and a growing range of specialist services. As those workflows have become more capable, we think the role of orchestration needs to evolve with them.
From managing technology to operating workflows
Providing a common interface through which an operator can configure different underlying technologies remains important, but it only solves part of the problem. If every user still needs to understand every component and make the same series of technical decisions each time they interact with a workflow, much of the complexity is simply being presented through a different interface.
There is an important distinction between designing a workflow and operating one. An engineer designing a service may need detailed control over infrastructure, transport, processing, security, monitoring and resilience. Once those decisions have been made, however, the person running that service does not necessarily need to revisit them every time. Their job may simply be to select the appropriate sources and destinations, start an event, check that everything is healthy and respond if something requires attention.
Livelink has always been designed to give customers direct control over their live workflows, whether through its user interface or API. As we’ve developed the platform, the question has increasingly become how that control can be presented in a way that better reflects what an individual user is actually there to do.
The right level of control for the job
The same platform can be used by people with very different responsibilities. An engineer designing or troubleshooting a live service needs granular information and the ability to get into the detail, while someone responsible for the day-to-day operation of an established workflow may interact with it quite differently. Providing control therefore isn’t simply about exposing every available option to every user; it is also about making sure the platform reflects the way different workflows are actually managed.
The existing approach to control within Livelink already reflects this to an extent. Livelink has always allowed organisations to separate workflows, users and resources according to their own operational requirements. As the platform develops, we are building further on that principle, looking at how information is presented, how established workflows are operated and how much interaction is genuinely required to carry out common operational tasks.
The underlying technical decisions remain available when they are needed. What we want to reduce is the need to revisit them unnecessarily. If a workflow has already been designed around a particular transport method, resilience model, processing requirement or set of destinations, operating that workflow shouldn’t require those decisions to be made again simply because the service is being used for another event.
Simplifying the experience, not the workflow
This is one of the areas influencing the next stage of Livelink’s development. We are looking across the operational experience and asking where information can be made clearer, where unnecessary interactions can be removed and where established technical decisions can remain in the background until somebody actually needs to change them.
Broadcast workflows themselves are unlikely to become technically simpler. If anything, the range of infrastructure, protocols, processing technologies and destinations involved will continue to grow. The answer therefore cannot be to pretend that complexity has gone away.
A better objective is to decide where that complexity needs to live and who genuinely needs to interact with it. For Livelink, that means continuing to give engineers the control they need while making it considerably easier for other users to operate the workflows those engineers have created.
If you’re ready to take the next step and find out more about Livelink, get in touch with the team, or book a demo at a time most convenient to you here.
