The Gilbane Report: Volume 9, Number 9

Who Should Own Your Content Management System?

Download a PDF version of this article

Read the news for this issue.

While most of the articles we publish cover technology issues and trends for IT managers or business managers who need to understand content technologies, often what they need the most help with are the organizational challenges they face when introducing new technology. This is especially true in the case of today's content management systems (CMSs) as neither they, nor the content they manage, typically exist in isolation. Who controls the content is often a very sticky issue. A successful content management system implementation is one where the CMS system architecture, the organization, and the information flow all work in harmony. How do you begin to figure out how to do this?

This month we are pleased to have content management consultant and author Bob Boiko join us to provide some expert advice on these issues based on his extensive consulting experience. His article is excerpted from his comprehensive new book, due out any day, Content Management Bible.

New Book on DRM

By the way, don't forget to check out associate editor Bill Trippe's new book as well. Digital Rights Management, Business and Technology, co-authored with Bill Rosenblatt and Stephen Mooney has just been released, and as the title suggests, covers both technical and business issues.

Both books can be found at Amazon.com.

Who Should Own Your Content Management System?

The purpose of a CMS is to help organizations create and offer valuable content and functionality. For commercial organizations, the content and functionality aid in the sale of goods; for government organizations, the content and functionality aid in the production and distribution of laws and regulations; and for nonprofit organizations, the content and functionality support a social concern.

Each department in an organization has something to add to the design or implementation of a CMS, but none of the traditional groups has the inherent right to own the system. Because the job of a CMS is so closely aligned with the job of the organization, to do its job, a CMS must be integrated fully into an organization.

In this article, I'll discuss how a CMS fits into a stereotypical large organization.

Because the task of a CMS is so closely aligned with the job of the organization, to do its job, a CMS must be integrated fully into an organization. Of course, a CMS might serve a small part of an organization. Many organizations are diverse and have a variety of types of value to create and offer. In these cases, it might be necessary or preferable for the CMS to be designed to serve a sub-organization. Regardless of the size or scope of the organization that the CMS serves, its purpose is so intertwined with the purpose of the organization that the more integrated it becomes, the more able it is to serve the goals of the organization.

A CMS becomes integrated into the organization in the following ways:

• It organizes many departments and job types into an overall system.
• It harvests information from throughout the organization.
• It unifies the organization's communications to itself (an intranet site, for example) and the outside world (an Internet site, for example).
• It ties into the organization's existing information management infrastructure.

Quite often, the need for a CMS is felt most acutely by one part of the organization. The group that feels the pain organizes a team to confront the problem. In my travels, I have seen these originating groups:

A business unit (or department) that needs a much fuller Web site than it now has. The business unit has diverse content and core functionality that it needs to bring to its audiences.

The organization's corporate communications or editorial group that finds it cannot keep up with the explosive growth of content that must be created and delivered.

The organization's IT group that needs to unify all of the divergent requests it receives for Web pages into a single, manageable system.

The organization's marketing department that wants to both unify the organization's appearance to the world and better target market segments.

If all goes well, the originating group brings in all other groups and they coalesce into a tight team that serves all the groups' needs. More often than not, however, this does not happen. Rather, the originating group avoids the hassle of dealing with other groups' budgets and politics and decides to go it alone. The result is, at best, inefficiency and redundant efforts. At worst, the result is massive infighting and paralysis while the organization decides who owns the effort.

I have seen organizations waste a tremendous amount of time and effort sorting out ownership of the new function of content management. The problem is that each group has a fair claim to ownership based on the part of the problem that they own. The business unit owns the content, the editorial group owns the management process, the marketing group owns the recipients of the content and the messages they receive, and the IT group owns the computer system that makes it all happen. Any group on its own can only duplicate the expertise already in another group. If a member group does not have the experience or skill to participate, then the group needs to be built up, not avoided.

