CHAPTER 7

DAM Technology Services: Architecture and Administration

Application Development and System Administration

System Security

Reporting and Analytics

Distribution

Configuration

Customization, Integration, and Extensibility

Scalability and Performance

DAM Administration

A Special Note About Standards

Now that you’re familiar with the various features that enable the end-to-end creation and distribution of assets, let’s explore the different aspects of system administration and management—the parts that allow you to configure and manage how the systems work.

Application Development and System Administration

DAM systems offer different levels of facilities for application development and system administration. We’ll look at these facilities broadly, evaluating vendors based on overall offerings for the administrator and developer, and then look into the detailed functions within these services.

The core of media-oriented, broadcast-caliber DAM software comprises a set of server software that performs a wide variety of services: essence management, video analysis, workflow management, indexing and search, integrations, and system administration tasks. Broadcast DAM systems are also expected to handle vast amounts of rich media content; thus, the underlying architecture determines scalability and performance.

Configuration and customization differ substantially. While you can enhance and tailor a system with both, configuration specifies predefined changes that have been built in to the system, do not require coding, and can be performed by an administrator. With customization, you enhance the system by adding new capabilities, applications, or system integrations that require programming. Extension and integration are specialized forms of customization.

System Security

The DAM system’s security model defines, organizes, and manages users and their abilities within the DAM. It controls what they can see and do, which objects (such as files and metadata) they can perform actions on, and where and when they can do something in the DAM application.

Many people can be involved in asset creation, management, production, and consumption. A DAM system facilitates these processes and provides access directly to asset creators, editors, reviewers, and users. A system installation often leads to more people becoming involved in these processes. To manage internal access and privileges, you need a system that scales to support a variety of different user types and the expansion of the user base. Finally, you also need to secure the content itself.

Let’s dig into these issues in more detail.

Access Control

The DAM system enforces security primarily through access control. As with any technology application, access control has several pieces:

• Authentication: Proving that you are who you say you are, typically by providing a user name and password. A check typically is done against a directory service like an LDAP or Active Directory server.

• Authorization: Identifying what “entitlements” you do or do not have, based on your Directory record, specific rights granted in the DAM, or both.

Authentication and Authorization

Most DAM packages provide both authentication and authorization mechanisms. Many can tie into existing corporate directory systems, such as LDAP or Active Directory servers, for basic authentication. Authorization occurs within the DAM itself.

Note that authentication and authorization methods vary markedly among products. For example, some products access an LDAP repository in real time. Others require that the LDAP server sync with—or cache—credentials within the product’s access control lists on a regular schedule. In the former case, you need to ensure the complete reliability of the network between your asset management system and your directory server. In the latter case, there can be periods when a user’s rights have been expunged in the corporate directory, but the user still has access to the asset management system’s privileges, or conversely, when a user has been added to the corporate directory but isn’t visible to the DAM system until the next synchronization. Beyond these timing concerns, there are other issues with directory services, including whether the system can support the creation of new users when they are added to the LDAP server and how to do this.

Single Sign-On

In some enterprises, the IT department insists that users have a single login for all the applications they can access. In this case, the DAM system may need to support single sign-on (SSO) and integrate with specific SSO devices and systems. You almost certainly need some customization here (see Figure 7.1).

FIGURE 7.1
Creating a role and assigning privileges in AssetBank to support single sign-on and to integrate with specific SSO devices and systems.

Roles and Groups

The DAM system can assign privileges to users based on the role they play—their place and job in the workflow—or the group to which they belong. These privileges define their authority; the scope and visibility of the asset population they can access; and typically the set of functions, operations, or capabilities they have rights to perform. Often, a user makes up a group of one. Note, however, that some vendors do not have notions of groups in their system. Others have groups but not roles.

Consider the following groups and roles for a generic enterprise.

Sample Groups

• Salespeople: Can only view and download assets

• Marketing managers: Can upload assets, add metadata, initiate and manage reviews, approve assets, and control visibility and distribution of assets

• Graphic designers: Can create, modify, and submit for approval images and layout files (may also be a role)

• Librarians: Can manage classification systems and metadata vocabularies

Sample Roles

• Super user: Can perform any function in the system

• Editor: Approves assets

• Author: Submits assets

• Reviewer: Reviews assets

• Intern: Adds metadata to assets

• Consumer: Downloads and consumes assets

• External partner: Can consume visible assets but not deposit assets

You may need a system that lets you use a combination of groups and roles. Using preceding samples, let’s say that Suzanne serves as an editor in the marketing managers group. She initiates review processes and approves the changes or updates that authors have made to assets.

Some products ship with generic roles already configured for your use. Except in the very low-end systems, you can modify those roles as necessary. Not all applications, however, allow you to create completely new roles. Among those that offer this capability, you may not be able to circumscribe functions exactly how you would like. For example, you may want your interns to add and modify metadata but have no other privileges, or you may need your managers to initiate workflow tasks but not be able to author content.

