Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Technology Books Media Book Reviews

Managing Enterprise Content 177

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.

This discussion has been archived. No new comments can be posted.

Managing Enterprise Content

Comments Filter:
  • me (Score:5, Funny)

    by fishybell ( 516991 ) <fishybell@hCOMMAotmail.com minus punct> on Thursday May 22, 2003 @11:01AM (#6015637) Homepage Journal
    I wish I had an important enough job to require my reading of this book.
    • Managing Enterprise Content

      Well, I would be more interested if the title were not so cryptic.
    • Read the book and you'll increase your chances of having a job that would require your reading this book :)
  • by ites ( 600337 ) on Thursday May 22, 2003 @11:04AM (#6015671) Journal
    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.

    • by HowlinMad ( 220943 ) on Thursday May 22, 2003 @11:08AM (#6015704) Homepage Journal
      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.
    • by CausticWindow ( 632215 ) on Thursday May 22, 2003 @11:14AM (#6015760)

      Well, maybe I'm not the archetypal customer, but I do judge companies from their webpages when I'm about to do business with them.

      In my experience, well managed websites usually means well managed business, and better produts or services.

      It would be interesting to see how important this is for a business though. I doubt many people think this way when they're buying stuff. My guess is that it will become more important in the future.

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

      Do you really need to ask that these days? Think about it.

      Imagine, you want to buy, say, a fancy hat. How imagine two companies, one with a big web site with pictures and descriptions of all their fancy hats, and one with a single crappy web page that says "We sell fancy hats" and a phone number. Who would get your business?

      I used have to expound the virtues of web sites to pointy-haired bossed five years ago, but now they most
      • Sometimes the obvious is anything but. A nice website means nothing more than a nice budget for graphics design. Think about the companies you do business with, and I'll bet that the majority of the money you spend goes to people you have either bought from before, or have heard about from someone else.

        I was specifically not thinking about web sites that sell articles, because these are not the ones where content management is an issue. Catalogues are not content. The other counter example is that of w

        • A nice website means nothing more than a nice budget for graphics design.

          No - it seems to me that website usability and graphics design budget are inversely correlated.

          Content management tools do address a real problem, but not one that couldn't be addressed better with CVS and a text editor. But doing that requires your users to learn HTML (or at least use a decent HTML editor).

    • 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 yo
    • here are two examples of really well managed content and really badly managed content.

      Intel's Intranet and Cisco's website.

      Intels intranet is (or at least was when I worked there) extrememly well designed to help you find any corporate info that you were looking for.

      Cisco's website (at least for me) is the ugliest thing I have ever used. although their searches seem to be rather relevant - there is no smooth navigation of the information on their site. IT SUCK ASS.

      now - many of you might disagree - but
      • IMHO, Microsoft's web site also blows chunks out the rear exit. The number of times I tried to find something, downloads, KB articles, whatever, and haven't been able to, I couldn't count. If I was to charge them for the time I waste supporting and using their products, I would be almost as rich as Billy Gates hisself...
    • 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.

    • Mod parent down. The author misses the point completely.

      CMS systems are not just about managing a website. In fact, a CMS system may not even push content to the web.

      The book is NOT about managing websites. It is about managing content at the enterprise level.

      As an example of content, think about Boeing. The have a huge amount of CONTENT (i.e. service documentation, engineering specs, wiring diagrams, etc.) that pertain to a specific jet.

      If you were to look at the printed versions of all this content, I
    • I believe it does matter, especially for businesses. If your website is trying to sell something, then content, presentation, etc. all make a big impression on me and influence my purchasing decision. I won't buy from an online store which has just part names without pictures or descriptions, for instance. If two stores have the same pricing but one of them has a better organized website, then guess who gets my sale.

      A company's website is its face on the internet, and could be seen by many people who woul

    • IIUC, the book isn't just about well managed websites. Content management ramifications are larger issues.

      Consider, the company for which I work has no real CM system in place. So when I'm assisting in preparing a proposal, things like our references and our procedure documentation have to be hunted down throughout many documents, then cut and pasted into the current one. In a CM type world, I could go to the application, select the document pieces, and drop them into a new proposal.

  • Based on what? (Score:1, Insightful)

    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? (Score:4, Informative)

      by nojomofo ( 123944 ) on Thursday May 22, 2003 @11:17AM (#6015790) Homepage
      I agree that most content management software out there is complete crap. But the rest of your advice is really off-base for the sort of people who look to those content management systems. Many organizations who use or need content management have content that non-technical people need to be able to maintain that needs to appear across different media (web, direct mail, multiple web sites, etc). They need to have simple and direct control over where and how the information will appear by checking a few boxes and clicking a few buttons. Simple tools won't support that sort of thing for a large corporation. I don't know of any complex tools that do the job well, but there are some that do some parts of it well.
    • Re:Based on what? (Score:5, Insightful)

      by smitty45 ( 657682 ) on Thursday May 22, 2003 @11:19AM (#6015802)
      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? (Score:3, Insightful)

      by DavidpFitz ( 136265 )

      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

    • Re:Based on what? (Score:5, Insightful)

      by BFKrew ( 650321 ) on Thursday May 22, 2003 @11:20AM (#6015810)
      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.

      • Try Postnuke!! Coupled with Content Express it allows users to create their content using MS word and post it to the site where CSS takes over to provide formatting!

        This allows non-technical users to manage the content.

        We (www.gmmsolutions.com) make a living providing this to companies that don't have the technical expertise to maintain their own sites! Give it a try!
    • Re:Based on what? (Score:1, Interesting)

      by Anonymous Coward
      I deal with CMS systems all day, every day. I develop in and for 4 separate systems: Documentum, Interwoven, Mediasurface, and Microsoft's offering.

      They all suck.

      Of the lot Mediasurface (even though it's least expensive to purchase and maintain) is the best. Meaning, it sucks the least.

      By the time I'm done typing this, someone will have posted "Try this Open Source offering, it's great - I've used it!". No, it's not. It sucks. I've tried every Open Source CMS and they all suck as bad as the proprietary o
      • Re:Based on what? (Score:2, Insightful)

        by smitty45 ( 657682 )
        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
    • I work in the product support department of a pretty big company. In all, we support 100+ applications/systems, developed by a host of other business units. Each business unit creates it's own documentation and come up with their own storage mechanism (custom web site, shared windows folder, etc.) Some of these are in Microsoft word, pdf, and html format. Finding documentation for a particular system when it goes down can be a real nightmare sometimes.

      In short, content management is huge. CVS wit
    • Content Management Software/System covers large spectrum of needs and uses, from big media web sites to corporate interanet to personal content management, Knowledge Management etc. Why? even the "Slashdot" software is basically a Content Management Software, that manages dynamic content in specialised format.So, the authors have pulled the right stuff from this vast, varied and fast emerging field of Content Management System
    • have you ever heard of documentum [documentum.com], livelink [opentext.com], imanage [imanage.com], hummingbird [hummingbird.com]? these are all big players in the ENTERPRISE content management game. i would really like to see you walk into a 3000 user enterprise and say "oh ok, sure, just store all of your documents in CVS. its really great and its free."

      i think that this book looks like a fantastic piece of work. we run our entire knowledge management system on livelink and since it moved from a user base of 30 to 150 people, things have gotten a little out of contro
    • "Most of the content management software out there is complete crap."

      Please define "crap".

      Does that mean only Ubergeeks can use it, so that Newbies are left in the cold? Or does it mean that it is targeted to the Newbie, and is missing the necissary Geek factor?

      Or do you mean "Buggy, crashes all the time" crap?

      Or does it mean that it only runs on _______, and I don't use _________.

      You know, vague terms like "Sucks" "Crap" really don't help anyone do anything better. So instead of making overly general
  • 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
  • I dont think one book can teach how to implement your content management system :)
    Implementing a CMS is an art and can not be learned by reading one book.
    you learn by practice and understanding your user needs. Not by enforcing what the books say on your users.
    • by smitty45 ( 657682 )
      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.
  • by cmburns69 ( 169686 ) on Thursday May 22, 2003 @11:13AM (#6015753) Homepage Journal
    According to this site [evolt.org], content management is needed if you've ever:

    • It takes a month to sign off the site's Terms & Conditions because every time any one of your organisation's lawyers changes a full stop, all the other ones need to sign it off.
    • You realise that your site's visual design isn't working, but it will take a month to wrap a new design around the same words.
    • Your web design agency insists on all content being signed off two months before it goes live... and then transcribes it incorrectly.
      In a parting gesture, the Web publisher you fired replaced photos of board members with sheep.
    • You can't update one section of the site because another section has a major overhaul underway. You can either publish the entire site, with both complete and incomplete updates, or hold until both are completed.
    • You have to work through the night to publish the company's results at market opening time because you don't have a secure area to develop them in advance.
    • You send email promotions about 'upgrading' to Windows2000 to registered Mac users.
    • You're employing an army of skilled web publishers just to update the system requirements of your software.


    So what is content management? At the smaller scope, it would just include the text from your webpage. At its largest scope, it would include your entire intranet, and the policys regarding its use.

    An online Starcraft RPG? Only at [netnexus.com]
    In soviet russia, all your us are belong to base!
    Karma: Redundant
  • by smitty45 ( 657682 ) on Thursday May 22, 2003 @11:16AM (#6015777)
    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.
  • by Ubergrendle ( 531719 ) on Thursday May 22, 2003 @11:16AM (#6015782) Journal
    I am currently the operations manager for an enterprise content management system for a large financial institution. My IT department is currently participating in an assessment, initiated by our business partners, of throwing out our version controlled dynamic webservices portal IN FAVOUR OF HTML. This boggles my mind, and seems completely idiotic, but they're in charge of the $, and they insist that they're not getting 'value' for their content presentation. The problem, as i see it, is that HTML creation is a relatively simple skillset which is easy to predict and easy for the business to understand...you want x # of pages, that takes y amount of time. Arguments like "what about version control?", expotential increase of manual maintenance effort over time, etc are hard to quantify, and my concerns are rejected as "just theory" or "technology trying to make themselves sound important, its not that complicated."

    Granted, this situation is partly the result of internal politics at my corporation, but i think that if the ground work for ROI was done more thoroughly up front during the delivery of this CMS this would not be much of an issue. I for one will buy this book if only to get some insight into industry standard ways of how to caluclate ROI for things like content reuse, publication between channels of delivery, content maintenance costs, etc.

    If anyone has any suggestions on how to manage this situation, or how you've dealt with similar concerns, i'd be open to your thoughts.

    • > out our version controlled dynamic webservices portal IN FAVOUR OF HTML

      Ahhh, so you'll be hiring lots of HTML monkeys soon. Good. :)
      The country needs jobs!
    • Ok (Score:3, Interesting)

      by truffle ( 37924 )
      If they want HTML, and you want version control, why not use CVS to manage changes to HTML documents? If you need search, use htdig.

      Dynamic is a word that is thrown around an awful lot. How is your content system dynamic. Does it change based on who is viewing it? Or do you mean by dynamic someone updates the content via some interface and then it changes. That's not really that different than editing a file. It's not really all that dynamic.

      Without more information, I'm leaning towards HTML. Why don't yo
      • Re:Ok (Score:3, Interesting)

        by Ubergrendle ( 531719 )
        Here's some of the things we use our dynamic front end for:

        - session management for logon to our transaction based web services, and for tracking of user experience and browsing patterns
        - dynamic display of content based on business rules (e.g. if you claim you're a student, or you're a pre-exsiting customer and we KNOW you're a student, we're not going to pre-qualify you for a platinum visa)
        - re-use of content for other channels of publication, like e-mail and wireless
        - repurpose of content for dis
        • My experience so far has been that our clients want these functions, but are unwilling to commit the time or money (or more importantly, discipline!) required to delivery these effectively.

          Of course not. The reality today is that maintaining intranet-pages is about as popular as going to the dentist.
          Why ? You don't get anything out of it, generally because everybody takes it for granted anyway and nobody wants to commit content.
          And your boss will think you don't do any "real work" because you just upda

    • Tough scenario, man. I think you hit it on the head when you said this:

      Granted, this situation is partly the result of internal politics at my corporation, but i think that if the ground work for ROI was done more thoroughly up front during the delivery of this CMS this would not be much of an issue.

      I've seen too many groups go through a six-month-plus evaluation, specification and implementation cycle on a CMS ... only to discover that it doesn't actually do what they wanted it to do and the people tr

  • It's easy (Score:3, Funny)

    by Have Blue ( 616 ) on Thursday May 22, 2003 @11:19AM (#6015800) Homepage
    Managing Enterprise content is simple. Just set the Tivo to record UPN at the right time, then rip the episodes and use a good naming scheme...
  • by rherbert ( 565206 )
    I dunno, it seems like Kirk/Picard/Archer seemed to have a good enough handle on this subject all ready.
  • gave me the impression that this book was meant to help Rick Berman and Brannon Braga with their screenwriting.
  • One Word... (Score:3, Funny)

    by DavidpFitz ( 136265 ) on Thursday May 22, 2003 @11:23AM (#6015832) Homepage Journal
    Vignette. [vignette.com] Seriously, it's the way to go. You know this URL's you see on news sites with lots of commas in them? That's Vignette.

    It's the market leader for a reason.

    • Re:One Word... (Score:3, Interesting)

      by buro9 ( 633210 )
      Then you've obviously never worked with it... they have some incredible salesmen, some bright-eyed but mostly clueless professional services consultants and an over-engineered under-performing product.

      Vignette never delivered on its personalisation promises, and once you've removed that the only thing left going for them is caching.

      It is the caching and cache flushing that enables those big sites to run so well... nothing to do with managing the content at all.

      Purchase some cheap boxes and throw squid on
    • Re:One Word... (Score:3, Insightful)

      by kahei ( 466208 )

      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... (Score:3, Insightful)

      by mbadolato ( 105588 )
      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 [slashdot.org]?) 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 i
    • by Anonymous Coward
      ...I point at you and laugh.

      Vignette's software is a giant, expensive mess that doesn't actually do much of anything. The only working part is the database cache, and that's not exactly rocket science. The rest is all marketing, and unfortunately marketing and engineering don't talk much. The biggest thing Vignette has going for them is the $300m or so in the bank, which has been pretty much the only thing keeping their head above water for the past few years.

      signed,
      a former Vignette employee (quit, no

    • ROFLMAO! Vignette is one of the worst designed solutions on the market. As just one criticism, the complexity of the dependency structure in the caching is out of control making it almost impossible to convert from test to deployment in any sane way.

      I'm currently developing a replacement for a Vignette deployment at my current employer and every time I interact with the Vignette system, I'm reminded of why my employer now has a policy prohibiting any new Vignette projects.

      If you must, use Vignette for p
  • Tools are the key. (Score:5, Insightful)

    by DrWhizBang ( 5333 ) on Thursday May 22, 2003 @11:24AM (#6015840) Homepage Journal
    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).
    • What we need a warm-fuzzy WYSIaWYG editor that can looks like a word processor but uses XML as it's native format

      You should take a look at Arbortext's Epic [arbortext.com]. Looks like it would fit your needs.
    • Start testing Openoffice 1.1 beta. It will save in xml and xhtml.

    • Check out Content Express.. it's exactly what you want! http://pn.arising.net

      It's a module for Postnuke CMS!

      GMM Solutions
      [http://www.gmmsolutions.com]
      CMS Solution Providers.
      • not exactly. I need to something to replace MS Word as the tool of choice for creating tech specs, arch docs, configuration docs, and end user documentation for our software company. All of these are kept in our SCM repository (Borland Starbase, as the case happens to be.)

        I need an editor, not an editor tied to a CMS (and a browser).
      • it's DOC format it zipped XML, and therefore not diffable

      Neat. I didn't know that. I managed to unzip a .sxw file and got the content.xml file. Trivial, but the xml is all on two lines (one for the header, then the rest written as a single, huge string). When you diff something like that you will get nothing useful. I suppose all you would need is to insert newlines before and after each tag to chop the file into diff-able pieces. No need to re-assemble the original files, just diff with copies.

  • 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.
    • There are lots of 'small' content management solutions like Zope, IBuySpy etc but whilst they will work for a 'small' website they just cannot cope when it comes to large (thousands of pages) sites which need full CMS features.

      You need to be able to archive HTML, Word, Excel, PDFs, Images, Videos - the list grows and people want to be able to search through videos etc etc.

      Zope's great but like many posters have said they just don't work for a large organisation which will rely on a good intranet/websi
      • I manage the proprietary site which has gathered so far more than 2 thousands of various documents (pages, images, messages, files, etc). Periodically I have to make a stress testing and it keeps more than 100 simultaniosly requesting users on a pretty regular PC server. It has archiving, backup and even replication (sort of) to the cold-backup (stand-by) site.

        But I already think to migrate it to accept a bigger user base. The key solution that will lets us doing it is ZEO [zope.org] - Zope Enterprise Objects, which

    • Yes, but better still is a Zope-based, CMS framework called "Plone" [plone.org]. You should categorize Zope as an application server, not as a web server or as a CMS proper.
  • by LordYUK ( 552359 ) <jeffwright821.gmail@com> on Thursday May 22, 2003 @11:44AM (#6015995)
    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?!?))
    • Now all I can think about is that damn game that made everyone crazy... No, not Pokemon Super Orange Deluxe Mega version 2.6, the game that you Wesley and that Engineer chick were hitting it off... Damn she was hot... it wasnt every week that the "hot chick" was closer to your age (as a pre-teen) ya know?

      Slips on headset. Imagines putting disk in whirlwind. Has slight Reloaded Orgasm.

      Ahh, weren't mid 90's "State of the Art" Special Effects great?
  • by TedTschopp ( 244839 ) on Thursday May 22, 2003 @11:45AM (#6016000) Homepage
    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
    • It sucks to have a unique last name when tools like Google exist.
    • 50 million? Sounds like you just need a few scripts. I'll do it for $20,000. Seriously

      What's an "Interprise?"
    • by Anonymous Coward

      Have a look at documentum:

      http://www.documentum.com [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!

    • I was involved with a project with these guys... Clarity Content Manager [clarity.ca] Kind of a neat licencing structure too... open source customizable code (not GPL'd though). I think the cafeteria staff could handle using it just fine. Last major project they had was for Terasen [terasen.com]. The Clarity product was used in the pipelines division, while M$ Content Manager was used by the other divisions. The pipelines division had a much easier time of it with respect to workflow of editing and approvals. Saved a wack of $ comp
    • 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.

      We use CVS here and it works a treat. The guys change the web pages using Dreamweaver, then they just look at the Explorer window, see the files they've changed highlighted in red and then right-click and select "Commit" from the menu. Totally
  • by dmorin ( 25609 ) <dmorin@gmail . c om> on Thursday May 22, 2003 @11:48AM (#6016023) Homepage Journal
    I was the lead geek for our web platform for 5 years before the company was bought (we used Documentum, a very expensive commercial product, which exports to XML). The new buyers subjected us to an interminable number of "rebranding" meetings where we figured out what we legally had to change, by when, with respect to the web sites. I thought this exchange was particularly priceless:

    Buyer: All the old logos will need to be identified and changed.
    Guy from our company (on a competing team): We'll have to examine every page on every site to make sure we get them all. I estimate 3 weeks.
    Guy from my team: Or we could go to the Compliance cabinet where those things are kept, find the Logo.gif file, and change it there. I estimate 3 minutes.

    Guy #1: What if not all of the logos came from that cabinet?

    Guy #2: So your people haven't been following the branding guidelines? The ones that are in place for exactly situations like this?

    Guy #1: No, we've been following them.

    Guy #2: Ok then. Next.

    • So did you like Documentum?
      • We used Documentum for years, long before they got into the web publishing business. Our first iteration literally had a production content server and we used a proprietary API to query it dynamically (yikes). It got much better with the introduction of their WebCache product, which was basically a glorified XML-Export tool.

        The product is not, and I dont think ever will be, a purely web content solution. It's intended to enterprise document management. The tools to do that are outstanding. Much better

  • by code_rage ( 130128 ) on Thursday May 22, 2003 @11:48AM (#6016024)
    But no one wants to die.

    (sigh). Yet another book that shows us the Promised Land, but without a guide to get there. If I had a buck for every time I have cursed the lameware cobbled together to manage content on development projects...

    Managers are all in favor of content management, but in my experience they don't have any idea of what that means. They would prefer to pay far more for a system developed in house instead of buying COTS components or systems developed for the very purpose.

    Not that it's all their fault: IT vendors oversold their products' capabilities and ease of use & customization, so many organizations are rightly skeptical.

    Still, books like this perhaps should have a chapter discussing how to motivate the managers to understand the importance of an effective system, and how to close the credibility gap.
  • cms sucks (Score:5, Interesting)

    by Anonymous Coward on Thursday May 22, 2003 @12:02PM (#6016152)
    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.

    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-sharename " 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.

    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.
    • I agree with you more than you can know. Just one point to mention:

      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"

      After 5 years of correcting users, I would probably have changed the instructions users need to follow to say "file > save as > \\servername\sharename\filename.ext." Or maybe map a drive (as part of a standard image) and just tell them what drive letter t

      • After 5 years of correcting users, I would probably have changed the instructions users need to follow to say "file > save as > \\servername\sharename\filename.ext."

        Followed by:

        "Why is filename.ext the only file on our intranet now? Where did everything else go?" :)
    • NTFS supports junction points. I believe on the Windows 2000 Resource Kit (don't ask why it wasn't included with Win2K...) has LINKD on it.

      Junction points are a little better than parsing points, and work very much link symlinks do.

      -----
  • by guacamolefoo ( 577448 ) on Thursday May 22, 2003 @12:24PM (#6016401) Homepage Journal
    I work for a law firm, and we originally had a fantastic content management system: an attorney would have a case and an issue would arise that had been addressed before, and he would go grab the old file (perhaps from a different client) and reuse the forms or follow the procedures from a prior case.

    Since that point, we've evolved it to more of an "electronic" filing cabinet. A networked box holds sanitized example documents by category of law (divorce, custody, personal injury, business formation, wills and probate, etc.). It is more useful than things were before, but it is not ideal. If you do something that is unusual or especially good, you are encouraged to submit it to the file.

    In addition, "how to" documents are created for new or unusual practice areas as guidelines or checklists for various procedures (how to handle a basic will, checklists for complaints, client interview checklists for various types of cases, etc.). None of this eliminates the use of sound judgment or experience, but the documents serve as tools to assist the attorneys -- it is sometimes hard to stay on track or get everything in a client interview that can last for over an hour. The checklists help with that.

    Not everybody contributes to the file repository and there is nobody in charge of vetting the documents to ensure that they are "best of breed" type documents. It does prevent the "reinventing the wheel" problem to some extent, however.

    When I worked for Ernst & Young, they were really pushing to make information retention and reuse a priority. Contributions to the document repository were considered in performance evaluations. The resources were aggressively managed (vetted, categorized, reviewed documents to prevent "staleness") by knowledgable individuals for each practice area and there were a number of groups which were extremely focused on reselling knowledge.

    IT people who can provide this sort of service are going to do well. Service businesses cannot improve margins without making use of technology to improve efficiencies, and content management is a fantastic way to help them get there. Very very few small to medium sized businesses really make use of content management to increase their margins, and this is one area where, even in a bad economy, IT can really help to make a positive contribution to the bottom line.

    GF.
    • Contributions to the document repository were considered in performance evaluations. The resources were aggressively managed (vetted, categorized, reviewed documents to prevent "staleness") by knowledgable individuals for each practice area and there were a number of groups which were extremely focused on reselling knowledge.

      This is good, but its only half the battle. Not only do you have to reward participation in the knowledge management system (contribution, vetting) you have to do it on an equal b
  • by mydigitalself ( 472203 ) on Thursday May 22, 2003 @12:27PM (#6016431)
    After just having returned from two content management conferences in Paris and Leon, I would just like to make a few statements to put a few things in context.

    1. Content management is NOT making web sites. Sure web sites can be built off the back of a content repository (Vignette + Documentum for example). Enterprise Content Management is a blanket term for the storage, management, collaboration, publishing of many forms of content. This content could be, for example in Life Sciences, highly regulated documents outlining manufacturing principles of drugs. Or it could be "How to use the water cooler". One of the many challenges that enterprises face today is how to extract business content from employees brains and make it accessible as such that you don't lose intellectual property when you lose staff.

    2. The XML thing. This is the tricky one. The majority of content today is authored in MS Office. Users of all walks of life author content. Many attempts at WYSIWYG XML editors have failed pretty dismally. The reason being is that users do no like to change the way they work. Two years ago, at the same set of conferences, everyone was talking about authoring in XML. It hasn't happened and it won't. Just plain old Microsoft Word styles are a pain in the butt to use - and thats just marking up style, not context or meta. Try asking a user to describe every paragraph within some form of taxonomy tree. You get blank faces or grimaces.

    Anyway, just some food for thought from, dare I say, the real world!
    • "he reason being is that users do no like to change the way they work."

      And yet they often do. The hard truth is that the users will do what you tell them to because their jobs are on the line. They will bitch and moan but they will either do it or get fired.

      If the comapny has a vision and if the company has a plan which it thinks will make them more competitive then there is no reason to stop that plan because the user don't want to change the way they work.

      It's not up to the users to determine strategic
  • http://www.intranetjournal.com/

    http://www.intranetjournal.com/articles/200305/i j_ 05_21_03a.html

    http://www.intranetjournal.com/articles/200305/i j_ 05_15_03a.html
  • It would appear from the replies I've read that CMS is beyond the needs of the average web developer, used primarily on large organization websites containing thousands of pages and that it seeks to allow large numbers of non-technical users to publish documents on the site.

    Is this an appropriate definition? But then there's also mention of XML content management, which doesn't seem to fit my def. Can somebody explain what this is or how/if this technology can be leveraged by the average web developer? D

    • What's an average web developer to you? 100 pages? 1000 pages?
    • The acronym pretty much sums it up: CMS is a system for managing content. Not necessarily web content, and not necessarily XML. CMSs can be used to store lots of different kinds of content.

      MANAGEMENT
      A content management system is about managing content in a systematic way. If you examine the premise, it implies a set of procedures for handling content (create, edit, view, delete, and more complex procedures built from these basics) in a systematic, structured way. From these advanced procedures arise
  • If I were in charge of Managing the Contents of the Enterprise, I would:
    1. make T'Pol's white catsuit her standard uniform
    2. get Hoshi to let her hair down
    3. Get rid of...

    Oh, wait...
  • That's what I thought the title of the article said at first glance. (Though it describes what I experienced in the past with a poorly-implemented content management system that ended up becoming a glorified file server for sales proposals because most of the employees forgot it was there, didn't trust the technology behind it, or just didn't care.)
  • ...because the problem can't be solved.

    Consider the following level zero problem. You have a server full of files people in your group have produced over the past few years. You want to find out what's in each file.

    Not only is this one of those problems everybody has, but I think it can be shown that if you can't solve this problem, you're out of luck generating any kind of content structure without reinventing your company's knowledge from the ground up.

    As soon as the person who created the file sa

  • by jafac ( 1449 )
    Without mentioning any names, There are actually a TON of solutions out there. And about 1999 lbs. of Garbage. The problem is, many of the systems require a TON of customization work, which when you figure out the costs, in reality, you end up spending about as much as rolling your own would cost. (which is a VERY strong argument for an Open Source solution).

    Just don't get stuck with a bad one. m'kay?

    Do your homework - because every time someone spends money on a bad solution, a bad company stays in b
  • When I first saw "Managing Enterprise Content" I thought it was a story about T'Pols new catsuit! Bummer..

The world will end in 5 minutes. Please log out.

Working...