Architectural Considerations in Digital Asset Management

Making the Case for Leveraging Content-Management Middleware in Digital Asset Management

Mark Walter, Senior Analyst, The Gilbane Report, October 2004

Sponsored by IBM and Stellent

You can also download a PDF version of this white paper (18 pages).

Abstract

What is the proper foundation for an enterprise-scale Digital Asset Management (DAM) system? How much of that system should be part of an organizations shared infrastructure and how much should be tailor-made to a specific application? There is no single answer to these questions, but changes in the technology industry are forcing everyone vendors and customers alike to change their assumptions about how DAM systems will be built. This paper explains how the content-management infrastructure is changing, why that matters to DAM, and what benefits can be derived from leveraging a content infrastructure for DAM. Examples from an enterprise implementation at the University of Michigan illustrate the types of architectural issues and requirements that affect platform choices when selecting a digital asset management system.

---

DAM in the Context of Content Management Architectures

Demand for content integration is driving organizations to lay content-management frameworks that provide common services for DAM and other content-related functions.

In today’s technology marketplace, digital asset management (DAM) refers to systems and processes for fine-grained management and control over rich digital media assets, notably high-resolution images, audio, video, animation, and other kinds of multimedia. Historically, DAM systems were viewed as discrete systems that served professionals in creative and production departments, and DAM systems were built from the ground up by vendors focused on serving this community of users and their specific needs. DAM vendors may have made use of standard relational databases, but much of the key functionality they provided—workflow, security, storage, file capture, manipulation and delivery—was coded directly into the DAM application and tuned to the file types and business processes of managing rich media.

Today, the landscape for managing digital assets is changing. Companies are recognizing the value of their intellectual property at an enterprise level and so are taking steps to make digital assets—and the software that manages them—available across their entire organization and even to trusted business partners and customers. The desire to incorporate rich media into a broader range of business processes is driving demand for increased integration of DAM functions with the rest of the business information-management infrastructure. This demand for content integration also extends to other types of content—text, records, email, electronic documents—which is leading many businesses to lay a common framework of general-purpose content-management services. These services—library services, workflow services, storage services, delivery services—may not be specific to one type of asset, nor to one type of application. Instead, they provide a set of core technical capabilities that an enterprise can leverage across many content-intensive applications. These core content-management capabilities form the backbone of a new generation of content-management and digital-asset management applications that are built on top of a larger content-management framework, rather than built from the ground up as standalone applications.

The need to incorporate rich media into a broad range of business processes is driving demand for integration of DAM functions with the rest of the business information-management infrastructure.

What are the components of a media middleware framework? What advantages do they bring to developing a DAM system? When does it make sense for an organization to layer its digital-asset management system on top of an underlying digital media infrastructure? This paper is designed to help businesses buying DAM systems by answering those questions, presenting key considerations that influence how DAM systems are built, and illustrating with examples from the field how a media middleware framework applies to DAM in the context of a large enterprise.

Digital Media Middleware

Each generation of computer technology adds a layer of abstraction that makes interaction with the computer system more intuitive, more flexible, and less bound to the specific characteristics of the hardware and software environment. Graphical user interfaces abstracted commands, so that users could invoke commands by clicking on icons or selecting a choice from a menu. Relational databases abstracted structured data from applications, which made the data accessible to a variety of software for a wide variety of purposes within a corporate enterprise. The Web abstracted Internet navigation and sparked a wave of Web-based infrastructure that now permeates the globe. As their underlying infrastructure changes, developers writing new applications take advantage of these abstractions, the standards for which are set by large industry players, such as Microsoft, IBM, or Oracle. Organizations with legacy applications struggle to integrate them with new applications written to more modern platforms.

Today, a new middleware layer for information management is emerging, one provided by enterprise content-management (ECM) suppliers, such as IBM, EMC, or Stellent, which are larger and have greater development resources than any individual DAM system supplier. In some cases, the services provided by these emerging digital media/content-management platforms create an abstraction layer for unstructured digital assets (text, graphics, and rich-media), similar to what was done over a decade ago for structured relational data. The general framework for this middleware layer of content services is depicted below in Figure 1.

DAM and content-management systems built on top of such a platform make their assets available not only to their own applications but also to other applications within the enterprise. At the same time, some ECM frameworks also abstract applications and data from devices. Developers and end users can store and later retrieve assets without necessarily having to be aware of the physical locations and storage media on which the assets reside.

Figure 1: Generic ECM architecture. A robust platform for enterprise content management (ECM) supports a variety of content types and facilitates process automation by providing a set of content-centric services that can be shared by a variety of applications, including digital asset management. Source: IBM, Gilbane

Enterprise Services That Matter to DAM