Additionally, some systems use a combination of privileges and permissions to set entitlements. Privileges correspond to what a user has the right to do. Objects, such as an asset or folder, grant permissions, allowing a given operation to be performed on them. For example, a user may have permission to modify an asset, but if the asset does not allow modification, the user cannot perform the action. The user must get consent from the asset owner to perform the specific operation. This combination may sound attractive to you and may in fact become necessary in highly sensitive environments. In reality, however, the attendant complexity frequently becomes an administrative nightmare and major support problem, as users are locked out of certain assets and they don’t know why.

Given this wide variance in the implementation of the security models, make this a point of emphasis when speaking with prospective vendors. You should be sure to understand how to set up the roles and groups you think you need and the granularity of control offered by the security model. Consider the complexity and power offered by the product and your expected use case. If, for example, you have very simple needs, stay cautious about products that offer highly granular control mechanisms (which may include things like hierarchical roles). These mechanisms can be hard to manage, and a novice administrator can accidentally create problems, such as locking various roles out of functions or assets to which they should really have access. This is also an excellent area to explore in reference calls or site visits.

Asset Security: Encryption

Asset management systems may offer additional security features beyond access control. Depending on the nature of the files or the value of assets or metadata, a DAM system might offer one or more flavors of encryption.

For some companies, assets represent critical or sensitive intellectual property (IP). Certain brand assets, such as a movie that is digitally distributed, military photos, a sensitive financial or brand strategy document, or sensitive metadata, should not be allowed to be modified. In all of these cases, you may want additional levels of security beyond access control. Furthermore, many companies using a SaaS provider need to encrypt assets or metadata transmitted to and from the hosted facility.

Encryption can be found in three places in the DAM system:

• Import or upload

• Storage

• Delivery or download

Some IT organizations or implementations may need to encrypt files as they’re transferred from the user’s desktop to the system, particularly for SaaS-provided DAM systems. Furthermore, when the SaaS vendor implements the system as a shared repository and service, you may prefer to encrypt requests for additional security and privacy. The reverse is also desirable: encrypting assets to transfer from the asset management system to the end location (for example, desktop, FTP site, or email).

Asset management systems commonly use SSL for over-the-wire encryption, but you may encounter other protocols and approaches. For example, many video formats adhere to various video-industry encryption standards, and SOAP payloads can be digitally signed and encrypted. Remember that SSL adds extra overhead to a wire transfer, however, and can slow delivery.

Alternatively, you can apply digital rights management to distribute sensitive assets, files, or purchased content such as books or music. Broadcast-oriented, media-centric vendors usually tell you to use the DRM technology from the content provider rather than providing any DRM services of their own. Note that DRM differs from the rights management discussed earlier. DRM enforces access and use, based on the dictated rights, rather than simply specifying the rights and privileges. With DRM, the asset and its metadata reside in a secure, encrypted envelope. Only those who have the proper keys have rights to access it after download or distribution.

In some systems, XMP metadata can be inserted into images prior to transmission or download, and individual fields can be encrypted. This function allows the metadata to travel with the asset. It facilitates automated downstream processing on the asset, while protecting sensitive fields from tampering, access, or change. This is an emerging area of metadata encryption and an emerging area of DAM technology. Instead of maintaining the metadata separate from the asset, as when it is in a repository, the system embeds the metadata into the asset, providing a true “asset” that can provide much deeper information about itself to external systems.

Finally, some highly secure DAM systems (primarily for government and military uses) may require encryption of assets and metadata in the repository, that is, a managed file system. This type of system requires encrypting both the database and repository and is less common in commercial use.

With any encryption/decryption use, performance and visibility are primary issues. Both encryption and decryption add overhead to the transmission and manipulation of assets. Assets must be encrypted before transmission, decrypted afterward, and decrypted prior to manipulation and use. These operations clearly can slow down performance; SSL is an example. For larger assets or a batch load of a large number of assets, encryption can slow delivery. You encounter the issue of visibility when you upload ZIP archives as assets. In this case, the DAM system treats the ZIP file asset as it does any other file format. It may not be able to provide an icon for the ZIP file asset and may not be able to provide a preview. In those rare cases with encrypted databases and repositories, access control governs the asset’s visibility. If you have proper access to an asset, the system would likely decrypt and present it for you. This process, however, adds overhead to the display performance.

Common Technologies

The underlying code base (that is, the programming languages in which the software is developed) is different among the various DAM products. Many are .NET based and run on the Microsoft technology stack; others combine a mix of technologies like Java, C, and C++ for different underlying modules.

Many DAM systems today use Microsoft SQL Server as the data repository, but those that are more broadcast-oriented and media-focused run on IBM DB2 or Oracle database software. Search functionality is implemented using Lucene or the related Solr and Elasticsearch technology (both are open source). Most DAM systems run on Windows, Linux, or UNIX operating systems.

If your enterprise has corporate standards about the technology on which the product is built (versus just being interested in the system’s performance, maintainability, and scalability), these differences are important considerations.

Reporting and Analytics

With the increasing maturity of the DAM marketplace, buyers now look at the software not just for asset management and workflow automation, but for real management. Management begs metrics—and metrics require reports. Ironically, many digital asset management systems don’t provide such reports, although some vendors are waking up to the fact that they should. Some systems don’t even create logs upon which you could build such reports. Look back over your business objectives and figure out how your system could help you to measure how you’re doing. Decide which ones are most important for your business.

