Managing Enterprise Content

Scott Abel writes: "If you are even considering a content management system for your organization, you owe it to yourself to read Managing Enterprise Content. The book is perhaps even more important to those of you who find yourselves in the midst of a content-management nightmare today." The goals here include saving money, time and effort in creating and using information (everything from Web content to help-desk troubleshooting scripts), and the book is not only suited to corporate environments -- read on for the rest of Scott's review. Managing Enterprise Content: A Unified Content Strategy author Ann Rockley, with Pamela Kostur and Steve Manning pages 592 publisher New Riders Publishing rating 10 reviewer Scott Abel ISBN 0735713065 summary Provides the concepts, strategies, guidelines, processes, and technological options that will prepare enterprise content managers and authors to meet the increasing demands of creating, managing, and distributing content.

The authors, Ann Rockley, Pamela Kostur, and Steve Manning, make the case for their "Unified Content Strategy" -- a practical and logical way of researching, planning, preparing, testing, implementing and selling content management across an enterprise. The lessons contained in this easy-to-read volume are not lost on smaller organizations, however; departments, small work groups, even individuals, will also benefit from learning innovative ways to effectively create, use and manage content.

The author's main message is that a well-planned "unified content strategy" can provide a dramatic improvement in the way content is created in an organization. A "Unified Content Strategy" is defined as "a repeatable method of identifying all content requirements up front, creating consistently structured content for reuse, managing that content in a definitive source, and assembling content on demand to meet your customers' needs." According to the authors, improvements that result from implementing such a strategy include "increased quality and consistency and long-term reduced time and costs for development and maintenance. In addition, reuse provides support for rapid re-configuration of your content to meet changing needs."

Of particular importance, the authors provide guidance on selecting a strategy before you get started; they explain their Unified Content Strategy, the importance of single sourcing (write it once, use it often), and how a properly planned content management initiative can help your organization deliver the right content to the right people at the right time in the format they desire. The authors also cover topics including: information modeling (the key to content reuse), content analysis, usability, IT and Business partnerships, metadata strategies, the importance of XML, tool selection, change management, training and more.

Section one of the book includes three chapters that address content creation, content reuse, and the return on investment a Unified Content Strategy can provide content-laden organizations. The authors set the stage for the introduction of their methods in Chapter One, "The Basis of a Unified Content Strategy," by illustrating the demons involved in what they call, "The Content Silo Trap" -- a common situation in which content is created by authors working in isolation from one anther, oftentimes re-creating the same types of content over and over again for different purposes (e.g. print, web, online help, marketing collateral, call center/help desk, computer-based training, etc.) The authors say content silos negatively impact the bottom line of any organization because they don't promote collaboration, leverage existing content creation activities, nor do they support the overall goals of the enterprise. Far too often, according to the book, silos create inconsistency, inaccuracy, and costly, unnecessary content re-creation expense. By adopting a Unified Content Strategy, organizations can enjoy faster time to market, reduced costs, improved quality and usability of content, improved workplace and customer satisfaction, as well as unique opportunities to innovate. Each of these topics is explored in the chapter with examples sprinkled throughout the book.

Chapter 2 describes, in detail, the "Fundamental Concepts of Reuse." It's an excellent chapter for those attempting to better understand the content their organizations create and how content re-use can help streamline the content creation process. The authors explore why you should re-use content, who's been doing it and why, as well as the two types of content reuse -- opportunistic and systematic -- and the benefits and drawbacks of each. Examples are provided for these methods in addition to a description of circumstances where reuse may not be appropriate. The entire chapter is available for download.

Chapter three, "Assessing a Return on Investment," helps readers determine the anticipated savings realized by adopting a Unified Content Strategy. A discussion of how to quantify and qualify the goals of such an effort are discussed, and information is provided to help you start assessing your actual costs (training, technology, consulting, lost productivity, etc). If you've got to sell your project to upper management and demonstrate potential ROI, this chapter is an excellent starting point. Don't overlook the section on developing metrics -- it's extremely useful.

