Models for XML in ECM

Increasingly organizations want to manage content from an enterprise perspective, across departments and content and asset management systems. XML is a key enabling technology for integrating disparate systems, repositories, and business processes. However, both ECM vendors and end-users alike promote and employ XML in various different ways.

In some cases, XML is used as an abstraction layer across repositories. In other cases, XML is used for content and data interchange. XML is often employed for enterprise metadata ("reference") repositories.

XML adoption has been somewhat uneven, however, partly because ECM and content integration vendors use XML in highly different ways, and because standards adoption has remained uneven.

This session will look at some emerging models in the industry and attempt to identify some implementation patterns. It will also examine which standards appear to have the most traction in the marketplace.

1. Introduction

Enterprise Content Management, or "ECM" has become a prominent buzzphrase in the content management industry. While the ideal of managing content at the enterprise level appears attractive on its face, in reality, specialists and analysts often mean very different things when they talk about ECM.

Part of the confusion stems from the plethora of technologies and disciplines that call themselves "ECM" solutions. These range from imaging to document management, to search, web content management, asset management, and portal and DRM tools, to name just a few. So what is ECM, exactly?

2. Model #1: Large Function-point Solution

Many content management vendors -- and some architects -- describe their solution as "enterprise" class, because it is designed to work across multiple departments, perhaps even multiple installations. Thus one will see an imaging or workflow vendor describe themselves as an "ECM" supplier, because their single-point solution is nominally scalable.

Some enterprises will indeed select a single vendor in the name of supplier consolidation and training and implementation efficiencies. In practice, however, the various implementations of a tool tend to be accomplished and supported independently (often by separate development teams), with somewhat diminished economies of scale and potential for conflict with business sponsors for whom the centrally-mandated tool was not a good match.

Nevertheless, the advent of XML in general and Web Services in particular, enables savvy enterprises to provide centralized content management capabilities as a service to different business units and applications -- ideally on an opt-in basis. A plethora of organizational skills are required for this to succeed, but the model is showing potential in the field.

3. Model #2: Integrated Suite of Content Management Services

Many different applications fall under the rubric of "ECM" including Digital Asset Management (DAM), Document Management (DM), Web Content Management (WCM), Product Data Management (PDM) and more. Major ECM vendors have begun to acquire or build these various pieces. Today, the products in these suites are really free-standing tools packaged together for marketing purposes, but usually sold, implemented, and supported by separate internal groups within the vendor.

Sometimes people ask why ECM vendors don't just dissolve all these tools into a single package to create a truly "enterprise" solution. After all, document management, records management, digital asset management, and XYZ management products do fundamentally the same thing: they ingest content, enable repository services, employ metadata, support workflow, allow you to decompose and recompose derivatives, then output or archive content in various formats. Is there an über-dashboard here for all your content?

I don't think so. It turns out that these different tools tend to get used by different people within the enterprise, who employ different authoring systems, have varying interface needs, and create diverse downstream products. These systems often need to work together, but enterprises are still figuring out how and when and where. Smart managers will ask "why," too.

So I think the product families (DAM, DM, RM, WCM, etc.) will remain distinct, at least in the near-term. ECM suite vendors seem to agree. They are expending much more effort cross-selling these tools than integrating them. To the extent that vendors are trying to integrate these toolsets, it is often in the context of a single unified repository, rather than a more XML-powered, distributed approach to content storage, transformation, and interchange.

4. Model #3: Single Source of the Truth

An alternate approach to ECM looks less at the different middleware systems in place and more at the content itself, in an effort to create a single source of authoritative content objects for use across the enterprise. This effort is most advanced in publishing companies (looking for greater value through multichannel publishing) and heavily-regulated industries (looking to simplify compliance).

The maturation of the XML family of specifications, and growing implementation experience, is quietly driving this model, and leading to a variety of success stories in the marketplace.

At least two persistent problems remain here though. First, the challenge of "roundtripping" changes to content from a channel-specific production environment (such as print) back into the authoritative repository presents substantial logistical and technical hurdles. Secondly, required cultural adjustments among staffers (who must now manage components instead of documents) creates substantial drag on these projects and is not helped by the relative dearth of tools to simplify analysis of dependencies and create multiple previews of renditions in context.

5. Model #4: ECM is a Discipline

All enterprise content management systems provide 2 basic services: repository services (e.g., categorization, version-control, etc.), and business process services (transformation, workflow, etc.). These can be understood as disciplines that require a core set of infrastructure and capabilities. For example, enterprise-wide taxonomies, reference repositories, and thesauri are essential for taking a truly repository-independent view of enterprise information.

By analyzing ECM as a set of core services, enterprises can build skill sets and adopt tools independent of heavyweight ECM product suites, using maturing XML standards and services-oriented architectures to solve discreet business problems.