Most commercial DAM products already leverage standard database platforms. In addition, many are also leveraging web application servers, rewriting their applications to the .Net or J2EE standards. The new layer of abstraction provided by content-management middleware rests above the database and web-application server platforms, as illustrated in Figure 1. The specific set provided by enterprise content-management platforms varies from vendor to vendor, but typically they include features that, if not provided as middleware, would need to be built as part of a DAM application. The platform services that are of particular relevance to DAM include storage, library and metadata, indexing and search, authorization, workflow, and collaboration.

Storage

Digital assets are stored on a variety of media, both online and offline. Because unstructured information, especially time-based media files (animation, audio, and video) are so large, special-purpose storage devices and systems are often required. For example, ten years ago, relatively few organizations outside of media companies needed a system to automate manipulation and delivery of videos or movies, so DAM suppliers serving media companies developed their own interfaces to storage subsystems. Today, the use of digital audio and video for marketing and training purposes has made high-volume storage a general-purpose capability of interest to all segments of industry, which has led content-management suppliers to add similar storage services to their platforms. In the case of IBM, for example, it offers prebuilt integration with Tivoli’s Storage Manager but also provides an architecture that enables an organization to create a centralized metadata index of its assets, even if the assets are stored on a variety of storage systems and devices. The integration with Tivoli enables IBM—and DAM supplier Stellent—to focus on application issues, while Tivoli focuses on keeping pace with advances in storage. Regardless of what storage system is used, end users of the DAM system can set storage rules and find and manipulate assets as if they are part of a single repository—without needing to be aware of where assets are physically stored.

Authorization services

All ECM platforms can control access privileges: what users can see and what they can do with assets. Applications that take advantage of this resource do not have to provide their own redundant access control mechanisms; instead they can implement ones that are consistent with other content applications written to the ECM platform. This enables the DAM implementer to tie into corporate directories via LDAP or other protocols and to keep the access control mechanisms of the DAM system in sync with changes to access control technologies and procedures made at the corporate level. In an enterprise setting, it also enables the DAM system to leverage access control lists that may already be maintained at the corporate level, in some cases by the middleware platform.

Library services and metadata

All DAM systems rely on a database to track and manage assets. An enterprise-class content-management middleware layer typically provides a set of scalable, general-purpose library services, such as check-in/check-out and versioning, which the DAM system can leverage. For enterprise implementations, such services should be available across multiple repositories and desktop operating environments. In addition, because the ECM middleware must support a broad range of applications, it typically features a flexible and extensible metadata model, which is critical to implementing DAM on an enterprise level across multiple business units, each of which may have unique metadata requirements and even specific taxonomies for classifying their assets.

Metadata standards are specific to industries as well as to data type. The medical field, for example, has a very different set of descriptors for its images than those of the news industry. Although your organization may have its own set of descriptors that it uses internally, buying a system that supports industry standards increases your flexibility in connecting your DAM system to other systems—both inside and outside your company. If your DAM system will serve a large enterprise that conducts business in several industries, then your DAM system should be able to support multiple metadata standards for a single type of file. When assets are categorized, they are usually done so against a fixed list, called a taxonomy. By leveraging the metadata services of a middleware platform, an organization can enable a taxonomy created for DAM to be shared by different systems that span different content types and departments. In some cases, assets will have to be categorized against multiple taxonomies. A typical example would be digital goods sold through different channels, each of which has its own way of categorizing materials.

If you expect your DAM system to grow beyond one department or to support a variety of assets types and purposes, then its metadata model must be extensible, so that you can describe the assets in ways that facilitate finding and reusing them. If you conduct business in several industries, then your DAM system should be able to support multiple metadata standards for a single type of file.

Indexing and search services

ECM platforms typically provide one or more indexing and search technologies as a standard service. Although field and full-text searching are still the most common techniques, it’s not unusual for an ECM platform to also offer multimedia-specific capabilities, such as visual searching or indexing of video key frames. Content repositories built on top of the ECM platform, including DAM repositories, automatically plug into this infrastructure. Users can run federated searches that find assets stored in multiple repositories across the organization.

Workflow and business-process-management (BPM) services

ECM platforms often have their own workflow software for automatically routing digital files, alerting users of status changes and triggering automated processes. Rather than have their own separate workflow software and APIs, DAM applications that build on top of ECM middleware simplify integration of DAM with other applications and leverage the customer’s expertise in developing workflows. Utilizing an underling workflow platform (e.g., IBM’s MQ Workflow) also leverages the research and development that the larger ECM platform vendor makes in workflow, enabling the DAM application provider to focus on applying that functionality to media-centric applications rather than writing new core workflow capabilities.

Collaboration services