The deadly forces of bad interpersonal dynamics and poor communication notwithstanding, the solution is obvious. Each group needs to understand the contribution of the others and make the best use of it. If the CMS effort is to remain in a single group, then that group must reach out to the others to be sure they are included. If the effort is to lie outside of any group (a solution I favor), then the purpose of the outside group is to marshal the resources of the other groups toward the goal of easily collected, well-managed, and fully deployed content.

For good or ill, in order to do its job, a CMS must integrate and unify the organization (see Figure 1).

Figure 1: To do its job, a CMS must integrate many of the parts of an organization.

To serve the whole enterprise, the CMS must accept a wide variety of information from a cross-section of the organization. To crunch all of this disparate information into a single system requires that you develop a single editorial approach to the organization's information (preferably with a unified editorial staff). If you are lucky, the organization will embrace this approach and will eventually create information in a unified way. If you are unlucky, you will be converting and reworking content for the indefinite future.

To allow information to flow into the CMS from throughout the organization and then from the CMS out to a variety of delivery platforms requires a unified infrastructure. CMS systems generally assume you will have a unified Web infrastructure for collecting and distributing information. Whatever infrastructure you create may be one of the few that spans the whole organization. If you are lucky, the infrastructure will be embraced and maintained by your existing IT group.

To allow diverse information sources to coexist in the same publications requires that you create a single brand (or small family of related brands) for your organization. Broadly speaking, a CMS must integrate and unify marketing approaches into a single approach with many channels. If you are lucky, your organization will be firmly behind this effort and will see it as a great step forward. If you are unlucky, you will be stuck trying to unify groups that would rather go it alone.

The challenge of a CMS is to be able to unify the organization enough that it is possible to have a single system collect, manage, and publish its information.

Tracking Information Flow In The Organization

All organizations create content. To create a successful CMS, you must be able to separate the content that has value beyond the context in which it was created from the content that serves one specific purpose and does not need to be managed and shared.

It is not uncommon for valuable content never to make it out of local distribution within a small segment of the organization. In order to do its best, the CMS must reach into each area where valuable information exists and tap into it. To reach in and tap, the CMS must be designed to target the right information sources, creators, and accumulators, and easily be used by them even if they have little or no background in the CMS.

In a typical organization, valuable information and functionality is created at all organizational levels, as shown in Figure 2.

Figure 2: Valuable information and functionality (represented by the stars) is created throughout the organization.

After it's created, information can flow within the organization in a number of ways.

Some information is created by an individual, who then passes it on to others higher up in the organization in the form of reports, analyses, presentations, and recommendations. The creator of this sort of information usually thinks of it as meeting a particular deliverable for a particular person, as shown in Figure 3. Often, the creator does not consider her information to be valuable beyond its original purpose (whether or not this is true).

Figure 3: Some information flows upward in the organization.

Other times, an individual creates information and distributes it to her team. Information such as plans, policies, new initiatives, and background is developed to give context to employees, and often this information is not considered by the creator to be generally useful (whether or not this is true), as shown in Figure 4.

Figure 4: Some information flows downward in the organization.

Finally, some information is created by an individual who then distributes it to peers. Information such as discipline-specific analyses, tips and tricks, and training resources is developed and distributed to help people of a certain type do their job more effectively, as shown in Figure 5. Once again, this information often is not considered generally useful but may indeed be.

Figure 5: Some information flows laterally in the organization.

If you begin to notice and then actually chart the creation and flow of information in your organization, you will be able to map out the sources and reservoirs of valuable content in your organization as the first step in harvesting it.

All organizations have systems that capture, store, and give access to data. A CMS rarely replaces these data systems. Rather, it brings the same degree of management to content that the organization is accustomed to applying to data. This is not to say that there is no interaction. Especially in the publication system, there is likely to be significant interaction.

