In a recent statement the Advanced Media Workflow Association (AMWA) – perhaps best known for their work on the AAF format – and the EBU announced that they are co-publishing a Request For Technology through a joint working group called the Framework for Interoperable Media Services (FIMS) Task Force. The Task Force’s overall aim is to address interoperability issues in digital workflows and the purpose of the RFT is threefold:

• Define an overall architecture for integration of reusable components
• Validate this architecture by applying it to three services
• Develop a list of appropriate services for the entirety or part of the media industry

As background to the need for a standardised set of services the RFT raises two key sets of issues for our consideration (describing them as justifications would be too strong a phrase at this point):

• Limitations of current (or traditional) approaches – these include problems surrounding interoperability, maintenance, scalability, dynamic discovery, dependence on vendors for customisation and implementation of solutions, etc.
• Media industry characteristics – this lists issues believed to be unique to media technology such as large file sizes, highly collaborative workflows with significant “human” task elements, streaming, multiple resolutions, special time requirements, etc.

Both of these lists make familiar reading for industry professionals as being representative of issues that we have to deal with on a regular basis. The implication of the lists is that they describe the set of issues that a collection of reusable and standardised industry services can address, and this is where AMWA/EBU’s view differs from mine.

Firstly, the limitations of current approaches as expressed aren’t incorrect, but they are generic IT system complexities that are simply becoming more common in the media industry as the scope of IT-based media systems, their complexity and associated integration requirements grow. Some of these limitations need to be addressed with better implementation methodologies, and others will require a shift in thinking from vendors - to provide external interfaces that are as rich and robust as those available internally, for example. Some of the issues seem to be somewhat misplaced - for example, it is hard to see how a set of standardised media services will be able to address issues around the availability of appropriately skilled technical talent (the point on “dependence on vendors, above”).

Secondly, the media industry characteristics correctly identify key issues affecting system implementation in the media industry, but I can’t see how standardised services will solve, for example, network-related issues surrounding the transfer of large files. In fact, real world experience shows that although the management of transfer requests can be service oriented, the actual transfer of large files should be kept outside the SOA infrastructure.

Lastly, there is a more general problem with this approach. I believe that there is a risk that the Task Force will get plenty of responses, each of which being a version of the interface method that the respective vendor has or intends to implement, which is specific to the needs and world-view of their product. The Task Force will then have to face the choice of choosing to support one vendor's view of the world, or mixing definitions from several vendors that will end up as a least common denominator of functionality that ultimately no vendor will be prepared to implement.

I believe that AMWA/EBU have identified the appropriate architecture and building blocks that organisations need to adopt to simplify future media systems integrations, as shown in the figure below extracted from the RFT.

Taken from Section 10 of RFT from joint EBU-AMWA Task Force on FIMS

However, what is needed as a first step is an adoption by vendors of open IT standards and, as mentioned above, robust and rich service-oriented interfaces that are well documented, that are exposed using standard IT protocols such as SOAP or XML over HTTP, and that can be easily accessed using widely available integration tools. Attempting to get vendors to implement a rigid, standardised set of service interfaces that could remove their ability to differentiate their products by providing their own features is taking the standardisation efforts too far and risks distracting attention from the fundamental issues in my opinion. But maybe it should not be a surprise that the solution to these problems is seen by standardisation bodies as an opportunity to create a new standard. All this said, I would encourage all vendors to have a look at the RFT and think about how their interfaces would fit into the landscape described. It’s the right technical direction regardless of the success or otherwise of the standardisation process.