Section two, "Performing a Substantive Audit: Determining Business Requirements," is a four-chapter compendium of information designed to help you establish where the content pains are in your organization and how you can address them. Chapter four and five help readers identify and understand their "content lifecycle" (to determine where improvements can be made to your existing processes) and chapter six, "Performing a Content Audit," seeks to help readers gain an "intimate understanding" of the nature and structure of the content to be managed. The authors describe how to perform a content audit, and provide several excellent examples of the process using scenarios that many readers will understand (medical devices, consumer electronics, banking institutions, learning materials). Instructions for building a reuse map -- a tool that identifies which content elements are reusable, where reuse would be beneficial, and whether the content would be reused "as is" (identical reuse) or with modification (derivative reuse) -- are provided. This section will not be lost on IT pros who have been using object-oriented programming reuse strategies for years. However, managing content is not the same as managing code. Content appropriate for public consumption has some unique considerations that the authors discuss in detail. Practical examples will help you think through content issues you may not have considered before.

Chapter 7, "Envisioning the Content Lifecycle," examines requirements gathering by using two fictitious companies as examples. A series of tables and explanatory text is provided to help readers better understand how to tie requirements to a return on investment. Readers are encouraged to use the exercise as the basis for designing improvements to your business processes and tool selection. In many organizations, IT departments are ill-equipped to develop solutions that address content lifecycle issues because IT staffers don't fully understand issues affecting content creation, management, publishing, archiving and translation. The authors attempt to shine light on this issue by exploring the importance of involving a team of subject matters experts, users, clients, etc. to help ensure the requirements gathered will help create new and improved business processes. The lesson: There's no sense automating a bad business process.

Section three tackles the issue of design by introducing the concepts of information modeling, metadata, dynamic content, workflow and implementation. Each chapter is jam-packed with real-world information and examples that simplify the concepts presented. Of particular interest is Chapter 8, "Information Modeling," which helps readers understand the significance an information model plays in the formalizing of content structure, and the subsequent creation of DTDs and schemas. As well, Chapter 9, "Designing Metadata," does an excellent job of exploring the role metadata play in labeling, categorizing and describing content, thereby enabling organizations to provide dynamic content to users on demand. This chapter is also available online. Visit "A Metadata Primer" at CMSWatch.

The remainder of the book discusses objectively the tools and technologies you can use to support a Unified Content Strategy. Such familiar topics as Extensible Markup Language, selecting tools, and evaluating vendors are discussed, as well as various authoring, workflow, and delivery systems -- necessary parts of any content management initiative. The book gives equal coverage to collaborative authoring, change management, implementation challenges and transition planning, although the authors admit they aren't able to cover each topic in as much detail as some readers might desire. Readers will need to seek out additional resources for such information. A useful glossary of terms, an extensive bibliography, and several appendices are also provided. Appendix A is a "Checklist for Implementing a Unified Content Strategy"; Appendix B explores the issues affiliated with "Writing for Multiple Media"; Appendix C examines vendors and their products; Appendix D includes a "Tools Checklist"; and Appendix E explores "Content Relationships."

The book could be improved by lengthening some examples, and by providing a few more case studies (although they are admittedly hard to obtain in such a new arena). As well, the book publisher should have abandoned their table structure for one that would better accommodate the information provided. However, providing access to a companion web site is a great idea that will allow the authors to provide additional information to readers when issues arise that are not discussed fully in the book.

Regardless of your particular situation, if you've got an interest in content management, I highly recommend Managing Enterprise Content: A Unified Content Strategy as well as the book's companion web site. The site provides a solid overview of the strategy, a free chapter from the book, a Return on Investment (ROI) calculator, glossary, white papers and more. The content on this site is extremely useful and is indicative of the quality content found in the book.

Scott Abel is a content management strategist who assists his clients in planning and preparing for content management initiatives. Scott is a frequent presenter at industry and professional service seminars, an instructor at Indiana University Purdue University at Indianapolis Community Learning Network, and vice president of the Society for Technical Communication (STC), Hoosier Chapter. You can purchase Managing Enterprise Content: A Unified Content Strategy from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Does it actually matter?

