Broadcast vendors say resilient workflows start with fewer tools

Every tool added to a broadcast workflow brings another credential, another integration and another thing to patch. Andrew Wierzan, president of products at Pixitmedia, made that argument in the final installment of NewscastStudio's three-part Industry Insights roundtable, published November 5. Resilience, he said, starts with subtraction rather than addition.

Panelists talked through strategies for disaster recovery and keeping the business running, what cloud-based redundancy costs and how it works in practice, the dependencies that run through production workflows, and the rising difficulty of proving content is authentic.

Removing tools before adding controls

Wierzan was careful to say he isn't arguing for locking into one vendor's ecosystem. His point is narrower and more useful. Teams should question every piece of glue in the chain and ask whether something they already run can do the job. On the data side, that means checking whether the storage platform can handle a task before putting an application on top of it, because that extra layer adds cost and inefficiency and then has to be secured as well.

Bea Alonso, marketing lead at Projective, described the human side. Creative staff will work around any control that costs them time, so resilience has to run in the background, with templated workspaces and automation taking care of project structure, backup discipline and access governance.

Russell Trafford-Jones, industry engagement manager at Techex, took the same approach to events. Resilience, he said, should be designed a single time and then reused, not rebuilt manually for each new event. Templated workflows deployed again and again simplify complex operations and keep designs consistent, which he said reduces the risk of errors. In his view, production teams get resilience with no added effort when upgrades and configuration are managed centrally and systems carry on running even after losing contact with their control layer.

Jan Helgesen, head of product and solutions at Nevion, offered the most concrete set of controls. His starting point was embedding security into tools teams already use, which lines up neatly with Wierzan's subtraction argument. He framed the rest as a move from perimeter defense toward identity-based, zero-trust workflows that stay out of the crew's way:

• Granular role-based access and least-privilege permissions
• Production networks separated from corporate IT and office networks
• Automated security checks during ingest and other routine steps
• Zero-trust network access in place of traditional VPNs
• Immutable backups and air-gapped disaster recovery for critical systems

Alonso's warning gives buyers a usable test for every item on that list: a control that adds steps for the crew is a control the crew will learn to skip. One caveat applies to the whole panel. Each speaker sells into the layer they describe, so their advice is best read as a set of design principles to test against a facility's own risks, not as neutral benchmarks.

Keeping redundancy out of the operator's way

Sergio Ammirata, chief scientist at SipRadius, made the case for putting resilience in the transport architecture so operators don't have to manage it during a live show. He said RIST and similar technologies can make smart use of redundant paths and packet recovery. That includes operation in the style of SMPTE ST 2022-7, in which data has to be retransmitted only when identical packets go missing on both paths. Automated network management then adjusts buffering and routing as conditions change. The production team should see a reliable signal, and the work of keeping it reliable stays underneath.

For operators comparing transport options, Ammirata's argument suggests a question for the spec sheet: whether resilience is built into the transport itself or left as another task for operators to manage during a live production.

Two plans, and a price for standby

Wierzan's second point was about education. Disaster recovery and business continuity are separate disciplines, he said, and stretched operations leads and executives regularly treat them as one. Recovery means getting systems and content back. Continuity means the program keeps going out while that happens.

He argues each needs its own plan, owner and test, and that when departments understand risk together rather than in silos, their decisions become more proactive and more practical, because the whole team owns the consequences. That last clause matters: separate owners for recovery and continuity only work if neither can treat the other's failure as someone else's problem.

In Alonso's view, continuity begins with a precise record of where each asset sits and the ability to rebuild a complete project, rather than recovering loose files spread across locations. Consistent structure and searchable archives are, as she put it, the unglamorous foundation. Her verdict on the alternative was blunt.

Kristan Bullett, CEO of Humans Not Robots, focused on cost. Continuity has become easier to buy thanks to cloud redundancy and automated failover, he said, though not necessarily cheaper or cleaner. Each duplicate region, standby instance and failover route carries both cost and carbon, and most organizations are not measuring either one. More redundancy and more resilience, in his telling, stop looking like the same thing once someone checks what each failover path costs to run.