The majority of ECM platform vendors have recently integrated shared work spaces and associated collaboration functionality (instant messaging, discussion lists, project calendars, voting, etc.) with their core content-management services. These collaboration services are especially useful to DAM applications, because a very high percentage of DAM-related business processes involve collaboration with contractors (agencies, freelancers, studios, etc.).

Other services

We recognize that some ECM platforms provide additional services not listed above. Among these might be asset capture services, such as a shared document-scanning module; categorization or cataloging; transformation services, such as text and image conversion or transcoding; delivery services; or digital rights management. The fact that this list is so long—and that it continues to grow at a rapid pace—underscores the point that as the content-technology industry evolves, ECM services will play an increasingly important role in support of DAM systems. By leveraging ECM services, DAM suppliers no longer have to create a redundant set of content services on their own.

We also recognize that the content-management and DAM software markets are undergoing consolidation. Several ECM vendors have acquired DAM products and are retooling them to align with the vendor’s ECM platform. As part of their due diligence, customers should investigate the underlying architecture of a DAM system to understand the extent to which it aligns with and leverages the services provided by a more general-purpose ECM platform.

Benefits of Middleware Services to DAM

The new level of middleware provided by an ECM platform enables application developers to focus more on the specifics of their applications and less on lower-level functions that are better left to infrastructure and middleware providers, such as IBM, Oracle, and Microsoft. More importantly, to customers the benefits from this approach can be seen in five areas:

• Scalability. The ECM middleware layer is written to support a distributed architecture that anticipates a high-volume of material, created and accessed by users who are geographically distributed and work in different functional areas. Scalability has become increasingly important to DAM, because there is a growing sense that as use of rich media grows, it should be viewed more as a corporate-wide resource than as an isolated function.
• Integration. The ease with which DAM functions and workflows can be integrated with those of other systems is also growing in importance, as organizations seek ways to tie managed assets into processes that span multiple systems and departments. The spectrum of such applications is broad and diverse, ranging from customer-facing examples like a merchandizing kiosk at a bank to back-office applications that tie scanned images or recorded phone conversations into call-center support operations. A single ECM connector to a DAM subsystem can take the place of several point-to-point, one-off integrations. This approach not only cuts development time; it also reduces the need for staff to learn new APIs and removes system-to-system dependencies that make changing systems over time so hard and expensive.
• Flexibility. By abstracting data, metadata, storage, and associated content services from the DAM application and user interface, the organization gains flexibility in how DAM can be deployed. As an example, server-based indexing and library services can be provided at the enterprise level, regardless of the operating system and editing tools at the user’s desktop.
• Adaptability. Organizations and business conditions constantly change. Systems must evolve to adapt to changing business requirements and also to stay aligned with advances in technology. By writing to a general-purpose framework that the ECM supplier updates, the application developer insulates a DAM application from technology changes within or below the platform. This approach frees developers, integrators, and customers to focus on adaptations that are specific to the DAM system and its implementations, while still supporting upgrades to the baseline technology infrastructure.
• Leverage. Building on top of a content-service layer creates leverage in two ways. First, from a financial standpoint, the platform enables the organization to reap additional return on its already-sunk costs in the technology from new applications. At the same time, both the DAM system developer and the customer leverage the research and development investments of the ECM platform vendor, which is typically a much larger company supporting a much larger base of customers. Second, from a skills perspective, the customer can leverage the skills that its own technical staff has acquired in applying the platform to the business. When an organization seeks to expand those skills, it is often easier to find people within the company and outside in the marketplace who have expertise in popular, general-purpose technologies than it is to find those with experience in niche applications.

Putting the Benefits in Context: DAM at the University of Michigan

An enterprise focus illustrates architectural issues that span many businesses and functions

The benefits of building DAM on top of ECM middleware cut across all sectors of industry, but it is often easiest to understand the implications in terms of specific examples. This section illustrates how architectural considerations come into play in the context of a large enterprise—in this case a university—that seeks to implement digital asset management as technology infrastructure. The university’s vision is to implement DAM as a set of core services available to all members of its community while still accommodating the specific needs of different departments and constituents.

While this example shows the use of DAM in the context of one market segment, because of its diverse user community, it also exposes many of the issues that face architects implementing enterprise-level DAM systems in other industries.

The University as a Corporate Enterprise

The University of Michigan (“U-M”) is a public institution of higher education and a major research university that includes classrooms and laboratories, libraries, museums, radio and television stations, and a large medical complex, including its own hospital. 1. With annual revenues in the range of $3 billion, U-M has more than 50,000 students and about 34,000 faculty and staff on campuses in Ann Arbor, Flint, and Dearborn. The main campus in Ann Arbor encompasses more than 300 major buildings spread out over 3,000 acres.

