Centralizing metadata, content and assets: Paradise Lost and Regained

Posted by Christopher Hill on Feb 23, 2011 5:46:00 PM

I've been working in content management for more than ten years, and thinking back over that time I realized that the dream of a true, standards-based, central repository for all of an organization's assets I naïvely espoused in the late 90s still hasn't become a reality except in the most narrow of applications. When I used to write and teach XML classes I was sure that open markup standards were going to revolutionize the way we created and managed assets. Around 2003 I started to become a bit disillusioned with my vision for content utopia. By 2008 I had all but thrown in the towel. Despite herculean efforts content kept worming its way into proprietary, tactical-level production systems and often was never seen nor heard from again, a victim of legacy of "fire and forget" publishing approaches common prior to the rise of the Internet.

 

Fortunately, just as I had resigned myself to living in a world of content silos, new strategic ways of managing content started to emerge that rekindled my ideals. The idea is more modest than my grandiose vision of pure standards I once embraced, but offers a new, more practical approach that can survive in the real world.

 

Rather than insist that every asset be centralized in a consistent, preferably open, format practicality may dictate that we instead work to build a centralized asset repository that shares common representations for all assets. The actual bits and bytes making up the asset (Word documents, InDesign files, photos, videos, etc.) can still be developed and stored in traditional systems where applicable, but a new system takes on the responsibility of cataloging relevant features and details about the asset in a centralized repository. So instead of insisting that every asset be physically managed in a central repository, we instead insist on the much more modest - and realistic - demand that all assets make relevant, common data and metadata available in a consistent format through a centralized system. This distinction means that rather than try to replace the tactical systems we use to create, manage or distribute content we instead develop a parallel, complementary content management strategy that reflects data in these systems and presents a common, consistent view of the asset regardless of type. 

 

So an image file may exist as a TIFF or PSD formatted file in a production system or on some hard drive somewhere, but the centralized repository maintains a record for this image with all of its relevant metadata and a standard image format readily accessible to any system (i.e. PNG, JPG in thumbnail and applicable preview formats). For a lot of applications, centralized lighter-weight representations of content is enough to create new products without returning to . For example, if I want to rapidly re-use images or stories on a new microsite, I don't have to resort to tracking down all of the content in its silos, but instead rely on these common representations to collect the assets together and send them into my Web CMS for the new microsite. Formats, conversions, and so forth can either be provided to the central system through traditional manual conversion or, preferably, through automated mechanisms built in to existing content workflows.

 

This sort of approach was attempted using search technologies at one time, but lacked an important ability to offer the depth of content management required to not just find the asset but also to be able to use and transform it. It gave us the ability to view the content but not any tools to do anything once we saw it. Search remains important, but a real central repository needs to actually have usable representations of content that can be managed, transformed and distributed as assets on their own. This requires a full content management system.

 

So my new vision of a centralized asset repository is not the end-all be-all "do everything" system that becomes impossible to design and build, it's a "do-some-things" central system that maintains some consistent, common format that can be readily transformed and transmitted and becomes an organization's strategic content reserve. It can answer questions like "what assets do we have about Egypt?" quickly, and serve as a baseline for those assets so that after finding them they can be used in our various tactical systems.

 

To build such a thing, consistent representations are needed. When looking for data standards we of course start with XML. When only a binary will do, ensuring that pointers are accurately maintained to the original assets and appropriate renditions of the binaries are created for things like the user interface of the central repository is an obviously useful model. Even if re-work is required the assets are already under active management. 

 

The RSuite Content Management System happens to be a great foundation for building shared, managed centralize repositories of content. The system is flexible, built on an XML standard database with a metadata model that can not only leverage existing metadata but also be extended in arbitrary ways to adapt to evolving requirements. It is built on open standards and is a good corporate citizen, ready to interoperate with existing systems. The native XML database and pointer management features ensure that consistent representations are available. This approach creates a solid foundation for a strategic, centralized asset repository. 

 

Part of my role as Product Manager for Really Strategies will be to focus on the ways that our existing clients have adopted XML-based content management. I'll be reporting in with our client success stories at building these content repositories here on the blog. 

 