Consider a typical staff management data system. Such a system has data about each employee or member of the organization, including name, ID, address, compensation package, position, and so on. The human resources and administration departments are likely to access the system via a specialized application. You are not likely to want to replace this system with a CMS. You may, however, want to connect the CMS to the system. For example, you might want to create a printed and Web-based company directory. You can base such a directory off the data system as follows: Once a week, software that is part of the CMS repository contacts the employee data system and retrieves data records for new or changed employees. It also retrieves the IDs of any employees that have left the organization. For each new employee, the CMS software adds a work item. The work item tells a CMS collection staff member to go get a picture and a memorable quote for the new people and to add them to the data that has already been retrieved. For employees that have left, the software can automatically delete their information from the CMS repository. To create the Web-based and printed directories, the CMS publication staff creates templates that draw the employee information out of the repository and format it as a set of Web pages and as a book.

In addition to being integrated with other data systems, the CMS itself is an organizational system that requires the same sort of administration and maintenance as other organizational systems. The CMS is one in the overall set of systems that run the organization.

Understanding your information

People will not naturally seek out the CMS and contribute to it. Rather, the CMS team must seek out contributors and go to them. To begin, you must define what makes information valuable to your organization. Some of this valuable information comes from outside the organization (industry news, for example) and some comes from within the organization (case studies, for example). For the information originating inside the organization, you must discover the following:

• Where in the organization is it created?
• What particular people or job descriptions create the information?
• What is its initial purpose?
• To whom is it distributed?
• Are there places (directory locations or file cabinets, for example) where the information naturally collects?
• Are there particular people or job descriptions that collect and save this information out of interest or job function?
• In what formats is it produced?

The main obstacles to harvesting information from the organization are finding it, understanding how to remove it from its original context, and any adverse attitudes in the content creators.

Understanding your functionality

All organizations create and distribute functionality (even if only internally and on paper). Just as the CMS must reach into the organization to tap into the valuable content that exists in the organization, so the CMS must reach into the organization to tap into the valuable functionality (like the functionality that lets someone update their own HR records, or the functionality that allows customers to see their past transactions). And just as with content, you first should learn about your functionality and then plan for its harvest. The main obstacles to harvesting functionality are making it suitable for electronic distribution, tying into existing data management processes, and any adverse attitudes in your programmers and administrators.

Functionality, like content, might exist throughout the organization. To understand the functionality in your organization, you might start with these questions:

• Where in the organization is it created and maintained?
• Is it suitable for being segmented and delivered electronically on a Web site? If not, what would need to be added or changed?
• Who is responsible for programming the functionality? Was it developed in-house or is it part of a commercial package?
• Who is responsible for managing the data behind the functionality?
• Can it be accessed by code executed on a Web server?
• Who is the current audience for this functionality?
• What knowledge or experience is required for someone to use the functionality?
• Is there other functionality to which the functionality is related or on which it depends?

Understanding Organizational Roles

Each of the major groups in your organization has something different to add to a CMS initiative, as the following list indicates:

Business units create the valuable content and functionality that the organization must deliver. These groups are, or should be, designed to produce important information effectively.

Editorial teams should aim toward creating unified content across the organization.

Marketing teams should create a definitive audience analysis and unified messaging in all publications.

The IT group should implement and maintain the CMS infrastructure and, possibly, be responsible for functionality.

Business units generate value

The valuable content and functionality that the organization delivers comes from business units. These groups are, or should be, designed to produce important information effectively. In addition, business functionality (ordering, getting support, making deals, and so on) originates and terminates in a business group. Business units should rightly be expected to create the value that the organization needs to deliver.

On the other hand, business units should not necessarily be expected to know how to gather, target, or deliver this value. Often, the valuable information the unit produces remains lodged on some individual's computer and never sees wide distribution. In addition, much of the valuable information is produced for an internal audience. Product specifications, for example, are extremely valuable information that is often inaccessible to the outside world because of their style or format.

Editorial teams unify content

