Slashdot Mirror
Managing Enterprise 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.
I wish I had an important enough job to require my reading of this book.
><));>
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.
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.
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).
Schrodinger's cat is either dead or really pissed off...
Zope (http:/www.zope.org) is object oriented webserver written in Python. It has a lot of content management features right out of the box and for those who want more, there are quite a lot of plug ins (products) that extend this functionality. It is open source, available for all major operating systems and completely configurable from the browser. Recommended for most content management jobs.
I think the first thing you'd have to do is arrange the episodes by ship. I'd probably start with NCC-1701 (no bloody A, B, C, or D) and work my way forward. Then you'd either go by episode, or maybe by how much of a factor ths ship played in the show. Like, it was really important in space battles and what not, or when it had to seperate, but sometimes it was more about the crew. Then I'd take the ones that stunk, like the ones that focued on that little bastard CleverNickN... err, Wesley Crusher and toss them, cause they mostly sucked.
I suppose you could probably catalouge the series based on when the ship blew up, because that happened quite a bit.
(btw, if you're reading this Clever, I don't really think your episodes sucked, except for maybe the last one you were in... I had always kinda hoped you'd come back, but NOOO, you had to go and do some stupid shuttle manuever and kill your bud, and then blame it on his dead body, blowing a WHOLE YEAR at the Academy! And why didnt they ever let you shack up with that hot engineer chick?! Huh?! Huh?!?))
This is my sig. Its pathetic.
I think most people who are responding do not get the scope of the problem in the interprise.
I work for a rather large (unnamed company) which has one of the largest data centers in California (nope not that company, you would be suprised who we are).
In any event our intranet consists of over 150,000 flat HTML pages. We have over 2000 web servers running anything from NT4 to Unix to our Mainfraims hosting web services to get data out of them.
Now look at the problem of having a couple dozen physical locations where employees work. We also have 2 physical mirrors of all our data in 2 different locations.
Now here is the problem. The guy who works in the company cafateria wants to update his webpage which has the menu for what they are selling at the cafateria in building X.
He has no idea on how to use any technical tools, but the man cooks like there is no tomorrow. So don't ask him to wack away at HTML. Do not ask him to use CVS. Do not ask him to start a script. He wants something like a word processor to go in and edit his webpage.
Now this presents another whole new problem. How do the systems administrators know Mr. Chef is allowed in. How do we do rights management accross all our servers. We have everything from Mainframes to desktops, to NT to Windows 2003 to several flavors of *nix.
Now how does the system get back ahold of Mr. Chef when he doesn't update his webpage? There is no use in having information about a cafateria menu which is 2 weeks old? How does the system know that the data is stale, and how do we get Mr. Chef to come back and update his website. There needs to be some type of self governing mechinism.
So I don't think CVS or whatever will solve this problem. Interprise CMS problems are of the non-trivial type. Our company has spent the last year or so studying the problem, and will problably spend another year or so before we actually choose the direction we are going. And to be honest we are probably looking at a $50+ million investment to roll out our CMS system. How's that for non-trivial?
Ted Tschopp
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
I'm in the middle of a content management nightmare. Seems to me the biggest problem with CMS is that once you've simplified something to the level where a target user in your company can use it, another target user is utterly confused. So you try to simplify, simplify more, until you want to strangle them.
e " one more time, I'm going to freak out. And in response to that, if I hear "where do I enter that again?" one more time, I'll kill myself.
CMS is hard when users have been using FrontPage for 5 years and still can't make pages look the way they want. CMS is hard when users create a 375 page document, complete with images and tables, and ask "how can I publish this to our clients via the website? By the way, it's a Word Doc." CMS is hard when, after 5 years, your users don't understand that "save the file to servername sharename" means "file > save as > \\servername\sharename\filename.ext".
How can you create a CMS when all people know how to do is save files into "My Documents", and still manage to lose them?
If I have to say, "that means backslash-backslash-servername-backslash-sharenam
This is the heart of CMS, as I see it. CMS is stringing networking, websites/intranets/extranets, and the ol' File Manager (Explorer) together in a way that is understandable by people who refuse to learn or try to comprehend anything new.
As I've begun using Linux, I've started to see how using symbolic links could simplify things more. I could smbmount, ln -s, and say "if you want to publish that *here*, save it to siteB/filename". The only clarification I'd have to make is "no, you don't have to type anything else, just siteB/filename". Unfortuantely, we're using Windows on the clients and Web Folders and Mapped Drives just don't do the trick.
My advice to anyone who embarks on a CMS project: Don't. In fact, better advice: Kill yourself.