Designing a Workflow Specification

Technology standards are deeply engrained in numerical and scientific representations. Most standards are developed and ratified by standards development organizations (SDOs). They are perceived as "industry recognized" descriptions about how a certain element interfaces and responds to recognized external technical parameters.

Well-known SMPTE industry standards such as timecode (ST 12M) and the Serial Digital Interface (ST 259 and ST 292) are fundamental to the operations of both devices and systems. Standards documents enable manufacturers to interface and meet interoperability requirements when exchanging signals or elements between other systems, devices or circuits.


However, when the specifications for a "workflow" are developed, the descriptions take on a completely different set of textual and conceptual meaning. In a workflow specification, the requirements become much more user-specific. They often address a much broader set of parameters, issues and in turn, system requirements. Workflow specifications can be used in developing a Request for Proposal (RFP), but they can also be used to help the organization understand (and adhere to) certain operational and functional capabilities.

In recent times, we've seen workflow specifications become both descriptive components for solution provider as well as binding contractual expectations for those systems provided by a vendor or integrator.

Workflow specifications have grown beyond generalizations to become the structure of the critical elements used to define performance, configuration and overall functionality of a complete system. Thus a workflow specification needs to include the technical, software and hardware components of many subsystems such as the editing platforms, storage, asset management, ingest, transmission and archive.

A typical broadcast environment depicting components, which would be described in an overall workflow specification design. Credit: “Moving Media Storage Technologies,” courtesy of Focal Press
Workflow specifications usually address file-based workflows and systems. The technical elements can include items such as the number and types of ingest or playout codecs, the "native" formats, and the number of clients attached to the system.

The specification further embodies the number of concurrent sessions; attached clients (including whether or not they are Fibre Channel or GigE and at what data rates); the number of licensed devices and how they are enabled (i.e., Web-based thin clients or dedicated plug-ins to thick clients); plus a host of other possible combinations.

When designing a workflow spec the question becomes, "How much is required to establish a suitable set of workflow requirements?"

The answers can be quite deep, often requiring the expertise of those familiar with a multitude of different operational models and vendor solutions. To help the reader understand both the importance and the necessity for prescribing the parameters and expectations necessary to properly implement an end-to-end workflow, we'll look at some of the higher profile parameters of a workflow specification.


To start, provide what most define as an "Executive Summary." State the obvious. For example, spell out that the user needs to implement an "enterprise media asset management, software-based solution that covers the elements of media ingest, production and distribution; feeds; desktop preparation; editorial as craft editing; asset management; play to air (cable, satellite); and file-based distribution to third parties including VoD."

This sets the tone for the remainder of the requirements. It establishes the target needs and it clearly covers those modules or components the system must be capable of addressing.

The specifications will be used to identify those "functional-use cases" that the MAM, storage system or platform must be capable of achieving. The requirements to be documented in the specification must derive—from the workflow which is to be enabled—a description of both the need for the particular workflow as well as supporting perceptions or suggestions, which will be cast to form the system and in turn be approved by the respective role players.

These fundamental key elements are crucial to setting the tone for all the follow-on techno-babble that will form the detailed performance expectations of the system.

The descriptions can get complicated. They will require the user to clearly set the depth and dimensions of the workflows, which must be satisfied by the core system, its storage elements, and any peripheral components (such as archive, editing workstations, transmission servers).

Workflow specifications need to outline any current equipment used by the facility or organization. Include elements such as field cameras (and codecs); routers; platforms (Mac or PC); software for editorial (Final Cut Pro, Media Composer); peripheral elements such as Adobe Bridge, AfterEffects and Photoshop/CS-x; and other physical devices such as videotape transports (with data rates and formats) as well as any existing third-party platforms (EditShare, CAT-DV, etc.). These items are extremely important to identify, especially as legacy elements or formats are married into the new "workflows."

Sometimes it is important to document the facility's current workflows as well as the "desired" workflows. Be sure to include all the components, any third-party interfaces, and have them substantiated by a guarantee that the integrated components will meet the overall requirements as identified in the workflow specifications document.

These guidelines comprise the foundation of a root specification. Needless to say, the "workflow specification" is becoming the most significant component in developing the operational requirements of a file-based environment. Systems should remain fluid and loosely coupled to allow flexibility as the operation evolves. Remember, the more detailed the requirements, the more understandable the workflow specification becomes.

Finally, be certain all the components, as well as your expectations, are clearly defined upfront and prior to signing a contract with a solution provider.

Karl Paulsen, CPBE, is a SMPTE Fellow and senior technologist with Diversified Systems. Read more about this and other storage topics in his latest book "Moving Media Storage Technologies". You can contact Karl at

Karl Paulsen is the CTO for Diversified, the global leader in media-related technologies, innovations and systems integration. Karl provides subject matter expertise and innovative visionary futures related to advanced networking and IP-technologies, workflow design and assessment, media asset management, and storage technologies. Karl is a SMPTE Life Fellow, a SBE Life Member & Certified Professional Broadcast Engineer, and the author of hundreds of articles focused on industry advances in cloud, storage, workflow, and media technologies. For over 25-years he has continually featured topics in TV Tech magazine—penning the magazine’s Storage and Media Technologies and its Cloudspotter’s Journal columns.