All organizations create some sort of written communication. Organizations employ technical writers to create product documentation, marketing writers to create brochures and press releases, and subject matter experts to create white papers and other background documents. Beyond these writers (and other content producers, such as graphic artists) is a group of editors who ensure that the output of the various writers is aligned and consistent. Consistency is the currency of content management. Without a strictly consistent approach to content structuring and tagging, the CMS cannot manage or publish content effectively. If your organization has editors, they should mediate between the business units and the central repository. Editors within the business units forge consistency within the content of the units. Editors outside any business unit forge consistency among all of the organization's content. When you implement a CMS, these two types of editors should form a common understanding and a common set of rules to make the editorial processes flow smoothly between the business units and the larger CMS effort.

On the other hand, editorial organizations rarely have been called upon to perform the very granular metadata tagging needed by a CMS. Thus, editorial skills in the organization must be augmented by the "metatorial" skills needed to develop and apply the level of metadata consistency needed by a CMS.

Marketing teams direct and unify publications

An organization's marketing group is responsible for understanding and controlling the way the organization presents itself to the outside world. Two of the main ways that marketers present the organization is through brand and messaging. The brand is the identity of the organization. It is a set of traits and associations that encompass how the organization wants to be seen by the world. Messaging consists of the small set of clear messages that the organization wants to deliver to the world (for example, "we are the place for information on the third world," or "buy our cars and you will have lots of admirers"). Because of this responsibility, the marketing group is often in control of all the organization's communication, including its Web site and other publications. What the marketing group brings to these publications is clear, directed communication about who the organization is and what they most want the world to know. In terms of content management, the marketing group has an even more central role - they know the audiences. The marketing group knows what kind of people the organization is trying to serve and what they want. This is the key knowledge that enables the organization to identify and target valuable content and functionality.

On the other hand, the marketing group often knows little about the technology and process behind designing and building a CMS. The analysis and development skills needed to create a CMS are often beyond the desire and ability of a marketing group.

IT groups build and maintain infrastructure

An organization's IT group keeps the computer hardware and software running and performing. Because a CMS is a set of interlocking software and hardware components, the role of the IT group is clear - to install and administer the system. In addition, the IT group has the knowledge and experience (or should have) to integrate the CMS into the array of other organizational systems (catalog and staff data systems, for example) that the CMS needs in order to provide content and, especially, functionality. In one sense, the CMS is just another enterprise information system and can be maintained by the same group and in the same way that other systems are.

On the other hand, just as you would not ask an IT professional to enter invoices into the organization's accounts receivable system, so you would not ask her to create content or publications. The natural place for the IT group is not in the content but in the system behind the content.

The groups I have discussed, as well as others, are not candidates for sole and exclusive ownership of the CMS. They are integral players in the overall success of the CMS effort and each has a different contribution.

Exploring Organizational Models

For simplicity, I present content management systems as single systems. Although it is surely most efficient to have a single system throughout the organization, it is by no means mandatory. If a single, monolithic CMS represents too much of a hurdle too soon for your organization, you can create a more or less loosely coupled system of relatively independent but interacting systems.

It's never a good idea to force a CMS on the organization. You are too much in need of the organization's active and creative participation ever to risk that sort of alienation. Rather, you need to figure out how the CMS can bring value to the groups it will encompass. You need to be clearly convinced that the CMS brings value to a group greater than the cost they will bear. Then you can present your case to the group and hope for the best. Be prepared for groups not to be convinced immediately. They may have a lot of personal and financial investment in the way they do things now. Think as objectively as possible. Is the problem that they just don't want to change? Is it that you have not presented your case well? Or do you just not have a compelling case?

For any of these reasons, you may need to fall back to a looser connection between the CMS and a particular group. There are a number of ways to loosen the connection.

Collection variations

On the collection side, the "normal" way to proceed is by having contributors submit content directly to the central CMS repository (see Figure 6).

Figure 6: The usual collection mode

It is not always possible, however, to immediately encompass every group's collection process. Suppose that a group is already creating a set of print publications that you will not soon be able to duplicate with your CMS. Still, you need the content in those print publications for the Web site that the CMS will produce. Rather than taking on a task you know you can't do, or worse, forcing them to "dumb-down" their publications so you can create them, you can get the group to behave like a syndication source, as shown in Figure 7.