Here is a small sampling of reports that could help you justify the asset management system’s value and expand its adoption and use:

• Who is logging in to the system, how often, and who does not use it at all?

• Which assets are most frequently downloaded or emailed?

• Which assets are most frequently viewed or accessed?

• How has the number of assets grown in volume over time?

• Who is contributing assets and who is consuming them?

• How many of each kind of asset do you have?

• Are there any orphaned assets?

• What volumes and types of content have been classified according to specific nodes in your taxonomy or by community tagging?

• How much storage is consumed?

• What payment or usage obligations have been incurred?

• Are there any “rogue” assets in the system?

• What are all the derivatives or linked assets?

You may also want to produce reports in various formats or utilize existing third-party reporting tools that you already have in-house. Some DAMs support third-party tools, allowing you to generate more configurable or custom reports in various formats, such as Excel, Word, or PDF.

Distribution

A key aspect of scalability and capacity is technology distribution. In this context, we don’t mean the assembly and delivery of the assets themselves, rather the extent to which and how a system can logically and physically distribute services and repositories.

We see three major opportunities in this area:

• Distributing services vertically by emphasizing load on the client, server, or storage tiers.

• Distributing services horizontally by separating services, perhaps putting very intensive services, such as transcoding, on specially configured hardware, or clustering services for better performance. We return to this discussion in the next section on scaling.

• Distributing the repository for potentially better access and performance.

Distribution describes where the processing, storage, business logic, and aspects of the user experience occur in the system. These capabilities may be centralized or distributed—or some combination of both, depending on the level at which you look. Distribution is a function of the overall architecture and is governed by architectural design decisions. As an architectural issue, it fundamentally affects several aspects of the overall system, including scalability and capacity, resource allocation, and hardware and software costs. As such, it has a significant effect on your total cost of ownership. Depending on the architecture, you may be able to add hardware incrementally, improving your system’s performance, capacity, or geographic distribution at a reasonable cost. However, you may have to replicate the entire structure to achieve your performance, capacity, or distribution goals.

Asset management systems are complex software systems that integrate a variety of components to provide digital asset management services. A DAM system has to upload, render, process, store, index, manage, search, transform, secure, and deliver assets and metadata. Where it performs these functions is the primary issue affecting how well the system performs.

Many DAM vendors have adopted service-oriented architecture (SOA) principles where different functions and processing services are clearly separated, with well-documented interfaces (inputs and outputs of a service) to each other. SOA principles make the software modular and make for easier maintenance as well. Another advantage is the ability to deploy multiple instances of the same service on either the same server or a different server. This enables you to start small and add more capacity as requirements grow. Of course, your site’s hardware configuration is determined in combination with other system needs, but generally speaking, a well-architected SOA system that can run on commodity software is a viable approach.

While we’ve mainly discussed the software aspects, many DAM systems are designed to run on commodity hardware. (Commodity hardware refers to Wintel, or Windows servers with Intel chips, which cost less compared to higher-end servers from Oracle and others.) Google has popularized this approach, and instead of using a small number of high-end servers, it uses a larger number of less powerful computers, thus easily adding incremental capacity at lower costs and providing better failover support.

Asset management systems vary significantly in architecture. Key areas of differentiation include where distribution functions perform, how the components or subsystems perform these functions and work together, and how these functions can scale as systems grow in capacity and utilization. Most DAM systems use a centralized model. In this model, the system transfers and uploads files to a central location for processing and storage. This model generally works for small- to medium-sized files. For large and very large video files and print-ready PDF files, however, this approach may be problematic, especially if your enterprise has multiple geographic locations attempting to access these files. You don’t want to move them around very much—if at all.

The system must process every asset to generate one or more renditions. Rendition examples include a thumbnail image; streamable, low-resolution proxies for video; or PDF files representing a rendered preview form of a brochure. Again, for small to medium files, this process works well in a centralized location. This central location could have a farm of media processing engines distributed over multiple local machines. For longer or for HD videos, the system should process them locally to the user, perhaps store them locally, and hand up the resulting proxies to the system for centralized storage.

Even if the system appears to be centralized from an access perspective or a logical view, it may physically distribute the storage. In this case, the system allows assets to live in multiple geographic locations while maintaining a centralized index of the assets. It may use a variety of technologies to do this, including distributed databases or distributed computing technologies, such as CORBA, Java Message Service (JMS), or Microsoft .NET.

Systems vary on where the DAM application runs. Client/server applications provide rich functionality as desktop applications that communicate with a back-end server. Other (and today, most) systems are browser-based, executing on the server, and serving the pieces from a Web or application server to the user via a thin client. Increasingly, more highly interactive and responsive rich Internet applications—using Web development technologies like HTML5 and JavaScript—provide desktop-like functionality and interactivity in a browser, and execute the business logic or application in specialized servers.

In short, an asset management system integrates many processing capabilities from various places. Most business organizations couldn’t care less about these architectural issues. However, they are critical to your IT group, which will have to manage the system and its infrastructure.

We recommend examining several key issues:

• How the processing and storage are distributed

