From Blind Date to Happy Marriage: Playing Matchmaker for ECM and Business Process

In looking at many articles and industry analyst reports surrounding enterprise content management (ECM), readers are likely to come across something along the lines of: "Content is a critical element of business process." But how close to reality is this seemingly fundamental concept?

Over the past few years, an increased understanding of the importance of unstructured content as part of overall business processes has taken place. Organizations that have deployed ECM systems have realized significant value and improved operational efficiencies. These benefits result not only from ECM's ability to control and manage organizational documents, but also from its enablement of organizations to transform content into a natural part of each user's regular day-to-day work.

In many organizations, ECM is considered as important as other core information management systems, such as financial applications. And the association is accurate. It reflects the growing need to ensure that content is managed as effectively—and with the same vigor—as revenue or customer data. That said, the concept of ECM taking its place as a critical business system also highlights a core challenge that organizations face as they seek to expand the use of content in their business processes.

A Match Made in Heaven?
Many organizations are building applications and solutions that include content as part of the information that is used and created by the people and systems involved in critical business processes. As they work to build these applications, organizations face a series of problems because of the way existing systems have been deployed and are being used.

In general, content management has been deployed to perform a single function, or enable point solutions, that are designed to address the content needs of one particular department or process. Despite the documented issues that have resulted from these silos of content, the point-solution architecture contains the information that is required to build new, enterprisewide applications.

In order to take advantage of this opportunity, developers are forced to make a difficult choice. They can try to force a single enterprisewide standard for all content management systems, or they can custom-build all of the connectors to all of the content management systems that the process-based application requires.

For most organizations, the standardization into a single content management environment is not possible. The costs associated with shifting the existing, working systems to a new environment are prohibitive. Adding to the restrictions for many organizations is the fact that the content management environments they control (and can work to standardize) are not the ones that are the real problem. Systems that exist outside the organization, beyond the control of the development and IT teams, have content that needs to be included in the applications and business processes inside the organization. These external systems can reside in government agencies, supply chain partners, customer organizations or anywhere across the extended enterprise. Because of the need to use content from both internal and external systems, and because of the cost of shifting away from working systems, the selection of a standard content management environment is not a practical alternative.

That leaves the development team with only one option—build all of the required integration points themselves. While this is possible, it poses some significant challenges and additional costs. First, does the organization possess the skills and knowledge required to develop these connections? Next, do the different content management systems provide enough access points and flexibility to allow this type of connection? And how will these connections be maintained over the life of the application?

This type of effort shifts the development resources inside the organization from integrators and business analysts to developers and maintainers of custom code. This shift results in higher overall costs and means that other critical business activities are not being automated or improved. Without some better mechanism to address the need to find, manage, use and share content—across both internal and external systems—ECM solutions will be limited to single-purpose, departmental applications.

The iECM Consortium: Making the Relationship Work
The key to solving the problem is in working toward interoperability, not integration. What is required is a mechanism built into all ECM systems that lets the systems truly work together and share content. A mechanism that would permit each application to use a common set of services, with a common set of definitions, to find, access and use content from any system that supports this standard. Fortunately there is a group of people working on just such a mechanism—the Interoperable Enterprise Content Management Consortium (iECM).

The iECM Consortium has been established to help organizations address the issues connected with the interoperation of ECM systems. It is working to define a standard that will provide the foundation for interoperability along with a set of best practices that can be used by vendors and users to implement interoperable solutions. The iECM will also work to develop proof-of-concepts and demonstrations of how ECM systems can be made to work together.

The iECM is defining a model for interoperability that includes three areas: services, metadata and components. These three areas form the iECM Reference Model. The first area, iECM Services, is a set of common content management operations, such as check-in and check-out. All ECM systems provide some form of these functions, but in order to achieve interoperability we need to have a set of agreed to and defined services that can be assured to exist and behave in the manner that they expect.