What has business process management got to do with broadcasting? Surely, it is more relevant to a manufacturing operation; broadcasting is a creative business, isn’t it? Sure, production is creative, but to an outsider, broadcasting operations are much like manufacturing. Raw materials — the program tape or file — arrive from the production company, and at the other end, the broadcaster delivers programs to the viewer.
Through all the many processes, the program has been formatted for the viewer’s television, tablet or smartphone, and any necessary subtitles, captions or dubbed audio have been added to the program. The channel schedule has been delivered to the third-party listings guides with information about each program, and the promotions department may also have created trailers for the program.
Is this not a manufacturing operation, a media factory?
Over the last decade, many verticals outside the media-and-entertainment sector have moved to a software architecture where the processes are managed as a whole, rather than using islands of software to process the product. This holistic management of business processes potentially offers a more efficient way to command, control and optimize media operations.
Business process management (BPM) is a formalized method to manage the activities of the business. Through process management, company executives can view and monitor the running of the business, and make informed decisions about developing and optimizing the business.
BPM allows business processes and goals to be abstracted from the underlying technical platforms. At the business level, a broadcaster may want to add social media interactivity. At the technical level, this could involve synchronizing playout automation with social media platforms though a Web-services interface. The business decision maker should not be concerned with the technical minutiae.
Often linked to BPM is service-oriented architecture (SOA), which is a configuration of the systems that implement the processes of the business. We use SOAs all the time when interacting with e-commerce services. As an example, when a user books a vacation, a travel website calls up hotels and airlines via the Web services. From these loosely coupled services, a federated view is presented to the user of a combined flight/hotel/rental car deal from 10 or so airlines and hundreds of hotels.
It is key to note here that each airline may have its own booking system, but presenting the flight schedules and availability as a Web service abstracts the travel Web site from the airline’s software. This removes the need to intimately link the booking systems with inflexible APIs that are costly to maintain as software is updated or changed.
The business capabilities of each party are presented as re-useable services. In implementing an SOA, services are wrapped via adaptors that hide the complexity and present only the data necessary to make the business transaction.
BPM is a software layer above the workflow orchestration within the SOA. It will provide a toolset to simulate and model business processes. Workflows can be designed, and business rules applied to processes. The workflow orchestration engine calls on services as appropriate using the information from the business model. It also reports feeds to the “dashboard” with data appropriate to the role of the user.
The orchestration engine and the services that implement the business processes are linked with an enterprise service bus (ESB) that carries the control messages.
Although DPs or editors may view their part of content production as creative, in reality the distribution and delivery of television programming can be viewed as a content factory.
The business processes in the factory include sales, acquisition and channel management. The staff running these processes are not concerned with which make and model of transcoder is used or how the media storage is designed. Their focus is on revenues, margins and costs.
Running a broadcast operation requires the management of content — both programs and commercials — through many processes before the final transmission. A typical business process could be “prepare this movie for air, and transmit at 9 p.m. on Friday.” To implement this process, the broadcaster will have designed a workflow that orchestrates many tasks and activities.
However, monitoring the processes, following content as it moves from one operator to another, and from one department to another, is difficult. An executive may rely on monthly reports from supervisors. These do not give a detailed view of how the business is running, how efficient it is or how efficiently resources are deployed.
The old way, moving tapes from one department to another, could be managed, but it was difficult to get an overall view of the efficiency of operations. Department heads provided a filtered view of operations under their command. Staff could confuse the status of jobs.
The linear nature of tape operations led to a rigid style of operation, with tapes passed like a baton in a relay from one operation to the next. Even with the move to file-based operations, much of the workflow orchestration was by files being saved in watch-folders or e-mail notifications to the next operator down the line.
It is difficult to analyze or audit such operations. There may be logs stored by individual workstations or software applications, but there is no federated view. BPM changes this by two means (shown in Figure 1):
Services could be called from a Web interface, much like the travel booking example. But the real strength of the SOA is when the workflow is orchestrated by a middle layer of software. This middleware carries out the business requests from the BPM and calls on the services to implement those business operations. Flowing the other way is reporting on the services, which allows the BPM to view the operations and to optimize them if required.
File-based operations remove many of the constraints on operations, allowing processes to be orchestrated in a way that serves the needs of the business, rather than as dictated by the limitations of the medium that carries the content (videotape).
Services can be provided within the facility, or they could be outsourced or even cloud-based. Through abstraction of the service adaptor, the workflow orchestration engine calls a service, whether it’s in the same room or on the other side of the world.
The Advanced Media Workflow Association (AMWA) and European Broadcasting Union (EBU) have been working jointly to develop a Framework for Interoperable Media Services (FIMS), as well as specifications for service adaptors, including transfer, transform and capture. The Transfer service copies or moves files and is typically used to deliver files, to archive them or to move them through a hierarchical storage system. The Transform service encompasses trancoding, transrating, rewrapping and change of resolution. The Capture service is the ingest of real-time video and audio streams, typically from HD-SDI.
These services lie at the heart of multiformat delivery. It is envisioned that further services will be added to the project over time.
An SOA is technology-agnostic, and the middleware can be obtained from any number of software vendors. The FIMS framework constrains the requirement for the middleware, and some vendors are already offering systems that comply with the framework and the service adaptors.
Part of the aims of FIMS is to move away from proprietary adaptors to reusable adaptors. This will save cost to the broadcaster, and save manufacturers the need for what is often unprofitable custom development.
There may have been no incentive for broadcasters to change processes and operations, to ignore what other vertical sectors were doing. But the intensified global competition in the media marketplace, and the demands of multi-platform delivery, have focused the need to improve efficiency. Broadcasters must be more agile. If a new consumer device comes along, with a new way to view content, then the broadcaster should be in a position to capitalize on the opportunity, and at an optimum cost.
Conventional IT architectures do not serve well the needs of the media business. For example, some services, like editing and grading, are human processes. The editor takes the source files, and days or weeks later, delivers the final cut. Even transcoding a file can be a lengthy process. Media files are large by IT standards, up to terabytes.
This requires a separate media service bus in parallel with ESB with the bandwidth to carry media files as they move between services. Any file-based facility probably already has a media network that can be adapted to this task.
To some, such a radical change may imply risk: Will the broadcast operations stop if the SOA middleware or the BPM crash? Do they become single points of failure?
There is risk in any business system, but the risk is mitigated by careful design. There is a wealth of knowledge from other vertical sectors in the application of SOA and BPM; they have been doing it for years. A feature of the SOA is that services are loosely coupled. The playout automation exchanges schedules and logs with the middleware, but if the middleware is down for some reason, playout continues. The automation and master control operator continue as normal until the middleware restores service messaging.
BPM and SOA present a good way to build an agile business that can quickly adapt to the changing media landscape. They can aid the executive to optimize use of capital equipment and staff resources. Through agility and efficiency, the business can better compete and succeed in a world of TV everywhere.
—David Austerberry, editor