Does your organization have a vision for managing content strategically? It’d be great hearing how others are working to address this challenge.

Topics: content management for publishers, publishing, CMS, best practices, XML, metadata

Metadata lessons from Google Books

Posted by Lisa Bos on Feb 15, 2011 9:24:00 AM

This Salon interview with Geoffrey Nunberg about Google Books' unfortunate use of metadata is fascinating as an illustration of why a publisher implementing a CMS should focus as much (maybe more) on metadata as on anything else. Bad metadata leads to all sorts of problems, and unfortunately it's a self-reinforcing problem - bad leads to worse as users repeat mistakes, act on inaccurate search results, and ultimately come to distrust the system. By "focus on metadata" I mean publishers implementing CMS should take care in:

  • modeling metadata
  • the creation of controlled lists and taxonomies
  • the design of automated and manual tools for assigning metadata
  • the development of automated validation tools to ensure quality
  • the development of search that leverages metadata
  • user interface design to make metadata easily visible in various contexts (browse, edit, search results, ...) to encourage consistent usage and metadata correction/entry whenever it's convenient to the user

Here's Nunberg's original article in the Chronicle of Higher Education from August 2009 and a related blog post. This topic is obviously fascinating at face value as well - as it relates to the usefulness of Google Books for different usages by different users with different expectations. The comments to Nunberg's article/blog posts illustrate effectively that smart, well-intentioned people strongly disagree on the value of metadata or of particular types of metadata as compared to the benefits of "simply" making content available through fulltext search. This basic disagreement often shows up during design projects for RSuite CMS implementation. Leaders within a publisher need to reach agreement about which metadata will truly be of value internally and to readers and about which types of usage are most important to support. They also need to determine the cost/benefit ratio (metadata is often relatively expensive to do right). If they can't reach such agreements, then it's also unlikely they will consistently and usefully build and leverage tools for metadata in the first place - thus leading to a self-fulfilling prophecy on the part of the fulltext-instead-of-metadata advocates.

Of course, there's also a role here for the technology vendor like Really Strategies - we need to make it as easy as possible for publishers to take the steps on the bulleted list at the top of this post, so that the human effort required to make metadata really valuable is also really efficient.

Topics: content management, publishing, metadata, Google Books

Top 5 Reasons CMS Projects Fail at Publishers

Posted by Barry Bealer on Feb 7, 2011 12:01:00 PM

