You are here: Home Page » Newsrooms » Software design

Software design

Jul 1, 2008 12:00 PM, By Brad Gilmer

Services offer improved designs for broadcast facilities.

The area of software design is a shifting landscape, and smart computer people are always coming up with better ways to do things. A significant shift in software design is making its way into broadcast facilities. At the core of this shift is the concept of a service. A service is a function offered on a network by a host to clients. The shift is not so much a technical change, although there are new technologies at work, but more a philosophical change.

Changing the design

In the past, functions were tightly integrated into a software package. If you purchased an automation system or a traffic system, the software was designed with various modules communicating directly with each other at a low level. This code was efficient, and for a programmer who was familiar with the system, this design made it easy to gain access to information.

But tightly coupled systems have problems. As these systems become larger, they grow in complexity. It becomes more difficult for a person to know about everything going on. Interactions between different parts of the software become complex, and changes in one area produce unexpected results elsewhere. In short, the complexity of the system grows until it becomes unmaintainable. Also, these systems embody a workflow that was happening in an organization at the point when the system was designed. Changing these systems later — when the workflow changes — is difficult, if not impossible.

Software engineers have been looking for a way to loosen the coupling of systems so that they can more readily adapt to changes in workflow. This is because many industries, including our own, have experienced rapid change. Understanding workflow is a key factor in the success of service-oriented systems.

Analyzing workflow

Workflow has been a topic of intense interest in the broadcast industry, and many of us have experienced workflow analysis firsthand. During analysis, business experts look at the entire broadcast operation, identifying areas of inefficiency and duplicated effort. Many engineers view these analyses as a waste of time. However, a focus on workflow has led to the identification of common functional elements within the broadcast facility, which in turn has allowed the development of software services that perform common functions.

Figure 1
Click to enlarge

For example, analyses have identified that the ingest function — the process of bringing video and audio into a system and making it available to clients — is commonly found in news, automation and post-production systems. Furthermore, as Figure 1 shows, ingest can be broken down into common workflow steps that differ little from one application to another. (Note that Figure 1 is greatly simplified.) Rather than design an ingest client into an application, programmers can create an ingest service performed by a host accessible on the network. Ingest jobs can be sent to the host, the host manually or automatically performs the ingest, and the client is then notified when the ingest job is complete.

Overall workflow

The next leap in software design comes from thinking about overall workflows and not just the functions that an individual application performs. When designing an ingest service that will live on a network, plan to make this service available not only to your own application, but to everyone on the network who needs it. Develop open, accessible interfaces to the service and publish the fact that the service exists. Overall design philosophy needs to change from building customized, specialized, highly interconnected software modules to building services that support several applications. Once you have adopted this way of thinking, it is easy to see the benefits:

Adding capacity is easy. If more ingest hosts are needed, simply add more on the network. If an ingest host is busy, the client looks for another one.
Upgrading is easier. When features are added to an ingest host, put a host with the new capabilities online alongside the old one. Clients that know about the new features are free to call on them.
Unanticipated interactions are reduced. Because the ingest host is rigidly defined by the service it provides, software programmers are not as tempted to develop shortcuts around interface points to get the information they need. Interfaces remain clean and clearly defined.
An automatic fail-over capability provides protection, so that when one service goes offline, the slack is taken up by other systems offering the same service.
Changing the overall functionality of a program in response to workflow changes is easier because the application is not tightly coupled.

Imagine how the configuration of a system built on services would work. A new video server is brought online, pointed to a device on the network that provides the ingest service, and the server is then ready to be loaded with material. But what if the video server could discover the ingest service itself?