[ites]

Has anyone proven that a well-managed web site actually generates business? I know it sounds obvious, but I don't believe it is. Most business comes from who you know, not what you say, with the exception of large companies selling to the public market. Web sites filled with content, and the tools to manage this content, are possibly (I'm just suggesting this possibility) largely irrelevant.

Fundamentally, managing a web site is going into the publishing business. Not something you should do unless you actually have something to say, and people interested in hearing it.

Re:Does it actually matter?

[HowlinMad]

When they refer to website, they may be reffering to the company's intranet, which can be very useful. Where I work, the intranet has tons of useful information. From HR stuff to general comany facts. It has articles on common computer problems and solutions used throughout the company, things like that. The website can just be internal and help the workers do thier job, which should make the ocmpany more money.

Re:Does it actually matter?

[neomac]

With the few exceptions of web sites that charge for viewing content, content management of a web site is implemented to reduce the costs associated with web site management, rather than generate revenue from it. It's also a preventitive measure for duplicating the same content, which takes up space as well as takes time to redo it over and over.

Having content in some sort of database makes it easier to script search engines for results. Also, if you ever get to the point where you can sell or syndicate your content, it makes delivery that much easier.

Yes, having a CMS for a web site is a lot like publishing.

Based on what?

[Ars-Fartsica]

I would like to know where the authors are pulling this stuff. Most of the content management software out there is complete crap. My advice is to keep files in CVS and use simple tools (make, perl scripts, simple web UIs) to manage authoring and distribution. XML is nice but the reality is that very few of your users know how to use it correctly. For better or for worse it is probably more expedient to store HTML or text files until the tools mature and XML becomes better understood by the rank and file.

Re:Based on what?

[smitty45]

your advice works when you're talking about managing a website, but Content Management needs to be able to work anywhere.

cvs, makefiles, and perl can't do it for a daily newspaper, weekly syndicated catalog company, or ad agency who needs to have stock photography categorized and in-sync with newsletters.

a lot of people assume that "content management" is nothing but a way to keep a website up to date, which is like saying engines are only used for mowing lawns.

Re:Based on what?

[DavidpFitz]

For better or for worse it is probably more expedient to store HTML or text files until the tools mature and XML becomes better understood by the rank and file.

What makes you think content providers for web sites are capable of writing HTML, or even using Dreamweaver? Don't you think they might try to format the page if using plain text... and if they are using plain text how on earth do you seperate a title from a paragraph, or use italics or bold? I know, you make them write something around the title to make it be a title... something along the lines of a title tag? -- Looks oddly like XML :)

Seriously, though -- when managing large amounts of content, structured data is the way to go... whether it is stored in an RDBMS or XML. Either way, the content writer should not know what they are doing (technically)... a very simple word processor tool can given to them where they can define what their content looks like.

Re:Based on what?

[BFKrew]

From my limited experience, I've found that trusting users with HTML is just a total pain. Granted I was working with people who had no HTML experience but were entering content via a WYSIWYG type interface.

You will get everything from wrong fonts, colours, line breaks and your entire site/intranet will look a mess.

And when it starts to hit you is when your boss says that it doesn't work on a big clients browser (they still use Netscape 4) and that sales want to access the intranet on their PDA's. Using HTML here will just not work.

XML is no 'silver bullet' and I certainly agree that educating 'non web savvy' users to use XML is just doesn't work in real life. They break it, can't figure out why they break it and what happens is the site doesn't get updated but if you write your tools carefully and choose the appropriate software, XML will allow you to use XSL amongst other technologies to get your site working great on IE, Opera, Konqueror, PDA's - whatever.

Once a site gets to a certain stage, simple tools aren't that powerful and you will usually find that managers don't like simple looking UI's - they want Javascripts, Flash, you name it. If your site is being used to promote your company it -needs- to look good.