A university research institution is in many respects like a corporate conglomerate. It has a variety of business units (in this case 19 different schools) that operate somewhat autonomously. All 19 schools fall under a single corporate umbrella, which provides central functions, including human-resource management and finance, but each school also has its own particular media needs and the autonomy to set its own budgets and policies. As a public institution, U-M is subject to many complex policies and rules imposed by federal and state regulatory bodies, and these rules are not consistent across its different business units.

U-M has a central information-technology (IT) organization that provides infrastructure technology, such as high-speed networking, across the entire campus. This central organization is complemented by IT departments within each of the U-M schools that provide many technical services and all of the local technology support. Similarly, there is a product-development center for academic technologies (the James and Anne Duderstadt Center) that researches and implements core infrastructure technologies. Its work in providing digital asset management as a campus resource complements the media-related activities at individual schools that have their own media staff, systems, and facilities.

One campus representing many different industries

Because of its size and breadth, U-M represents a microcosm of the media needs of many different industries. These include:

• Education.As an educational and research institution, U-M is typically labeled as part of the educational market, where DAM systems often serve as the backbone for delivering instructional materials to students through learning-management systems, portals, or other online delivery systems. As in commercial industry, U-M’s DAM system must support local collaboration and production as well as distance-learning courses delivered through third parties.
• Media & entertainment. U-M’s Office of the Vice President of Communications, which operates its own television and radio stations, shares many of the same rich-media requirements as its commercial counterparts: a high volume of rich-media content that is delivered through traditional broadcast channels as well as streamed online. Other departments, such as the History of Art Department within the School of Literature, Science & the Arts, contain collections of high-resolution photographs comparable in volume and quality to what might be found at a stock photography house or commercial magazine or book publisher.
• Healthcare. The university’s schools of medicine, dentistry, and other health sciences commonly make use of special imaging equipment, such as MRIs, that are typical in the healthcare setting. Their capture, manipulation, search, storage, and metadata requirements are quite different than those of other schools within the university, and in many cases their operations are regulated by state or federal agencies.
• General business. The university’s graduate school of business, as well as its extensive undergraduate program, represents a broad spectrum of business activities—architecture, government, sports, law, and engineering, to name just a few. The types of materials and their associated metadata, processes, and creative and production systems vary widely, depending on the nature of the material and the work.

One enterprise covering many business functions

Although research and education are the primary motivators for DAM at U-M, in fact the university already makes use of rich media for many of the same purposes that are typical in a corporate enterprise. These include:

• Archives and collections. Different schools within the university are creating repositories of intellectual property stored in digital form. The collections reach both internal and external audiences, which means that access and rights privileges must be managed and enforced.
• Research and collaboration. Like any organization that conducts research, U-M wants to create shared repositories of both in-process work and finished research. In many cases, researchers from different schools collaborate on projects and therefore have a need to share their work during the development process. Yet researchers also want to locate and retrieve relevant materials that are finished and have been published by others.
• Online learning. The university delivers a variety of course materials, including video, both within its campus to labs and classroom settings and outside its campus to distance-learning participants.
• Public communications. The university regularly uses rich media in its communication with the public. Communication takes place over several media, including print, Web, and broadcast channels and includes activities such as airing events and performances, both live and recorded.

U-M summarized in broad terms the scope of its digital asset ingest, management, collaboration, and distribution activities in the original request for proposal that it sent to prospective vendors:

“We gather digital assets in many forms: text files, audio files, still images, video images, research datasets, and real-time experimental data. We distribute these assets through our Web sites, information portals, public radio and television stations, and via streaming audio and video services. We repurpose digital assets for use in traditional on-campus classroom instruction, for distribution via our Web-based course management system, and for distribution via our relationships with other learning partners. Increasingly, our research projects capture digital assets to share among research colleagues.” – from the University of Michigan DAM Request for Proposal

All of these activities were already taking place before the University considered implementing a DAM system, but many of them were hampered by manual processes and a lack of shared media-management and processing capabilities.

The Need for DAM at U-M

The decision to test and ultimately implement DAM on a enterprise level at U-M was made on the heels of an important strategic study conducted by the University to consider how to capitalize on the opportunities and address the challenges of information technology that is in a state of constant change. In its report, issued in 2001, the University President’s Information Revolution Commission concluded that to retain its leadership status, U-M needed enterprise-wide commitment to utilizing and experimenting with emerging technologies: “With adequate investment in human capital and physical infrastructure, strong leadership, and coordinated, campus-wide involvement, the University can take the lead in redefining higher education in light of the information revolution.” 2.

An enterprise approach to DAM was deemed most appropriate, because there was a clear need for rich-media technology and services across all of the schools, and U-M already had in place a networking infrastructure that could support the heavy data traffic associated with digital video. Different schools at the university have different levels of need for digital asset management, but everyone could benefit from a shared system that enabled them to store, find and distribute rich media. Examples of the challenges and opportunities included:

• Improve sharing of content and collections. U-M lacked centralized storage for rich media. Its repositories, which included institutional file systems, library collections, course-management systems, and Web content-management systems, existed in pockets, isolated from each other. The lack of centralized storage led users to rely on local storage and peer-to-peer sharing of assets, which made it difficult to share content across boundaries. For example, a guest lecture by Madeline Albright might be videotaped by the business school and streamed to the Web. That same video might be of interest to humanities students in a current-events political science course, but without a common index, they might never find it. A common metadata repository would enable students and faculty across the entire university to search and retrieve rich-media assets that are relevant to their task at hand.
• Facilitate collaboration.Faculty and researchers frequently collaborate on course materials and research projects, and an increasing number of projects are interdisciplinary, involving individuals from different departments. In an extreme example, as many as 15 instructors and assistants might collaborate on a single course. Without a common system, faculty, students, and staff found it difficult to share content during its development.
• Increase use of rich media in instruction. Even though many faculty members recognized the value of rich media, few were making use of it in their classes. The faculty and librarians lacked experience and tools for managing rich media individually or institutionally, and there was a lack of large-scale rich-media services, including workflow, searching, or tools for managing intellectual property rights. Implementing a core set of rich-media services would enable students and staff to experiment with the technology and begin to discover how it might be applied to their work.
• Support and improve existing media management. In addition to general requirements shared by everyone on campus, there were specific needs that representatives from specific departments had identified. For example, the University’s Vice President of Communications sought a better way to manage the large amounts of video and audio being recorded for broadcasts and performances. The School of Dentistry wanted to migrate into digital form its extensive collection of dental anatomy and oral pathology images and videotapes of dental procedures. The School of Literature, Science and the Arts planned to digitize and post online one of the world’s larger history of art collections (more than 450,000 images). To be successful, any enterprise-wide DAM system would have to be sufficiently robust and flexible that it could accommodate the specific needs of departments that already had their own tools and processes for working with rich media.

Architectural Considerations

Louis King, Managing Producer for Digital Asset Management Systems at U-M, described a series of architectural considerations that factored into U-M’s selection of IBM and Stellent (then Ancept) for the project. The implementation, begun in 2003, installed Stellent’s Ancept Media Server running on top of IBM Content Manager in a “Living Lab” at U-M’s Duderstadt Center, which is charged with developing media technologies that will benefit all of U-M’s schools and colleges. King serves as the technical lead on the project.

General Considerations

The decision to view DAM as a core enterprise capability directly affected U-M’s requirements in terms of the modularity of its DAM system design, the standards it would have to meet, and the scale of users and activity it would have to support.

Because this creative environment will be so diverse, our DAM infrastructure must be highly scalable, open, and flexible. It must scale to accommodate high usage levels from both inside and outside the University. The DAM infrastructure must not limit access to particular types of workstations, operating systems, or creative software. And the infrastructure must support the translation of digital assets into a wide variety of formats.” –from the University of Michigan DAM Request for Proposal

Modularity of design

For a system to work across such a large and diverse organization, it has to be very reliable, scalable, yet flexible with regard to how it is used. The DAM team decided to provide a core set of services that were common across the entire end-user community. These common tasks shared by the entire community include:

• Sharing metadata
• Searching and retrieving assets
• Moving data across the network
• Setting access controls

At the same time, there are many common tasks that do not necessarily share the same tools. King explained: “Everyone working with video is transcoding it, but not necessarily in the same way. Many edit and collaborate on rich media, but not necessarily in the same way or with the same tools. For example, FlipFactory and Virage are the tools of the reference implementation, but the medical school might want to use something different for MRIs so that it could encode metadata on a time-frame basis. … We wanted to design a system that would be independent of editing and delivery.”

The conceptual framework of U-M’s digital asset management system (DAMS) and the services it provides are shown in Figure 2.

Figure 2. Components and consumers of DAM services provided by the University of Michigan’s digital asset management system (DAMS).  Source: Louis E. King. © 2004 The Regents of the University of Michigan

Adherence to standards

In contrast with previous DAM implementations at the university, which were focused on specific departments, this one would lay a foundation of core services on top of which specific applications could be built. As King paraphrased a colleague’s observation, “We wanted indoor plumbing for rich media. . . a service, that like water at the tap, could be turned on or off by students, faculty, and staff as they needed it.” Following the plumbing analogy, King noted, “It had to follow standards; there couldn’t be any special fittings; otherwise, it’s not going to work across all of the business units.” Standards that were important to U-M for this project included J2EE and the new JSR168 portal standard, which will also be used by their collaboration and learning environment (CLE). “Our intent is to be able to plug DAM into the CLE, so that multimedia can be made readily available online,” said King. In addition, the system had to work with the university’s security protocols, which continue to evolve as technology changes.