• Whether each tier of processing can be scaled independently, thereby reducing overall costs, allowing you to spend only where necessary

• Whether local processing is needed or desirable

• How the storage scales

• What communication mechanisms are used to enable distributed processing

• Whether it uses an application server, web server, or some other technology, and how these can be clustered and scaled for performance and capacity

You need to weigh manageability, flexibility, and power against the needs of your workflows and users’ geographic locales.

Configuration

Configuration means changing some comparatively simple default settings, often through a browser interface or by editing a text- or XML-based config file. Adding users to and removing them from a system represents a common, and usually simple, configuration. Others can be more complex, yet by our definition, configuration does not require a developer.

A broad range of capabilities can be configurable. Beyond the typical system-tuning parameters for the core repository, database, DAM application or application server, you can usually configure the following:

• Metadata schema

• Folder name and structures

• Metadata presentation—what metadata is visible on which screens

• Definitions of user roles and groups and their privileges

• Structured workflows—who, what, when, and how frequently (often using templates)

• File types

• Predefined transformations and renditions

• Filters and predefined saved searches

• Log contents

• Initial landing pages

• The user interface appearance, or “skin”

In some cases, the metadata model requires SQL coding to define the model, making it more of a customization than a configuration. Additionally, DAM systems vary in their support of single sign-on and integration with and access to information in existing directory structures such as LDAP or Microsoft Active Directory. In some, this process can be configured; others require programming.

Customization, Integration, and Extensibility

Customization means writing some custom code to do something that a browser-based configurator couldn’t accomplish. One of your first considerations here should be configuration management.

Just what might need to be customized? In a DAM system, customization can apply to virtually any part of the system. Enterprises commonly customize unavailable features or integration with external systems. Occasionally, the user interface requires customization to make it more approachable or to tailor it to a specific use case or workflow. You may need to write code to modify or add workflow actions; to integrate with an unsupported media processing engine, tool, or application; or to integrate with a back-end accounting or billing system.

Some systems have APIs or better-designed development APIs. The vendors set up these APIs so that third parties and IT shops can extend the system with minimal training. Beware of systems that appear to have tremendous function in the vendor demo. It’s not that the system can’t do these things; it’s just that vendors may glue together many examples of previously customized capabilities that are not actually available out of the box. Adding these capabilities will result in additional cost to you. Be sure to ask whether a specific feature is native or if it is a customization.

Customization also can get you into trouble. Poorly written code can cause memory or security leaks. You can encounter thorny problems at upgrade or patch time. You may need to retest the code against the new DAM system and possibly rewrite it if it doesn’t work properly.

Make sure any code is well documented—we recommend requiring this as a condition of payment—and follow best practices laid out by your vendor. If your vendor doesn’t lay out best practices and you expect to perform significant customization, reconsider your choice of tools.

As in customizing, “extending” software requires coding, but typically at a deeper level. Extension deals with creating discrete objects, classes, or modules that run inside or alongside the system.

You would extend a DAM product to supply features that might be missing entirely, such as a personalization subsystem, workflow subsystem, report writer, archive, or a different display of metadata or assets. All of these caveats still apply, that is, the importance of configuration management. You should pay close attention to possible security conflicts with the system itself. You also may encounter potential problems if you mess around with lower-level application or platform settings.

In the vendor evaluations, when we say a product is more “platform oriented” rather than “product oriented,” we mean that it lends itself better to extension, potentially at the expense of implementation speed and ease.

Integrating your DAM with other applications or infrastructure will require a combination of configurations, customizations, and extensions. For more high-definition scenarios, broadcasters have a plethora of systems, and you will need to engage in an elaborate dance between two or more different systems. Broadcast-oriented systems can integrate with a variety of systems for media processing, delivery, monetization, rights management, and video system infrastructure.

At the easy end of the spectrum is data integration, in which you integrate information from another repository or system. Some DAM products have mechanisms to draw metadata from outside their own repository. Of course, this process can be complicated, especially with respect to synchronization, security, and versioning. You need to respect the business logic of both systems when moving and accessing data. Work through an API wherever possible.

Process integration can be more complicated for two reasons. First, most DAM systems do not have sophisticated event models. Second, our industry has not standardized as effectively around business process integration approaches. You may want to look for supported, prepackaged connectors between systems rather than writing your own.

Note that, unlike enterprise portal software, most DAM systems were not originally designed as integration platforms. Historically, the DAM industry has largely supported freestanding digital asset management operations. This is starting to change, but packaged software tends to change more slowly than business needs. For better or for worse, most larger enterprises still look to portal or business process management (BPM) software as their core information integration platform.

As you get a feel for your intended use of the DAM and work your way through the features and capabilities of prospective products, determine where you’ll have to customize the system to fit the needs of your workflow and use cases and where the vendor provides built-in avenues to configure the system. Configuration is significantly cheaper and can be very flexible.

Scalability and Performance

Scalability and high performance are words that vendors love to use; IT needs to understand them. Digital asset management systems can range from single-user desktop applications to full-blown enterprise software systems. You need to examine how vendors portray the scalability, reliability, and capacity of their offerings.