Re:Based on what?

[smitty45]

You can find problems with every CMS product, but the REAL problem is not with the technical details.

which database, perl or python, web-centric, XML or not...these are technical issues that CAN be worked out, and are basically irrelevent.

for example, from reading your post, it seems as if one requirement you have is the ability to scale with users and size of content. that can be fixed, althought I'm sure you're finding it difficult so far.

what is *MORE* difficult to fix is getting a CMS to work in an intuitive and efficient way for a particular organization.

before the web, there were CMS products, except they were specific to each industry (print, photography, audio/video production, etc.) -- to think that a postgres/php/apache setup is going to be able to address the content flow/management issues of all those industries would be very naive.

I believe that organizations that need CMS tools need to pick one (or build one) that is as specific and custom as possible.

Some thoughts on Engineering Enterprise Management

[Real World Stuff]

One of the best ways to increase the odds of success on a project is to use prototyping. For me, the biggest argument for prototyping is that you really don't know what you need to build until the users can look at something that allows them to visualize how they are going to use it and tell you, "That's exactly what I need" or more likely "No, it won't work that way, it needs to do this." There is a belief within many organizations that through focus groups and the development of use cases and detailed requirements specifications, you can determine exactly what you need to build, built it, and roll out the perfect system. I've not seen it happen and, frankly, I don't think it's possible. I've seen this type of implementation labeled as a success. However, that's usually not the opinion of the people who have to live with and use the application every day. They have to change how they do their work because when they finally "saw" how the new system worked they had signed off on the design. Through their acceptance they now have to live with what was built. I'm not against focus groups, use cases, or detailed specs. They are key components of building systems right, but if we don't add the piece that provides true validation of those components, we devalue their use. People think in images. If we don't help them see the future with a prototype, they may not see it. Actually doing the work with a prototype enables people who will be doing the work to actually see their future. It is in this process where the greatest discoveries are often made. This can draw out ideas that will make your process sing - isn't that what you were looking to do in the first place? Here are some important reasons why I see prototyping as a necessary component for project success.

1. Creativity. Prototyping encourages creative development by both the developers and the users. Like brainstorming, once team members begin traveling down a path, the possibilities of what they can come up with are practically limitless. Creativity is an area of a person's work that can make that person's job much more satisfying. 2. True evaluation by system users. Watching the application in action is the only way that most people can truly evaluate it. Due to the limit of items the human mind can hold in their conscious mind, people cannot see all the components of the complex systems we are documenting. People only see the potential problems when they see the entire process and they are only going to exert a limited amount of effort in reading about a system being considered. 3. Find problems and possibilities early on. As we've learn through the years, the most costly problems are those that go undetected the longest. The earliest we find something, the less our cost. That's a core component of TQM-Total Quality Management: find the costliest errors early. A prototype allows you to develop an application with only the resources (cost) that make it verifiable so that it can be reviewed by those with the right domain knowledge to either correct errors that are identified or uncover additional opportunities that were previously not considered. Successfully blend solid strategic thinking and tactics- spend the correct amount of effort up front to ensure you are building the right solution before you spend the big dollars to build it right.

Yes, folks do raise some valid concerns about prototyping so let me take a crack at responding to the three that I have heard the most often.

1. "Is it done yet?" (Raised expectations). When users see something that looks real, there is a belief that it must be just about ready to use. The best way to handle this is to make sure that everyone is aware of the process so that when you remind them that there is still plenty to do, they are not totally shocked and are somewhat accepting of that idea. If they are told up front how things will progress and the benefits of doing things this way, they tend to be all for it. Keep them aware of all progress -- even the parts that they can't see -- with regular sta

It's about time someone wrote a book on this...

[smitty45]

