The Automation Paradox

The need for content distributors and broadcasters to deliver media to an ever-growing range of consumer platforms has led to an exponential rise in the number of workflow automation projects in recent years. These are focused specifically content supply chain automation strategies.

An important distinction between these and the automation projects of the previous 25-years is that a significant number of organisations are choosing to build rather than buy the capability. The accessibility of Web Service technologies is the key enabler here but designing, building, and operating a workflow orchestration platform requires significant resources. It is very easy to get started with cloud Web Services and potent results may be realised quickly but a broad analysis of the overall goals of a project should be carried out at the outset to ensure that the cost of the solution is not more than the cost of the problem.

The Evolution of Automation The meaning of the term automation' in the media and broadcast industry has evolved dramatically over the last three decades:

In the 1990s automation referred to the software systems that controlled hardware such VTRs and cassette robots in linear playout environments.

In the 2000s automation control naturally evolved to include playout servers as well as on-screen graphics and digital effects' systems. This era was one of software controlling a mixture of hardware and software-based components. There were very few in house' built systems although it was common to augment commercial off the shelf (COTS) systems to provide operator-specific capability.

The multiplatform age of the 2010s brought a more expansive set of automations, such as transcoding and packaging for OTT platforms. In this period, both the automation layer and functional layer were mostly software based.

As the 2020s gets underway automation has progressed to encompass a rapidly growing range of cloud-based media services. In a content supply chain context automation is now the orchestration of number of cloud provisioned capabilities, probably from a range of vendors, to create, format and deliver content for the multitude of consumer platforms. While the number of services to orchestrate and the operational complexity has increased, the business drivers remain largely unchanged.

To Reduce Manual Operations Operational Cost The motivation for automation was simple from the 1990s to the 2010s: computerisation of operational functions reduced costs. The return on investment was a simple calculation, the business case straightforward and, more importantly, the success of an automation project could be tangibly measured.

In the 2020s the complexity and throughput volume of our modern media content supply chains makes operating without automation extremely difficult. Accuracy, repeatability and precision are increasingly important but as difficult' translates directly to expensive' cost reduction remains the principal motivation for most.

The Intoxicating Capabilities of the Cloud This is cool The range of sophisticated media services available in the cloud' is astounding. Rather than needing to either invest in software and infrastructure or engage a specialist service-provider, media operators can now self-serve on a consumption-based cost model. The ability for operators to access broadcast quality' transcoding or AI based transcription on a pay-per-minute basis has transformed the cost of content preparation and exploded accessibility.

This is easy Building a joined up' operational workflow from a disparate set of services is also relatively straightforward due to the accessibility of cloud-based services through common Web Services interfaces that conform to RESTful architectures. Mid-level software developers can quickly build a scripts or program to control any given service from a near zero knowledge starting point. In this context, building an automation capability in the cloud for file-based media is far less technically complex than it was for apparently simpler linear operations - no vertical interval timing to worry about here.

Why don't we just An increasing number of media operators now choose to build their own orchestration / automation platforms as in house' development projects - either as ground up' developments or based on a 3rd party platform framework or middleware layer which provides pre-built capability such as metadata management.

Such projects frequently deliver viable results quite quickly and rapidly grow to encompass a larger range of operational business services. As the scope grows, the value of the platform grows, but so does the size of the development team and therefore the need for rigor in the capability. Protection of the newly developed, and now operational, platform becomes paramount, but the need to adapt the workflows it supports to meet changing business needs puts pressure on the technology teams.

We're gonna need a bigger boat Sensibly, technology managers create a DevOps' (Development Operations) capability in order to deliver functionality at speed, maintain reliability and manage business requirements. DevOps in any technology organisation is an essential function. The structure of the DevOps capability varies depending on the organisation, but a basic capability would typically include a number of software developers, software testers, business analysts as well as support and configuration heads.

The Paradox The DevOps function of highly skilled people can, and does, soon become more expensive to own and operate than a fully manual operation staffed by a, perhaps lower skilled but flexible and less expensive, hands-on team. Ironically, this is the exact opposite of the usage-based cost model which makes cloud-based services attractive and which probably motiv

LINK:	https://bluelucy.com/the-automation-paradox/...
	See more stories from bluelucy

Most recent headlines