Scalability deals with how you can expand or contract the system in response to increases or decreases in the number of users, assets, simultaneous operations, or execution of structured workflow processes. It also relates to how the system uses hardware, CPUs, storage, and networking infrastructure.

Reliability measures the system’s resilience, uptime, and consistency of operation. Can it use RAID arrays for redundancy and failover? Is it fault tolerant? Does it support clustering? Does it run on top of standard application server platforms that can themselves be scaled according to commonly understood approaches? Or is it a freestanding service that must be scaled according to vendor-prescribed means?

Capacity measures a variety of functions, including maximum processing, throughput, number of users, number of assets, and transmission speed, at a given time. Is the DAM system efficient in its use of hardware, or is it resource intensive? Is it multithreaded or multi-CPU?

In addition to the hardware and software considerations discussed here, another important aspect is the design of the network between the DAM system and user desktops. Because we’re talking about large volumes of video assets, the network bandwidth must accommodate a large volume of network traffic. If users work on low-resolution proxies and export EDLs instead of actual assets, it will reduce network traffic.

All of these issues must be considered and depend on the anticipated use and adoption of the system, IT’s predisposition to managing and maintaining the infrastructure, and the total cost of ownership.

Caching

The ability to cache information fundamentally speeds performance. Caching can affect system performance in several areas in a DAM system, primarily by serving as a place for system components to store and retrieve frequently or recently used data, assets, or information. The caching capability, however, may not be considered as a critical component.

In fact, you will find that caching is generally treated as a “tuning parameter” in most DAM systems. It can potentially be tuned at several places in the system, depending on the DAM’s architecture. For example, if the DAM system uses a commercial database, you can tune the database cache for more optimal query performance and result set management. If, on the other hand, the DAM uses an application server as a fundamental part of its architecture, you can tune the application server’s execution cache or data cache for different performance profiles. Depending on the transcoding technology used, the system may or may not provide and utilize a cache. If the system provides a cache, it can speed repetitive transformation or rendering operations on the same asset by retrieving it from the cache instead of processing it again. If the DAM makes use of a web server, you may be able to tweak the presentation performance of web pages in Web-based DAM applications.

In general, you should determine the DAM system’s capability for tuning performance. However, beware that caching is a very sophisticated topic and takes a true expert to understand all of its nuances. If you’ll be dealing in large volumes of assets or very large assets, you should have a knowledgeable person assess the system’s capabilities before assuming that it can do whatever the salesperson promises it can do.

DAM Administration

DAM systems provide tools for administrators to configure the DAM instance and monitoring tools. Administrators monitor both the status of the software services (running or stopped) and the status of different workflow tasks (for example, file transfers and format conversions). Among the different DAM vendors, these monitoring tools range from basic and utilitarian to extensive and polished.

Administrator User Interface

The last topic we discuss is the user interface and interaction, but it’s foremost in users’ minds as they evaluate tools and you persuade your colleagues to fully embrace your DAM system. There are two separate aspects of the user experience. The first is the asset manager’s user experience, and the second is the administrator’s user experience, which is often neglected or deemed less important. Given the modern emphasis of configuration over customization with software products, the usability of the administrator interface cannot be overlooked.

As previously mentioned, the DAM toolset consists of both browser-based and decreasingly, Windows-based clients. In the early years of DAM (mid to late 1990s), users had to be familiar with many different tools, each for accomplishing a specific set of tasks. Increasingly, however, DAM vendors are focused on combining multiple, disparate tools into a more tightly unified toolset in an effort to provide the required functionality all in one place.

Currently, users can navigate workspaces (folders with assets), search for assets, examine the details of those assets, preview assets, and change assets all from a single interface. Despite these improvements, the DAM user interface can overwhelm users because multiple screens are trying to capture as much rich detail about assets as possible. To prevent cognitive overload, it is important to map users to specific roles and display only UI screens that are relevant to the role. DAM vendors support role-based access to functionality and features, and during the initial rollout, the UI is configured to support different types of roles.

Many DAM vendors provide the ability to apply visual themes and skins to the DAM user interface, and some options are configured by the administrator and some by the user. Dark-colored and light-hued themes are available based on where the users are working; some users work in dark broadcast rooms and would prefer darker-colored themes. In general, these customization options are limited, and DAM products generally don’t offer a wide variety of choice.

In theory, the user interface of the DAM product could be easily localized from a technical point of view, but DAM vendors’ support for UI localizations varies. In general, European languages (which follow the same left-to-right orientation as English) tend to be better supported than Asian languages.

Rich media is largely visual, and as such, it needs to be seen and experienced to be understood. Thus, the presentation and usability of the user interface and the system’s seamless ability to integrate with content creation and visualization tools are essential for establishing a rich and effective experience.

Describing user interfaces and the user interaction in words is difficult. Therefore, we use the following figures to help you visualize and understand some of the key features that are important. See the example shown in Figure 7.2.

FIGURE 7.2
Annotating images in globaledit allows photographers and creative users to make comments, annotations, and markup directly in context.

Most DAM UIs have a common set of features:

• A tree structure for visualizing the folder or collection hierarchy and browsing

• An asset overview display providing thumbnails and possibly animated GIFs and summary metadata representing the content of the currently opened folder