RSuite - Content management for publishersAll of us have been involved at one point or another in our careers with that “death project” that just seems to lack any real conclusion and no one seems to know how or why it is in the state of limbo.  Vendors who serve the publishing industry have many reasons why a project is in jeopardy or has failed altogether including lack of proper resources, no project management discipline,  etc.   From a vendor’s perspective there are some telltale signs that were evident from the very beginning of the project but everyone overlooked them in the excitement of project kickoff.  Following are my top 5 reasons (from a vendor perspective) on why CMS projects fail at publishers:

  1. Solution/Technology was not the right fit – Almost no one will admit to selecting the wrong solution or technology.  We all know that buying technology is sometimes a mystery.  Some vendors are really good at selling a vision only to have the publisher realize in the middle of the project that reaching that vision is going to cost three times more than they budgeted.  In other cases publishers already have a preferred technology or product and force that product on all groups.  On more than one occasion we were told point blank by a larger publisher that we love your RSuite technology but corporate is forcing us to use Documentum because we bought a site license.  Economically that makes sense. But functionally this may be trying to shoehorn a technology that was built to manage documents into a publishing environment that requires content management.  Different requirements, different solution required.  It is that simple.  It is no surpise when we hear back from the publisher 9 months later that the project failed or the system is not being used because the system does not meet expectations.
  2. Buying a vision that is unattainable – Publishers get excited by vendor demos.  And they should!  What they are seeing in a demo is something they generally don’t have in place.  Some vendors are outstanding at selling a vision by demonstrating slick end-user applications.  The problem with this is that a publisher needs to ask the question “how much is it going to cost me to reach that vision?”  Seeing a technology vendor show really cool functionality does not mean there is a good business or production model behind it.  It is good to see demonstrations that push the envelope, but understand what it will take to implement such a vision (time, money, and business model changes).  I have seen several publishers purchase certain technology to build really cool end user applications only to have the technology sitting around because the vision was not attainable to begin with because it just cost way more than they could ever budget.  Investing in a vision is fine, just be able to break that vision down into logical, cost-effective projects.  Be realistic about what you would like to accomplish and what you can actually accomplish.
  3. Poor project budgeting – Along with vague requirements goes poor budgeting.  If you went to a home builder and said "I want a two story house built, give me a quote." How much confidence would you have in the quote you would receive back when the requirements for the house were so vague?  Well, from a vendor’s perspective, we get this level of vague requirements for a CMS on a regular basis and are expected to provide a budget to implement the software.  It is generally couched with “we are only looking for a ballpark.”  OK, great, but if you are looking for a ballpark price that you would have a low level of confidence in, why are you putting that ballpark price into your next fiscal years’ budget?  Immediately you are putting the project at risk.  Again, vague requirements will lead to ballpark estimates that can be misconstrued in budgets. There can be pressure on the vendor to implement a solution based on an unrealistic budget.  Because the system does not operate according to some vague vision there is a real risk of project failure and unhappy customers.  See the chain of events?
  4. Inherent conflict between IT and editorial  – My colleague, Lisa Bos, wrote several years back in one of our website newsletters that software development and editorial processes are in direct conflict with one another.  Think about it.  Software developers are used to an environment where they work up to the very last minute making changes on the fly and moving the system to production with an acceptable level of bugs.  The software is never 100%, but it is operational.  On the other hand, the editorial team has a defined process to complete edits on a deadline with the goal of 100% accuracy.  This inherent conflict between these operational approaches comes out during a CMS project implementation.  Understanding the cultural differences between the two organizations is important.
  5. No definition of CMS project success – Why do publishers implement CMSs?  There are many reasons of course, but how often are the goals of the CMS project discussed: during the budget cycle, RFP stage, kickoff only, never?  If you hold a CMS project kickoff meeting and ask the group the definition of success when the system is operational and no one in the room knows the answer, you have a problem.  How can a CMS project be successful if the project team does not know the measurement of success?  Installing a CMS is not a success criteria.  Managing XML better is not a measurable goal.   Re-using X% of content in new derivative products, or reducing time-to-market by X days are real, measurable success criteria.  One exercise I like to do at the project kickoff meeting is to make the team draft a press release announcing the completion of the project.  After the team gets over the silliness of the initial request, most teams have fun with the exercise and actually contribute to the writing of the press release.  This simple exercise allows the team to verbally communicate among peers what their interpretation of success is for the project.  If you cannot articulate the definition of project success for the CMS project from the outset, you may be in trouble of ever meeting expectations of management.  Know the success criteria, communicate the success criteria, and celebrate the success with your team.
There are many reasons that CMS projects fail, but over the past decade these five are top of mind.  You will not be able to avoid all of them, but recognizing an issue early on and addressing it will benefit you in the long run and make everyone happier because of the ultimate success your team will achieve.

Topics: content management for publishers, content management, CMS, project management, best practices, CMS project, Content Mangement Project Team, CMS Teams

Really Strategies Announces RSuite Cloud

Posted by Barry Bealer on Feb 1, 2011 1:10:00 PM

"Push-Button Publishing System” for Print, Web, and eBook Production in 70 Languages

rsuite cloud 200wWe are pleased to announce the availability of RSuite Cloud - a complete end-to-end hosted editorial and production system for book publishers.  If you are looking to shorten your book production time to market, want to publish to multiple channels (print, HTML, eBook) at once, and publish in 70 different languages, I suggest you take a look for yourself.  Online demo here.

Here is what one of our clients said about RSuite Cloud:

“We saw the time to produce PDF proofs drop from a week to just a few minutes. This improvement in productivity allowed us to dramatically shorten our production cycle and even recognize revenue in 2010 for a book that was originally scheduled for 2011," stated Stephen Driver, vice president of production services, Rowman & Littlefield Publishing Group. “We are excited about our ability to scale with this solution and the new scheduling flexibility that we could never have dreamed of in our old environment."

Topics: content management for publishers, content management, ebooks, CMS, CMS project, XML

Comment below