Scale

U-M already generates on average 25 hours of video a day—representing more than 100 GB of digital video. As more members of the U-M community become familiar with the system and begin to take advantage of it, King anticipates that usage will grow, conceivably up to 100 hours a day. With 70,000 users on its networks, more than 20,000 user-seats per semester operating in its C-Tools Collaboration and Learning Environment, and Internet2 linkages throughout the country, King noted that U-M “serves as a good testbed within which high-volume rich-media transaction systems can be benchmarked.” Any system that serves the entire campus would have to be designed in a way that could scale in parallel with growth in usage.

As a system grows and its use expands across multiple departments and business units, the way in which it is administered will also change. Specifically, the need to distribute responsibility increases as more users adopt it. If local business units cannot configure the system themselves, then the centralized service group runs the risk of becoming the bottleneck that keeps the organization from fully utilizing its DAM system and the assets it manages. For example, each time a new employee needs to be added to the set of authorized users, or a department wants to change the roles and permissions of a certain set of content, someone authorized and trained in these administrative functions must make the change. If the only people trained to perform such functions are in the corporate IT group, then any time a business unit wants to make a change, or implement a procedure different than what was originally outlined, they must wait until the central group can implement it for them.

U-M anticipated the tension and bottlenecks that can arise over control and successfully avoided them by proactively creating a DAMS Affiliate program. Through this program, the Duderstadt Center provides DAM infrastructure as a corporate resource but teaches technology staff from individual schools how to administer the system themselves and also how to train end users within their schools. Recognizing the control issues that accompany large-scale adoption, U-M selected a DAM system that is flexible enough to allow the central group to distribute responsibility for metadata, workflow, storage, and even authorization. It then established a program that smoothes the process of distributing these responsibilities.

Metadata

A central metadata index and a shared search capability is a core requirement at U-M, but because the materials being loaded into the DAM system are so diverse, the system must be flexible enough to accommodate a variety of metadata models. U-M anticipates the need to support a variety of metadata schemas, including:

• Instructional objects: SCORM / IMS
• MPEG 7: Merged video content and metadata
• MPEG 21: E-Commerce / DRM metadata
• Institutional repository: Dublin Core, MARC
• Discipline-specific and project-specific schemas

For the purposes of searching across schools, it will be beneficial to share one set of core metadata. But to enable more precise searching within one school, the system must allow each type of asset to have additional specific properties that can be exposed by customizing the user interface. For example, the videos of dental procedures might have a different set of metadata than the videos of school classrooms taped by researchers in the School of Education. Medical images will likely have a different set of properties, and different classification scheme, than images in the art collection.

Each discipline, application type, school, or project may require unique metadata structures. At the same time, each asset should share common metadata information established upon ingestion… The ability to define and mange multiple metadata structures and associations for any digital asset is an important attribute for a successful University-wide DAMS implementation.” –the U-M DAM Request for Proposal

The conclusion of the DAMS team was that a successful vendor partner must be able to demonstrate an open and robust structure that allowed both a common set of metadata and the ability to attach multiple metadata schemas to a single asset. It would have to accommodate schemas that evolve over time, and it would have to allow structured data fields that might be filled in using both structured (e.g., pick lists) and unstructured (e.g., free-form text entry) ways.

Workflow

Although the system is installed as a corporate resource, it is managed and run by the individual schools, each of which has and will continue to have its own way of doing things. The approach that the DAMS team has taken is to teach IT service units how to implement workflows, so that individual schools and departments can configure workflows to meet their needs. “When we went looking, we wanted a system that was flexible in design and made it easy to create new workflows,” said King. Knowing the diversity of the user community, “the last thing we needed was a system that dictated a certain workflow,” King added.

For enterprise implementations, the ability to leverage the workflow capabilities of an underlying content-management platform is a key distinction from departmental DAM implementations. Workflows differ across business units, and increasingly businesses are seeking ways to integrate digital assets and DAM services into larger business processes that are not specific to DAM. U-M, for example, is experimenting with ways to use DAM in support of interdepartmental collaborative research and course development. In the context of another corporate enterprise, such integration may involve integrating rich media with merchandizing, marketing communications, product packaging, or support. Through the use of a common workflow framework, the organization gains flexibility in tying together information and processes that span multiple departments.

Storage

Three key factors led U-M to conclude that its DAM system needed a way to logically separate storage management from the library of metadata. First, not all business units have the same storage needs, so no single storage solution would be optimal across all of the schools. Second, some schools already have storage systems and procedures in place, and they would be reluctant to plug into a centralized system if it didn’t support their existing systems. Third, even though it can make recommendations, the central IT organization is not in a position to dictate a single storage solution for all of the business units. In some cases, it does not want the responsibility for managing storage, because the business unit’s IT organization already has people with that responsibility.