• Icons that depict various additional information, state, or rankings on each asset

• Actions depicted as icons for functions that can be performed on individual or groups of assets

• A menu structure for additional functionality beyond the current screen

• Detailed asset and metadata views

• Search fields and search result pages

• Mechanisms for selecting assets, such as check boxes, drag-and-drop functionality clip-bins, and shopping carts

• Metadata entry fields

To become a power user with these features requires training and frequent system use. Indeed, while these UI features are common, the quality of a user’s experience derives from the ease of organization, flow, and user interactivity in performing tasks. You won’t be able to evaluate these features without trying the product first-hand, against your own workflows and scenarios (see Figure 7.3).

FIGURE 7.3
Asset management system UIs typically have a tree structure type of navigation that allows you to browse through assets by topic and view thumbnails of assets within each category (called a “library” or sometimes a “job”), as depicted here in Extensis Portfolio.

You may want to consider several other UI aspects:

• Organization: Is information laid out intelligently? Are the features to access and work with the information intuitive so that you can perform your job effectively?

• Presentation of metadata: Can the metadata be configured? By you? By the administrator? For different roles or groups? How much control do you have over hiding metadata or showing a summary of fields of your choice?

• Personalization of the UI: Can you manipulate the display of the UI to see only what you need or want to see? Does it change based on your role? Do you have any control over how and what you want to display?

• Ability to easily perform the task you need: How does the UI flow for a given task? Does it take a single step or several steps? Is it intuitive? Does it help you to do your job?

• Screen refresh and performance: How much time do you wait between each screen refresh? Does it only refresh regions of the screen that need it?

On this last point, more modern user interface technologies such as HTML5 have significantly improved user interface interactivity, performance, responsiveness, and usability. Newer web application development technologies enable you to update smaller regions of the screen, versus the old, page-based world of click-and-wait. This optimization can provide both greater interactivity and increased responsiveness, resulting in a significantly better user experience. Faceted search endeavors to bring such interactive experiences to the search functionality as well.

Many DAM vendors have made significant investments in integrating with the more common creation tools. These include the tools in Adobe’s Creative Suite (especially Photoshop and InDesign), as well as Adobe Reader, Microsoft PowerPoint and Word, and video-editing suites, such as Adobe Premier and Avid’s Interplay. Most provide players for various audio and video formats, including Adobe Flash, Apple QuickTime, and Microsoft Windows Media. A move is taking place to drop support of older file types, and most modern-day DAM systems use HTML5-embedded codes to deliver the video directly from the DAM or content distribution network (CDN) into websites and other touchpoints across the content journey.

Close integration allows you to search, access, and save assets across both the system and the tool, and presents these actions well within the context of the tool. A high degree of transparency in performing operations enhances your experience and allows you to focus on the task and not how the tool is connected to the DAM.

Some vendors, such as OpenText and EMC, have also made significant efforts to allow you to work with files in the file system. You can easily drag and drop them for ingestion into the DAM. This makes loading of assets much easier. DAM systems vary in how they allow you to attach metadata to the assets you ingest in this manner, however.

Ultimately, though, usability means “fitness to purpose.” Therefore, you cannot understand ease of use outside the context of business process. It also means that an enterprise that cares about meaningful and broad adoption of its DAM system will likely have to invest in modifying default user interfaces for different roles, tasks, or scenarios. You should have a clear idea of how to do that in the DAM systems you consider and how much effort it will require.

A Special Note About Standards

Vendors love to talk about standards. To be sure, standards are important, but there are fewer standards than you would think. Moreover, even those are less standardized than we’d like. Keep in mind that whichever boxes the vendors check, standards support tends to be a relative attribute rather than an absolute. There are different ways to comply with J2EE or to support the Dublin Core specification. You need to focus on how a particular tool supports a particular standard. In the following sections, we outline some standards that you might want to explore before you begin—or re-embark on—your DAM journey.

Currently, there are no definitive standards within the digital asset management industry. We see some standards as they relate to certain metadata standards (XMP, Dublin Core, and IPTC as outlined next). As the chaos continues in enterprise-based workflows, the need for an interoperability standard is clear.

Dublin Core

The Dublin Core metadata element set is a standard for interoperable, cross-domain information resource description. It provides a simple and standard set of conventions for describing items, making them easier to find, and enabling more intelligent information discovery systems. Dublin Core is widely used to describe digital materials such as video, sound, image, text, and web pages. Because of its simplicity, all DAM systems support Dublin Core in some form. There is, however, no body for qualifying, testing, or approving the implementation.

When you’re a DAM system buyer and user, this lack of an absolute standard can be critical, because Dublin Core provides a basic set of metadata fields that may be implemented differently in different DAM systems. As a result, while it may be likely that one system using Dublin Core can exchange information with another system using it, you cannot be certain. If you’re relying on Dublin Core as a key part of your metadata model, be sure to understand how the vendor implements it.

“Dublin” refers to Dublin, Ohio, where the Online Computer Library Center (OCLC) originated the work in 1995. “Core” refers to the fact that the metadata element set is a basic but expandable “core” list. The semantics of Dublin Core were established and are maintained by an international, cross-disciplinary group of professionals from library science, computer science, text encoding, museums, and other related fields. The Dublin Core Metadata Initiative (DCMI) maintains and evolves the standard.