Figure 7: You can treat other groups in your organization as syndication sources.

Your main task in this scenario is to get the other group to begin to think of its own system as a CMS. If they can figure out how to separate their own content from its publications, they can figure out how to give clean input to your CMS. Even if they never fully automate their process, you still will have accomplished two major tasks:

• The group will be on the road to becoming fully part of the CMS. As they get better at separating their content from their own publications, they will make their own compromises in their publications, and be learning the art of CM along the way.
• You will get a good content source without having to participate in its creation. Given that you can get the group to give you good stuff (valid XML, for example), you will have all you need to easily incorporate their content in your repository.

What you lose in this approach is time and control of the master source. You probably will not receive content from this group until it has already been released in their publications. In addition, can you be sure that they will not make significant changes to the content after they deliver it to you?

Publishing variations

On the publishing side, the usual way to proceed is to have the CMS create all of the publications, as illustrated in Figure 8.

Figure 8: The usual case, where the CMS creates all publications

But it is not always practical or advisable to have the CMS control all publications. Suppose that you have a group that has already set up a dynamic Web presence with a set of content databases and a complete Web infrastructure. Rather than migrating them to the CMS publication system and Web platform, you can simply fill their databases full of content from your repository (see Figure 9).

Figure 9: Using the tools you have for syndication, you can fill a Web database with content.

Using this method, you can embrace all of the collection and management of content destined for the site without disrupting the site itself. In effect, you are syndicating content to the Web database. Although this may require some programming on your part, it will probably be a lot less work than re-creating the entire site from your CMS.

Of course, you may want to re-create some of the site. For example, maybe the site design is out of line with the other publications you are creating, or maybe the site really should include other content that it is not currently set up to handle. In this case, you may want to consider having the CMS produce not only data for the site, but also some of its page templates and even some of its pages (see Figure 10).

Figure 10: In addition to syndicating data, you can supply page templates and even complete pages to an external system.

This scenario is a bit tricky. To produce page templates for an existing Web site, you have to know a lot about the code and conventions of that site. In effect, your CMS would be managing much of the publishing of the external site. To produce pages, you have to make sure that they fit into the site. Both the look and feel as well as the navigation must match the way the site is constructed. Of course, if you are producing templates for the site, both of these variables are already in your control.

Finally, you can simply treat any system external to the CMS as a syndication target, as shown in Figure 11.

Figure 11: You can always just syndicate to an external system.

The external system controls its own publications and may have other content that you do not control.

Management variations

In all of the collection and publishing variations I mentioned, the only thing that was absolutely under the control of the CMS was the central repository. Even in the case of the external collection system syndicating to the CMS, the central repository can contain the definitive content to be shared by the organization. If you back off this, and the definitive content to be shared is in two or more places, you are biting off some problems.

It is not so much that you shouldn't have more than one database, but that you shouldn't have more than one content structure and access methodology. Regardless of how many physical databases you have, if you have a single organizational structure and unified access methods, then you have a single repository. On the other hand, if you do not have a single organizational structure and unified access, even if you have all of your content in a single database, you do not have a single repository.

That said, if you can manage to have a single database for all your content, you will spare yourself the unenviable task of distributed data management. At the very least, you must have a single place where you can tell people to go to get the blessed version of a particular kind of content.

Optimally, you want to create a central repository that really unifies your content and content access.

To function as a central repository, your system must extend the following qualities over all of your content:

Unified content structure. The way content is chunked and tagged (your components and their elements) needs to be standardized across all data sources.

Unified organization. The hierarchies and other organizational schemes you use to categorize and get to your content need to extend to any place where the content is stored.

Unified access. The way you query and make use of the content you retrieve needs to be the same across all data sources.

My best advice concerning management variations is to try not to vary too much. The headaches you will have - trying to keep track of what content is in what structure, organization, and access system - will be unending. You will also inevitably find yourself in a position of not being able to get to the content you need in a publication or particular page.

-- Bob Boiko
bob@metatorial.com