We wanted one system that can reference any storage system but doesn’t have to own it.”—Louis King

Storage requirements are directly related to volume of data and usage, which varies from school to school. The television and radio stations run by U-M’s Office of the Vice President of Communications, for example, generate considerable material and already have storage systems in place. Other U-M schools are just starting to experiment with the use of video for instructional purposes. In order to create a centralized index without requiring specific storage solutions, the system would have to flexible enough to accommodate both new and existing storage systems. “We wanted one system that can reference any storage system but doesn’t have to own it,” King explained. “That way, nobody had to change what they were doing in order to take advantage of the shared metadata repository. They can continue to store material as they did before, but now at the same time they can make that material available to anyone else they want to.”

At the same time, U-M wanted an architecture that allowed flexibility in how storage was managed from the standpoint of policies and procedures. If a school is new to multimedia, it can opt to allow a shared IT organization, like the Information Technology Central Services group, to manage the storage as part of its media services. But when a school already has people who handle day-to-day storage administration, acceptance of an enterprise DAM capability hinges on the central group’s ability to relinquish control to the local business unit. Consider, for example, something as routine as backing up the data. In a departmental application, it’s assumed that the person who installed and runs the system will take care of creating back-up copies of the assets in case of hardware or disk failure, using the policies and procedures of his department. But when a DAM system becomes an enterprise application, used by many departments across multiple business units, then centralized administration—including back-up—may no longer be feasible. “As the providers of infrastructure, we don’t want to learn all of the policies and procedures that are particular to each school. We want the flexibility to distribute storage management responsibilities to the business units that have people who know the material and its uses much better than we do,” said King.

Authorization and Rights Management

Any large organization wrestles with authorization issues when trying to implement DAM across an enterprise, but U-M has particularly complex requirements that demand a robust underlying framework. “We need strong security and access controls to integrate with our mature LDAP environment, to implement rights-management models, to manage multiple ownership and access privileges, and to ensure the authenticity and currency of distributed digital assets,” explained King.

The complexity of U-M authorization requirements manifested itself in several areas:

• Support for technical standards. U-M wanted its DAM system to tie into corporate authentication standards—its internal cookie authentication and LDAP—as well as external authorization protocols.
• Leveraging existing ACLs. Rather than create a redundant set of access control lists (ACLs), the DAMS team wanted to leverage the ACLs that the University already maintains for its courses. The University conducts thousands of classes, and participants change every semester. The DAMS team recognized that it would be virtually impossible to replicate these lists, and that trying to do so would result in a massive amount of redundant effort.
• Support of user-defined ACLs. U-M differs from many corporate settings in that it also has a need for user-defined ACLs. Both faculty and students are allowed to set up both shared and private work areas. For example, there might be departmental ACLs for material to be shared across faculty of a department, and faculty and staff may set up ad-hoc project or committee ACLs. All members of the community can also create their own ACLs for communities of interest or individual projects, such as e-portfolios. King estimates that once DAMS gains broad acceptance, U-M may be generating 50,000–100,000 unique ACLs a year, a number far too large for one IT organization to manually maintain.
• Incorporation of DRM. Lastly, the University wanted a DAM platform that would not only control internal access but also could tie into mechanisms for tracking and processing licensing rights and ultimately convey these rights in the packaging and delivery of multiple media asset types to multiple audiences, taking into account privileges and privacy issues. King cited the project RFP, which explains the rationale for including digital rights management within the DAMS framework: “We know that we have great needs to manage the delivery of digital assets to multiple communities, each with its own unique requirements regarding digital rights (full or restricted licenses, pay-per-use licenses, public domain distribution, fair use, etc.). In addition, the University must be sensitive to the privacy requirements of the federal government (e.g., FERPA, HIPAA) as well as the privacy and intellectual property rights associated with sponsored research contracts.”

Summary

As organizations strive to create value and efficiencies from their DAM investments, they increasingly seek ways to make their assets accessible to other users both inside and outside the organization. Keeping the DAM system consistent with industry standards and emerging enterprise platforms—portals, web application servers, databases, storage systems, and security and authorization frameworks, for example—makes it easier for organizations to stay nimble and adapt their DAM capabilities to changes in both business requirements and technical infrastructure. In a large and complex organization like the University of Michigan, layering digital asset management on top of an underlying enterprise content-management framework provides both the scalability and flexibility required to successfully implement DAM as an enterprise-wide capability.

Conclusions

The DAM Infrastructure Is Changing