Most books/discussions involving content management these days are too focused on the technical details of particular CMS solutions, and of course everybody has their own opinion. The fact is, most CMS products (open source or not) only have value if it's done along with educating users and evaluating the specific ways people are using content. Most people think of dynamic websites when they think of content management, but there are MANY organizations that use/need solutions that can't just be solved with your runofthemill PHP/MySql/Apache. it's just not as simple as that. How about daily newspapers ? Weekly magazines ? Technical journals ? Catalog producers, Creative departments in ad agencies, stock photography libraries....the list can go on and on. One of the largest mistake of implementing a CMS is a perspective problem. You can't allow the flow of content in an organization to be dictated by the software only. There needs to be an understanding of how content flows in order for a CMS to work correctly. Otherwise, you might as well not even have a CMS.

Re:CMS in one book?

[smitty45]

no, but I think the aim of this book is to provide a methodology of practice and understanding your users from a content perspective, which is often overlooked. unfortunately, a lot of organizations often just lean on the technical merits of a particular CMS software solution with no regard to the users who will use it to control content flow.

Tools are the key.

[DrWhizBang]

In our company, we have a terrible problem with content management - most of it caused by a reliance on you-know-who's office suite for documents. I have proosed several times that we migrate to XML (preferably docbook) but the reality is there are no tools for the no-technical types to create documents.

What we need a warm-fuzzy WYSIaWYG editor that can looks like a word processor but uses XML as it's native format so that documents can be diffed and transformed easily. There are lots of word processors, and lots of XML editors, but no word processors for XML. (and please, before you mention OpenOffice.org, bear in mind that it's DOC format it zipped XML, and therefore not diffable.)

The tools are close - you can almost use OpenOffice.org for docbook, or someone could develop the tools to diff and transfrom their current format, but until then we are stuck with proprietary formats (making books like the above necessary, i guess).

Re:One Word...

[kahei]

Well, I've known some Vignette places and they were NOT happy with it. It seems to be more of a very very very complex database front end than an actual CMS. I think they locked in a bunch of customers early on and are now gradually losing them.

Now, if only it was so easy to dismiss WebSphere...

Re:One Word...

[mbadolato]

Funny, but noooooo. Vignette is about the biggest pile of shit software out there.

I had the displeasure of working with it when I worked for quepasa.com (remember this?) Not only was it unbelievably expensive, it was horribly broken. Built-in commands would literally stop working one day. As in, pieces of the production site (that hadn't been touched in weeks) would suddenly not work. As an example, one day the DATE_FORMAT command broke. It was off by one. You could roll dates back a few days with it and it would be fine. Once you incremented up to the current day, it would go off by one from then on.

There was literally NOTHING about the system that we couldn't have done in Perl of PHP for a lot cheaper, a lot faster, and 1000% better performance. What a waste that was.

And their tech support was horrendous.

Re:You don't understand the scope of the problem

[Anonymous Coward]

Have a look at documentum:

http://www.documentum.com

They have document management backed by a relational database to hold the metadata. Includes workflow, signoffs and query language. Yes it also does web site management(a "small" but still growing part of the content management picture). Mr. Chef will still be printing the menu for many years to come. Now can I get that menu on my PDA via 802... :) Oh and drop me an email when chef makes baked alaska!

Yes, it matters esp. for tech support

[joelparker]

Has anyone proven that a well-managed web site actually generates business?

Yes, I have. It substantial pay-offs
in enterprise technical support.

We found this at Sun, when we improved re-use
among our enterprise call center tech support
our QA, and our marketing release notes.

For example, we improved consistency among
what our marketing website claims as features,
what our customers actually try to do with it,
what QA finds as potential issues or bug fixes,
and what tech support can tell the customer.

This is *enormously* important in the enterprise,
because it gives everyone consistent understanding.

We made our support calls easier,
gave our customers better feedback,
found deployment issues much faster,
and made our marketing more realistic.

Cheers, Joel

Re:POSTNUKE!!

[lukegalea1234]

That's true.. but we feel that there is a substantial market that are too small to benefit from a complete workflow management system. The problem with most systems out there is that they target those with extremely complicated workflows and extreme amounts of content while neglecting those who merely lack the technical expertise to manage their own content.

I think there ought to be a classification to distinguish between these two forms of content management.