He says he regularly sees media companies set the size of their failover with no measurement of what it continues to cost or its carbon impact. The result, he said, is that disaster recovery quietly becomes one of the least scrutinized areas in the entire technology estate. His alternative starts with real data about what each workflow delivers, costs, consumes and depends on, instead of a blanket assumption that more redundancy is always safer.

The media and telco organizations Bullett works with are increasingly asking more than whether they can fail over. They also want to know what that architecture costs them, in cash and carbon, on every day it goes unused.

The obvious objection is that live broadcasting has little room for error, and a channel that drops off air can't get that moment back. Bullett's framing allows for this. He wants redundancy decided workload by workload and sized to actual risk, instead of applied as one policy everywhere. Under that approach, a live playout chain could still justify full geographic diversity while an archive or post-production workflow might need much less. The argument is for measuring redundancy, and measuring sometimes shows the duplicate infrastructure is worth what it costs.

Watching for drift, not just failure

Bullett's other point was about where those measurements come from. Monitoring bolted on afterward creates the tradeoff between resilience and complexity. Monitoring built from telemetry the workflows already generate does not, because crews get visibility without another dashboard to babysit or another process to follow. His lesson from working with compute-intensive broadcasters is that resilience shows up as a by-product of good measurement, not as a separate layer added on top.

The clearest illustration of why that history matters comes from outside broadcasting, so treat it as an analogy rather than a broadcast case. Daria Rieznik, a product manager for Redwood Software's RunMyJobs automation platform, describes an enterprise IT billing workflow: an export runs from an on-premises data center, an AWS Glue job transforms the data, and a SaaS billing application needs clean output by 7 a.m. to generate invoices.

Over six to 12 months of rising transaction volumes, the cloud transformation step creeps from 20 minutes to nearly an hour. The two-hour safety buffer before the deadline shrinks to 12 minutes. Nothing visibly fails along the way, and billing still finishes on schedule. But one unexpected retry would now use up the remaining margin and miss the service-level agreement.

Rieznik notes that operators in that situation compensate informally, by watching queues by hand, checking file arrivals and nudging schedules. That is exactly the kind of per-event manual effort Trafford-Jones wants designed out of broadcast operations. Drift like this only shows up in historical execution data, which is why it fits Bullett's case for measuring from telemetry that already exists.

Two of her fixes map onto the panel's arguments. A workflow padded with a fixed 30-minute delay "just in case" can switch to event-driven triggers, so the downstream job starts as soon as its input file is validated. And instead of leaving compute instances running around the clock for intermittent batch tasks, teams can spin capacity up when work arrives and shut it down afterward. That second fix is Bullett's idle-cost question applied to an ordinary IT job.

A billing run with a morning cutoff is not a live playout chain, and the stakes of a missed deadline differ. Still, ingest and playout chains also run on timing assumptions set at design time. For operators running them, the example suggests keeping run histories, not just alerts.

Proving where a frame came from

The panel's last topic moved from keeping signals up to proving they are genuine. Martin Lindsay, head of networked solutions at Sony Electronics, said broadcasters and content owners increasingly want verifiable provenance from the moment of capture through distribution. As AI-generated and manipulated media gets more convincing, organizations want trusted evidence of where content came from, instead of depending only on human review and detection tools applied in post. He named camera-based authentication, the open C2PA standard and verification at the workflow level as the main pieces.

The underlying idea is a transparent record of how content is captured, processed and shared. Lindsay said that preserving authenticity information across production workflows lets broadcasters verify the origin of content and detect unauthorized modifications, and that adopting open industry standards is essential to keep that trust information interoperable across diverse tools, platforms and distribution environments. Read alongside Wierzan's opening point, that suggests every unnecessary integration could be one more place provenance data has to survive.

Lindsay also described what he expects from vendors: building security, authenticity and resilience directly into media workflows instead of treating them as separate processes. In practice he listed securing contribution and distribution infrastructure, supporting trusted provenance from capture through delivery, and giving organizations tools to verify the integrity and authenticity of what they publish. That framing turns the panel's two halves into one design problem. The same chain that has to keep a signal on air also has to carry proof of where that signal came from.

For a newsroom buying cameras or editing systems in the next cycle, Lindsay's point suggests checking whether provenance is supported from capture through delivery, not only at capture, even if verified content isn't yet part of the daily workflow.