Television news is, for a number of reasons, the most critical part of most broadcasters' operations. The way a broadcaster handles news is the clearest indication of its character, and the best way to create and manage a brand identity. Because of its very nature, it is a broadcaster's most complex operation, and working under intense pressure is an everyday norm.
There is a long history of technology solutions to ease the production of television news — dating back 30 years to first-generation newsroom computer systems such as Basys and Newstar. Newsroom computer systems have dealt traditionally with words: wire services, scripts, running orders and research archives.
More recently, a parallel stream of technology developed that handled the media assets: video clips, voice-overs and so on. The two computer networks are commonly linked, usually via a standard interface, which now is almost exclusively the Media Object Server (MOS) protocol. This production system manages ingest and live recording, moves content to editors and graphics workshops, compiles and delivers playlists, and hands completed content over to the archive.
These two systems are both mission-critical for the news broadcast. Both are complex and both have heavy demands on processing and network traffic. But, operating them as two independent, albeit linked, systems seems wrong. Instead, the ideal solution must be to have one computer network that handles all the elements of news production.
Some vendors are now suggesting this. Their approach is problematic, though, in that their solution is to bundle all the likely tools into one all-purpose workstation. This leads to an extremely bloated application — one likely to be a big drain on resources. At the most basic level, combining the newsroom computer with the news production system doubles the risk.
It also implies a complex, point-to-point architecture. If each workstation has to talk to each device, it results in a large number of interface points. Changes to any element of the software may mean changes to these interface points, which may in turn cause another part of the functionality to become unstable.
Also, changes may be outside the control of the newsroom computer vendor. If a broadcaster decides to upgrade its router, or if the server supplier makes a change to its communications protocol, it can easily cause a comprehensive system to fail. If the whole of the news production operation depends upon this network, and it stops working, it becomes a major problem.
Put bluntly, such an architecture can be a nightmare to manage and maintain, and definitely not the path that should be taken in 2011. That said, let's look at a system that could very well be the answer broadcasters need.
Service-oriented architecture
While service-oriented architecture (SOA) has been a common structural approach in the computer industry for quite a while, it has only recently entered the broadcast conversation — so recently that there is still a lack of clarity, exactly, as to what an SOA is.
An SOA has three distinct characteristics. First, it is organized around outcomes instead of technology. The tools are defined by tasks, not the other way around. Second, it bridges a number of systems, bringing functionality to the user as required. Third, it is based on the concept of “services” that can be delivered by small packages of dedicated code, connecting and communicating through simple, open interfaces.
If we accept this definition, then one would further suggest the television newsroom is an obvious setting for the application of SOA-principled technology. There are a large number of tasks — ingest, metadata creation and management, editing, archiving, and graphics — that are required to be performed by different people at different times and in different locations. Virtually all of those tasks are critical.
The tasks involve working with different devices: routers, servers, decoders, character generators and more. Those remote devices will be supplied by a number of vendors, all of whom will each be engaged in continuous improvement of their own products but not consult each other about consistency testing or upgrade cycles.
Using an SOA means that the functionality is provided where you need it, when you need it, with lightweight software services. There is no workstation bloat. In television news, where the core of the infrastructure already exists — the newsroom computer — it makes logical sense to add functionality to it through an SOA.
All the common newsroom computer systems support MOS as an open architecture. That means that the choice of software platform remains with the news director choosing for operational, not technical reasons.
What the SOA level should do is load services into a newsroom computer plug-in when you need them and put them away when you do not. Each user builds a workstation with the tools needed at that moment. That will keep the software load on the individual computer light, agile and, most important, stable.
News presenters will use their terminals for scripting, and probably for access to the browse server to look at story packages as they are completed, to get the right in and out cues. Most of the time, that is all the functionality they require.
But occasionally they may go out of the studio to shoot a special report, in which case they might need editing facilities for rough cutting. At that point, the desktop editing service is loaded. The story is cut, the EDL is exported, and the editing service goes away again. There is no onscreen clutter and no potential for software conflicts.
The EDL can then be compiled on-the-fly on the server, or it can be handed to craft editors, because they too can sit as part of the service oriented architecture, swapping the data they need.
Journalists might need the desktop editor more often. Having the editor appear alongside the script means journalists can develop the way they tell their story as one single process, evaluating and cutting the pictures and sound while developing the script simultaneously. When the story is cut, a service can pop up that allows them to populate graphics templates.
Planners will need to set up satellite or line recordings; news directors definitely want to review content. You get the idea: All the people in the newsroom get functionality when they need it, but do not need to clutter up their computers with unwanted tools.
In a well-crafted SOA, these tools will be called up by lightweight pieces of XML code over MOS — two well-known and open standards. As well as making the system agile and stable, this means that any competent third party can create their own functional tools using the same simple Web services-based interface.
Adaptors
Most of us use laptop computers, and many of us travel. Supplied with the laptop, the power supply provides an essential service (charging the battery) when needed. We do not need to know what happens at the far end of the cord, whether it is 100V to 240V, 50Hz or 60Hz. We do not care; the power supply sorts all that out. All we need is the interface to make the plug fit in the wall receptacle, which is why we do not get on a plane without a bag of power adaptors.
That is directly analogous to the way an SOA is constructed. The service sits on our computer, and we deal with the part of the information we care about in that particular task, which might be amending an EDL or updating archive metadata. That information needs to be stored in the right part of data architecture, but we do not want to worry about that. We just need to get the job done.
So the other essential part of the SOA is a bag full of adaptors, which provide the interface to third-party devices, ensuring the data and content is in the right format for the transfer to be successful. And, like the service connections themselves, interfacing adaptors are simple pieces of XML code: simple to write, simple to maintain, and undemanding of processing power or bandwidth.
Here's the bottom line: The next generation of newsrooms will use software services as plug-ins to the newsroom computer installation, with simple adaptors for interfacing, and a service-oriented software platform to provide the connectivity. Using the existing newsroom computer platform preserves the broadcaster's investment, another significant consideration.
As a solution, it is infinitely flexible. New services can be added by anyone with an understanding of XML. Elements of the third-party hardware and software infrastructure can be replaced when necessary because it is only the adaptor that needs rewriting, and maybe not even that.
Users can connect into the full range of functionality wherever they are, on whatever device they choose, because tools are not hardware-bound or pre-installed. If a journalist wants to update a story with a revised edit on an iPad in a Starbucks, that is fine.
Most important, it means that users can create a rich, individualized work experience. If they are hot desking, their individualized experience follows them wherever they go. The solution enormously expands users' capabilities while simplifying the technology and increasing its reliability. It is the only sensible way to implement the flexible television newsroom.
Ed Casaccia is the senior director, product marketing for Grass Valley.
