Media Asset Management (MAM) is a broad term that refers to many different sets of functions. The range of these functions for any specific project depends upon a number of factors; especially the scope of the project.
In a typical broadcaster environment, the scope of the project could include any or all of the following applications:
- Supporting TX functions – TX MAM
- Archive and library management – Archive MAM
- Supporting production operations – Production Asset Management (PAM)
- Supporting news operations – News MAM
- Supporting graphics operations – Graphics MAM
Each commercially available MAM system has strengths and weaknesses in one or more of these applications.
A phrase sometimes used is ‘Enterprise MAM’, whereby the system supports many of these applications across multiple types of media, including video, audio, text and still images.
In our experience, and despite vendors’ marketing statements to the contrary, there is no such thing as a truly ‘Enterprise MAM’ solution – especially one that meets all the needs of a broadcaster. This is why many broadcasters manage media assets across multiple systems
It is important to note that most broadcasters who produce their own content have specific issues to solve with MAM. These issues are different to (e.g.) newspapers and web content publishers.
However, these issues are not specific to individual companies. As Tom Wragg, former Head of Resources & Operations at BBC News & Current Affairs, once stated: “Broadcasters have always had the view that they are unique and can do it better than anyone else. Both points are WRONG”.
Broadcasters employ very similar processes. They acquire or produce content, they edit, check and enhance that content, they store and publish information about that content, and then they transmit and distribute it.
As a result, it is often extremely useful to look at what other organisations have done to tackle their MAM issues, to benefit from their experience, and learn from their mistakes.
MAM Mistakes
Mistakes in the planning and deployment of a broadcast MAM system are very common, and may be broken down into several types.
Poor specification (e.g. too prescriptive or too generic)
We have seen many cases of Broadcasters being too prescriptive within an RFP. This often leads to the rejection of all proposals as they cannot possibly meet the stated ‘must have’ requirements, leaving the customer with the only options of either changing the specification or building their own solution.
Prescriptive RFPs are often a result of over-analysis of the possible uses of a MAM system and the involvement of too large a stakeholder group.
This is a common mistake, made with the best intentions of trying to achieve widespread user buy-in, but results in either a significant delay in implementation, or dissatisfaction from many of the user groups as they feel that their ‘requirements’ have been ignored. Either way, the project is not destined for success.
We have also witnessed RFPs where the requirements are so generic that patently unsuitable solutions meet the selection criteria. Often, this is because the customer focuses on how the solution is structured rather than defining the required functionality.
Generic systems from an IT background are often strong on architecture, integration and scalability but lack broadcast-specific functionality. Adding this functionality can be very costly.
Poor business case (insufficient buy in from c-level)
It is often difficult to create a firm Return On Investment (ROI) case for a MAM implementation. Whereas a well executed MAM solution can increase operational efficiency and enable new distribution models and revenues, the precise savings, either forecast or in retrospect, are often unclear.
With competition for finances within broadcasters, MAM projects are often delayed or shelved in favour of expenditure that can be justified financially. It is therefore good practice to create a financial case, as well as defining technical and operational advantages.
In order to create a financial justification, a good metric is to measure the average number of person hours that are required to prepare a fixed duration of content (e.g. 1 hour) for transmission and online distribution.
This needs to look at all processes that could potentially be impacted by the implementation of a MAM system, including acquisitions/commissioning, marketing, viewing by the acquisitions/commissioning teams, viewing by legal and editorial compliance, compliance editing, quality control, scheduling, on line preparation, transcoding/encoding content movement, and general media management activities.
It is not unusual to find significant repetition in tasks, multiple processes duplicating effort, and assets or metadata being stored in multiple repositories.
As various departments in the media enterprise have evolved organically with localised decision-making, it is not at all unusual for organisations to have multiple ingest processes, management systems, transcoding systems, and point to point integrations.
Making sure that project priorities are closely aligned to the primary business drivers can help determine the order in which new workflows are implemented.
Resistance to change
A former colleague, Dr. Peter Thomas, once stated that: “Broadcast is good at absorbing new technology, though poor at new process.” He went on to say that “The same technology can be overwhelmingly successful in one broadcaster and be a disaster in another. Success critically depends on business process re-engineering to optimally leverage technology” .
Implementing new asset management is far more than just buying and integrating technology; it requires leadership, governance, integration, cultural change and user adoption to make it work.
Sadly, changing the habits of key user groups tends to be an afterthought in many projects, and as a result, the success of a project is undermined as users retain workarounds, spreadsheets and informal processes.
This goes further than training. It starts with good communication to ensure that all affected users understand the broader goals of the project, and the importance of their part within that project.
It often relies upon ‘super-users’ who become champions for the MAM platform, and are the ‘go to’ people for users who have questions. These super users should be representative of different groups of operational staff, and provide a degree of leadership and inspiration for other users.
This does not mean that they need to be senior staff, but their attitudes are key.
Considerations for a MAM project
Define the Scope
The first point to address is the scope of the project. Whilst it is possible to specify a MAM solution that will touch nearly all media processes within a broadcaster, we normally recommend that the primary focus should be to support preparation of content for transmission and non-linear content distribution activities, both of which are generally human resource intensive operations.
Prioritise the Requirements
The second point to address is the priority of functionality required from the project. Functionality may be prioritised as Must Have, Should Have and Like To Have.
The definition of must have functionality needs to be treated carefully, and should be restricted to functionality where its absence will seriously jeopardise the success of the project, or will impede the ability for the broadcaster to get content to air, or on non-linear distribution platforms.
Too many ‘must haves’ will significantly restrict the broadcaster’s options when evaluating commercially available platforms, or will render the development of the project overly complex.
It is a perfectly valid approach to implement functionality in stages, over time, with the first stage addressing the key requirements, and additional capabilities introduced once the core system is operational.
For example, it might be desirable to deploy support for linear TX operations, and later add capabilities that would replace legacy management systems.
However, this approach introduces the risk of spending being curtailed once the initial objectives (especially those that produce the greatest operational efficiencies) of the project are satisfied.
What type of MAM platform?
The third point to address is to choose the type of MAM platform. There are a number of options here:
- A specific broadcast MAM solution, where the vendor provides the functionality, integration and customisation required. Examples of such vendors are TMD, VizRT, Tedial, Dalet, VSN, Imagine, SAM and Avid.
- A development platform that provides the basic MAM capability and toolsets, but requires the customer, or the customer’s chosen third party developer/integrator to develop user interfaces and workflow upon that platform. Examples include Vidispine, Imagen, Blue Lucy Media and Cantemo. This approach provides the ability to implement specific functionality that may not be cost effective with a commercially available broadcast MAM solution. The core functionality (e.g. database, search, results display and API suite) is generally made available to all customers as part of the overall platform cost.
- Self-Build. This option has been exercised by a number of broadcast companies in order to fully satisfy their presumed requirements. Although this approach does provide the greatest flexibility, it also usually comes with the largest price tag. Development costs and ongoing software support cannot be amortised across multiple installations, and are therefore shouldered by the broadcaster.
There are obvious practical reasons to buy rather than build a custom solution. They include maintenance, scaling, ongoing development and losing the code or the person that wrote the code taking another job.
On premise vs. cloud
The hosting of the MAM platform used to be a straightforward proposition. There were very few web-hosted (now referred to as cloud) platforms, and those that did exist provided little or no integration with the customers’ broadcast infrastructure. This of course has changed, with a plethora of cloud-based solutions now available.
There are advantages and disadvantages with public cloud hosted solutions, and the cost model is often skewed towards OPEX rather than CAPEX; this does not suit all organisations. The level of integration required with existing systems, and whether remote access to the MAM is required can also be major factors in this decision.
Workflow orchestration
Workflow orchestration (sometimes known as workflow automation or process management) is a capability of many, but not all MAM systems.
The ability to programme automated workflows that are dependent upon content metadata, the outcome of processes and operator input can significantly improve operational efficiency. However, not all workflow orchestration systems are created equal.
Some vendors offer the ability for their customers’ systems administrators to modify, create and programme workflows using standard scripting tools such as Windows PowerShell scripting language, UML and BPEL.
Others provide visual workflow creation and editing tools that allow the systems administrators to model workflows graphically, often using flow chart type notation.
Figure 1: A broadcast workflow designer from Tedial
These systems have workflow engines that manage processes within the MAM environment. Processes could include file movements, metadata updates (dependent upon the outcome of previous processes or changes in connected external systems) and transcode operations.
For MAM platforms that are integrated with external systems, this workflow automation can be extended to allow processes (e.g. auto QC) to be executed by these external systems and the results returned to the MAM operator and stored in the content metadata.
Integration
It is rare for a broadcast MAM system to operate completely stand alone, without integration to other management and technical systems.
Integration with other systems can be provided in a number of ways, including multiple point to point integrations whereby the MAM system integrates with third party APIs, or the third party systems each integrate with the MAM APIs. What is becoming more common however is the use of an Enterprise Service Bus.
An Enterprise Service Bus (ESB) is a software architecture model used for designing and implementing communication between software applications in a service-oriented architecture.
In general, an ESB can be thought of as a mechanism that manages access to applications and services to present a single, simple, and consistent interface to third party systems.
Instead of developing multiple separate connections from the MAM system to each third party system that must be integrated, an ESB provides a single point of integration for each connected system. This means that it becomes much easier to replace an individual component without worrying about affecting multiple different interconnections.
Figure 2: An example of an Enterprise Service Bus in a broadcast environment
A service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a well defined communications protocol, typically over a network.
A service is a function that is defined, self-contained, and does not depend on the context or state of other services. A service could be a repeatable business activity that has a specified outcome (e.g. perform auto QC on this clip, create browse copy of that clip, move another clip to archive, etc.).
In a MAM solution, these services may be components of the MAM system itself, or parts of external systems.
Within any SOA environment, there are Service Providers and Service Consumers. The principles of service-orientation are independent of any vendor, product or technology.
Figure 3: Service provider and service consumer in SOA
Enterprise Service Busses designed for broadcast are still quite immature, however some examples do exist, including Sony’s Media Backbone, and Squared Paper’s Busby.
These are certainly worth investigating, and their usefulness and value will increase as more adapters to commonly used broadcast equipment and systems become available.
Recommendations for Broadcasters
Our recommended approach for broadcasters considering a MAM implementation is as follows:
- Identify the areas in which a new MAM system can improve operational efficiencies and add value to media workflows. This may include support for the following processes:
- Content preparation workflows (viewing, QC, compliance, access services, etc.)
- Linear transmission
- Movement of content between different storage locations
- Metadata storage, management and enrichment
- Library and archive management
- Non-linear formatting and distribution.
2. Agree and prioritise the key requirements for the solution, and whether the system will be deployed in phases (often better than a ‘big bang’ approach).
3. Decide whether the system will need to incorporate other functionality at a later date (e.g. news or production archive, etc.).
4. Choose which type of MAM solution (as defined above).
5. Identify the systems with which the MAM will require integration, what data needs to be exchanged and how. We recommend the use of an ESB.
6. Visit other, similar broadcasters to study their MAM deployments.
7. Define and document all the workflows that will be deployed with the MAM system.
8. Create a short list of potential suppliers.
9. Create a short form Request For Information only once the above points have been addressed.
10. Identify the budget requirement for the MAM system, third-party software, hardware (if hosted on-premise), storage and professional services required to complete the project.
11. Create a business case and ensure high-level buy in, and identification of the deployment team is achieved prior to placing any contracts.
12. Identify and appoint motivated ‘super users’ from each affected department to become champions for the adoption of the solution.
It’s a complex process, and consultancy can, and does, help.