This standard has two levels: simple and qualified. Simple Dublin Core includes 15 metadata elements:

• Title

• Creator

• Subject

• Description

• Publisher

• Contributor

• Date

• Type

• Format

• Identifier

• Source

• Language

• Relation

• Coverage

• Rights

Each Dublin Core element is optional and may be repeated. Dublin Core has no prescribed order for presenting or using the elements.

Qualified Dublin Core adds three additional elements—Audience, Provenance, and Rights Holder—as well as a group of elements that refine the semantics in ways that may be useful in resource discovery. Qualified Dublin Core also includes a set of recommended encoding schemes that are designed to aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules.

Historically, many DAM implementations have started with Dublin Core. We’re not sure why. Perhaps users wanted a well-defined starter set of metadata for describing assets. In some situations, such as with museums, Dublin Core was a common element in the museum information model. Therefore, if you don’t have an information model or a taxonomy for your assets, Dublin Core may provide you with a very basic starting point. However, we have found that most implementations quickly outgrow this core or expand it so significantly for their particular use case or domain that it becomes barely recognizable.

Dublin Core does not appear to be frequently used for asset transfer or interoperability. XML and XMP allow for easier mappings between systems using XSLT, for example, to transform tags from one system to another. Thus, the Dublin Core—or any metadata model for that matter—would be expressed into XML or XMP for output. It would then be mapped back into another system’s metadata model, according to a set of proprietary syntactic and semantic rules.

IPTC

A group of news organizations established the International Press Telecommunications Council (IPTC) in 1965 to safeguard the telecommunications interests of the world’s press. Based in the UK, the council is a consortium of the world’s major news agencies, publishers, and industry vendors. Virtually every major news organization in the world uses the IPTC’s technical standards for improved news exchange.

Since the late 1970s, the IPTC has focused on developing and publishing industry standards for the interchange of news data. In particular, the IPTC defined a set of metadata attributes to apply to images. Although the IPTC defined the standards in 1979, the concept advanced significantly in 1994 when Adobe created a specification for actually embedding the metadata into digital image files. These “IPTC headers” can be embedded into JPEG, EXIF, or TIFF formatted image files.

Photographers and printers commonly use IPTC metadata to store information about the digital images directly in the files. Applications, such as a DAM system, can read and write this information, facilitating workflows and communicating additional or needed information. Most DAMs support IPTC—particularly its extraction from the image file. Some systems support write-back, which inserts the metadata back into the file.

XMP

Adobe developed the Extensible Metadata Platform (XMP) in 2001. It is an XML schema for the same metadata as IPTC, but is based on XML/RDF (Resource Description Framework), a general-purpose language for representing information on the Web. It is inherently extensible. Adobe and the IPTC collaborated to produce the IPTC Core Schema for XMP, which merges the two approaches to embedded metadata. The XMP specification describes techniques for embedding the metadata in a variety of files including JPEG, TIFF, JPEG 2000, GIF, PNG, HTML, PostScript, PDF, SVG, Adobe Illustrator, and DNG files. Recent versions of Adobe’s Creative Suite products—Photoshop, Illustrator, and Bridge—support XMP, as do a small but increasing number of third-party tools.

Adobe, the XMP Open group, and some DAM vendors assert that an asset’s metadata should be embedded in the file and carried with it wherever it goes outside the DAM system. Historically, metadata in the DAM system remained separate from the asset. The DAM system didn’t typically attach or reinsert the metadata into the file once it left the system. With the XMP approach, the DAM system (as well as other systems) can process it more intelligently and make more intelligent use of the asset.

Systems embracing the XMP approach can at least perform XMP metadata extraction. They can read the file’s XMP information and use those definitions and structures to map the values from the file into metadata fields in the DAM. Some systems go further and use this information to guide the creation of new metadata schemas, such as definitions of metadata types and metadata fields, in the DAM system. This is a step beyond metadata extraction. It creates new DAM schema on the fly so that it can represent what XMP contains in the file. This capability can provide additional system versatility. You would potentially be able to dynamically create or modify the metadata model on the fly, using XMP, without system downtime.

This perspective is pushing an emerging trend: XMP-based workflows, systems, tools, and processes that are informed by and (in some cases) driven by the asset’s embedded XMP information. Thus, XMP will be useful to you if you expect to create more automated workflows or if you expect your files to have embedded metadata. We see this use of XMP particularly in advertising, prepress, and print use cases.

From a technical standpoint, transformation engines primarily handle the process of inserting and extracting XMP into and out of files. They perform this function at asset import or export, or sometimes as part of transforming an asset, so it can affect ingest, export, or transformation performance. It may, however, be buried in the overall ingest or transformation performance, so it may not be easily identifiable as a performance problem area. Metadata inserted into a file can increase the asset size, although for high-resolution images, this increase may be dwarfed by the size of the image itself.

