Making the Case for Leveraging Content-Management Middleware in Digital Asset Management
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.
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.
Source: IBM, Gilbane
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.
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.
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.
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.
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.
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.
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.
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.).
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.
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:
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 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.
Because of its size and breadth, U-M represents a microcosm of the media needs of many different industries. These include:
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:
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 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:
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.
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
These common tasks shared by the entire community include:
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.
Source: Louis E. King. © 2004 The Regents of the University of Michigan
Figure 2. Components and consumers of DAM services provided by the University of Michigan’s digital asset management system (DAMS)
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.
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.
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:
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.
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.
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.
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.”
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.
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.
Building on top of such services:
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:
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/.
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.
For more information, call your IBM sales rep or contact:
| IBM Corporation | Stellent, Inc. |
Digital Media Solutions |
7777 Golden Triangle Dr |
| 1133 Westchester Avenue | Eden Prairie, MN 55344 |
| White Plains, NY 10604 | Phone: 952-903-2000 |
| digmed@us.ibm.com | sales.inquiry@stellent.com |
| www.ibm.com/solutions/digitalmedia | Reference: Ancept Media Server sales |