Organizations worldwide are recognizing the importance of managing unstructured content, a portion of which includes rich-media assets that historically were housed within DAM systems. Increasingly, the DAM platform needs to be engineered for a kind of openness and richness that allows ready integration with a wide variety of processes, workflows, and tools. As a result, organizations across the globe are putting into place pan-departmental (enterprise-level) service frameworks on which new DAM applications will be built.

These service frameworks, or content-management middleware, provide services that were once embedded within discrete applications and could only be accessed by users of those discrete applications. Examples of services that matter in a DAM context include library services, metadata management, storage, authorization, workflow, search, and other features that are often shared by content management and digital asset management applications.

Middleware Provides Clear Benefits to DAM

Building on top of such services:

• Provides a framework that enables DAM systems to scale and grow over time.
• Speeds integration of managed assets and workflows with business processes and systems across the enterprise.
• Increases organizational flexibility and adaptability by abstracting DAM applications from content services provided by the enterprise content platform.
• Leverages corporate investment in technology and staff expertise in core platform services and also the investment by larger platform vendors in new content technologies.

Key Factors Influence Architectural Choices

The degree to which a content-management middleware platform provides value to a new DAM implementation is determined in the context of an organization’s overall IT strategy and the functional and technical requirements of the implementation. Among the factors that can help you determine the relative value and weight of leveraging a content middleware platform are:

• Scale: The number of business units and end users that the system will serve; the volume of assets and transactions; the diversity of media types and applications; and the level of system reliability and availability required.
• Modularity: The degree to which you want DAM application code and user interfaces to be abstracted from physical storage, metadata, workflow, and other content services.
• Standards: The organization-specific and market standards to which you want the system to adhere.
• Skills: The availability of technical skills within your organization and their domains; your preferred software platforms, programming languages, development environment and interfaces; the opportunity to leverage technical expertise required by the DAM application elsewhere the organization.
• Administration. The degree to which you want to be able to distribute operation, control and administration of the system organizationally and geographically without giving up the benefits and efficiencies of a centralized system.
• Library services and metadata: The number and complexity of metadata models, taxonomies, and workflows; the opportunity to leverage and integrate with existing content technologies and services; the opportunity to integrate DAM with other systems and business processes.
• Authentication: Your requirements for tying DAM into existing corporate authentication protocols and access controls; the complexity of access control required; the type and complexity of rights-management requirements.
• Storage: The number and types of storage systems to be supported now and in the future; the need to support decentralized capture and storage while still maintaining a single shared index (logical repository) for searching; the need for both centralized and decentralized administration of storage management.

1.) More information about the University of Michigan is available at http://www.umich.edu. Specific information about this project is available on the Web at: http://sitemaker.umich.edu/dams.

2.) The complete report can be found at: http://www.umich.edu/pres/inforev2/.

Sponsoring Companies

Using a content management middleware approach when deploying a digital asset management solution can be critical to long-term success. The IBM DB2 Content Manager and Ancept Media Server solution was developed with this in mind from its inception. No other DAM solution uses this approach, and this is one factor that makes ours truly unique. Simply stated, IBM DB2 Content Manager was designed to be middleware and Ancept Media Server was designed to use middleware.

IBM solutions, technologies and services can fast-forward your company’s transformation to an on demand model. In an increasingly digital environment, creating content that can be quickly repurposed and seamlessly distributed over multiple networks is critical. Enterprises can extend their reach—and their returns—by enabling integrated media, adopting open standards, and extending more autonomy, and sales potential, to business partners. IBM Digital Media Solutions encompass a portfolio of applications and services to help companies plan and execute these activities, add more value and take control of their media assets. These open, standards-based offerings utilize the IBM Digital Media Factory framework, which sustains the integration of rich media—from content creation to content distribution—with indexing, archiving and search options, digital rights management and more. Now enterprises can move beyond simply creating, managing and distribution digital media to fully embracing the potential of rich media.

No single application or provider can supply all of the solutions and services that our clients require in this complex and rapidly evolving marketplace. The extensive IBM Business Partner network provides additional opportunities for our customers, and enables us to continue our strong and long-standing commitment to strategic partnering. This philosophy continues to earn us top industry recognition, including being named Digital Content Management Company of the Year by IT growth consulting firm Frost & Sullivan. As the largest consulting organization in the world, IBM has the knowledge, experience and reach to deliver customized solutions to meet the needs of media and entertainment companies. We continue to be the recognized leader in the industry, investing more in technology research and holding more patents than any other technology provider.

IBM Corporation 
Digital Media Solutions 
1133 Westchester Avenue  
White Plains, NY 10604
digmed@us.ibm.com
www.ibm.com/solutions/digitalmedia

Stellent, Inc.
7777 Golden Triangle Dr 
Eden Prairie, MN 55344 
952-903-2000 
salesinquiry@stellent.com 
Reference: Ancept Media Server sales