Injecting metadata into an asset can change an asset from a binary comparison perspective. This is critical because many DAM systems use algorithms that examine the asset at a binary level to determine whether it is unique or already exists in the DAM system. Injecting metadata into the asset can change the outcome of this “checksum” algorithm, and thus create duplicate assets in the DAM. While you might argue that the asset hasn’t changed, its metadata has.

Some file formats don’t currently support XMP. When working with assets in one of these file formats, you need to use another approach, such as “side cars” and related files. In these approaches, the XMP information lives near or is appended to the file. Some vendors support this approach. Be aware that this approach can affect ingest and export and may not itself be supported for all file formats. You may encounter a problem if you want to have full XMP workflows using assets with XMP embedded metadata.

If you’re considering XMP, ask the vendor what happens in this case and whether the extraction of the metadata occurs before the system performs checksum or uniqueness calculation on the asset. Additionally, ask about the performance and asset size increases to get a sense of whether this would be a significant factor. In most cases, you will not encounter a significant performance problem.

Web Services Versus REST

Web services refers to a related set of protocols and technologies designed to enable applications to expose discrete features to each other over the Internet. Instead of hypertext, think of hyperservices. Much of the fervor around Web services has centered on marketplace integration and bundling B2C and B2B applications into a single transaction. Nevertheless, there is still a major DAM story, but much of it will happen within and as part of the enterprise network.

Web services stands on three interrelated standards:

• SOAP: The transport protocol that enables disparate applications to plug into each other seamlessly as services

• WSDL: The language for describing those services

• UDDI: The directory protocol for listing those services

Each of these standards uses XML.

REST stands for Representational State Transfer. It is another approach to providing and consuming discrete services using Internet protocols. With REST, services are mapped to URLs, and you serve or invoke any function through a GET, PUT, or POST to a URL. A REST-based DAM system enables you to invoke any standard operation in a repository through a URL and to access alternate versions or kick off a workflow by adding additional parameters to the POST or GET request.

DAM system managers recognize several benefits from a more service-oriented approach:

• Connecting better from desktop editing tools to back-end DAMs: Facilitating the transparent movement of assets between the desktop application and the DAM system and vice versa is a key element of successfully adopting a DAM system and streamlining workflow processes. While some approaches rely on native interfaces at the file system level to perform this function, Web services allow your creative and Office applications to search for, access, and save assets and then use them directly and seamlessly with the DAM system. Some vendors already use Web services to connect the DAM system to authoring tools and other applications.

• Integrating content silos, improving brand consistency, and removing redundancy and cost: Enterprises need interenterprise workflow today. The core problems are a lack of standards and silos of creativity and storage. Note, however, that we could often say the same thing of interdepartmental workflows within large, decentralized enterprises. I’ve seen brand marketing teams or corporate marketing teams within the same enterprise perform similar creative activities yet regenerate content because they can’t locate it, they can’t share it, or they don’t even know about it! You’ll see this occur with PowerPoint slides, even in small organizations, with everyone keeping and modifying copies on their desktop but no one controlling or owning the master or “released” version. The same problem happens with assets like logos, images, common charts and graphics, and other brand elements. A more SOA-oriented model enables the enterprise to offer central DAM services and desktop editing tool access for regional, local branches of the enterprise that still need to localize content or generate their own marketing collateral.

• Creating an “enterprise service bus” for rich media: DAM integration historically followed the same path as enterprise application integration (EAI)—point-to-point solutions. In contrast, an SOA-oriented approach would expose generic DAM services to other applications that can utilize their logic with the DAM system. Media and entertainment companies have taken the lead in this area. They have created enterprise service bus-based infrastructures built on SOA to facilitate the development of a range of applications that integrate a variety of other services and applications. In an SOA world, it shouldn’t matter which tool or applications you license; they interoperate via SOAP or REST.

JSR 170/JSR 283/JCR

JSR 170 (now JSR 283)—sometimes known as Java Content Repository, or JCR—is a specification developed under the Java Community Process (JCP) program. This expert group contains more than 60 individual members representing both major content management vendors and Java technology infrastructure players like Apache, IBM, and Oracle.

The goal is to provide greater code portability above the repository layer. Today, nearly all content management applications, including DAM systems, ship with their own “content repository” (usually proprietary). This repository usually extends a storage layer, such as a relational database, with the various service facilities that almost any modern content application requires. Nearly every vendor implements its “repository services” differently, using different terminologies and programming interfaces.

To the Java world (and possibly beyond), JCR promises a unified API that allows accessing any compliant repository in a vendor or implementation-neutral fashion. This would lead to the separation of concerns that characterize modern IT architectures. Some people call JCR the “JDBC of Content Repositories.”

The JSR 170/283 specification defines how an application and a content repository interact with respect to a number of content services. For example, the versioning facilities of a content repository are clearly defined, so an application knows how to browse the version history, check in and check out content items, or update and merge content in a standard fashion.

JCR compliance has different levels. While some DAM vendors have implemented JCR, few (other than Adobe) support it at all levels. If your enterprise already leverages JCR heavily in an existing enterprise content management system, there’s a chance you may be able to realize some efficiencies by choosing a DAM system that implements JCR and that (as a result) can integrate relatively smoothly with the ECM system. Otherwise, JCR is probably not something that should be determinative in your choice of DAM system.