Analyzing The Services Required to Implement a CMS

Posted by Barry Bealer on Mar 10, 2014 7:53:00 AM

CMS Services Analysis resized 600Every so often we get inquiries from our RSuite enterprise clients or prospects about why there are services required to implement our RSuite software if the pre-configured environment is pretty much useful out-of-the-box?  If one digs a little deeper and analyzes exactly what types of services are required, I think a publisher will be surprised that services related to customizing or extending the content management software are actually pretty small.  Sure there will be custom forms for metadata capture or custom search forms, but these are generally a few days worth of work at the most.  On the other hand, services related to content structure and workflow re-engineering have a huge impact on the services required for a content management product implementation independent of the software package chosen.

Content Engineering

Content engineering can be simply defined as understanding the structure of your content and putting a migration plan to make it adhere to some type of standard.  In some cases very large publishers have crafted a proprietary content standard, but many adhere to industry standards such as NLM, D4P, DocBook, etc.  The amount of services required to transform the content from one format to another can vary widely depending on the amount of file formats and complexity of content.  While this effort can be categorized as part of the content management project, it is not part of the content management software.  

Content structure and organization reflects how an organization has worked over time.  If the publisher was disciplined and remained in compliance with industry standards, the amount of services to get the content into the content management system is minimal at best.  Basically, if the publisher has well structured content that adheres to a DTD, then it should just work in RSuite or other systems.  The challenge surfaces when multiple products adhere to different DTD's and then the publisher wants to consolidate under one standard.  Again, a very good idea, but this is an issue beyond the content management software. Or the publisher has no DTD and wants to migrate all of their content to a standard.  Again, an excellent idea, but the effort to complete this should not reflect on the content management software.  As one of our engineers has said, "there is no magic button to transform the content, you either have the discipline to adhere to a standard or it will take some work to transform the content so that it does comply".  There is no simple solution.

Workflow Analysis and Automation

Services related to workflow are generally consultative in nature whereby a business analyst sits with all parties to understand current "as-is" and "to-be" workflows.  In some cases publishers have done a very nice job documenting their current as-is workflows but have a difficult time envisioning the to-be workflows.  This is normal and can generally be addressed by creating some pilot workflows and showing the client how the software will help them.  In some cases though a publisher which has been doing business one way for the past 20-years can have cultural challenges to change to the to-be workflows.  This has been becoming less and less over the past 5-years as the need to embrace multi-channel publishing is critical to the sustainability of the publishing business.  In other words, optimizing workflows, creating efficiencies, and actually automating multi-channel publishing are no longer options.  It does mean in some cases that people within the publishing organization will have to be re-skilled or let go.  That is unfortunately the nature of the game right now for publishers.  Workflow equals efficiency which equals cost reductions which equals a reduction or reallocation of staff or an increase in production throughput.

A publisher that requires significant manual steps (e.g., a person needs to review and approve content) in their workflow will not realize the true benefits of implementing the workflow software.  Manual steps are still required in the editorial process, but minimizing them is key.  An automated step (e.g., content transformation) is the key to gaining the efficiencies that are sought by management.  Depending on the complexity of the automated steps, the amount of services required can vary widely.  The key is automating the highest value steps in the workflow and minimizing the manual steps.  Again, the more a publisher understands how they need to change their process, the less services will be required to implement the content management software.  The software will do whatever you configure it to do, but time spent understanding exactly what a publisher should be doing takes time and requires a visionary within your organization to think outside the box.

The Bottom Line

For both content engineering and workflow related services, the more a publisher is organized in these areas, the less services are required for a content management project independent of whether it is RSuite or not.  The painfulness of addressing years of neglect in a structured or disciplined production of content can require significant services to unwind the structure, business rules, or lack of adherence to standards.  Unfortunately this can be seen as a barrier to implementing a content management system.  

While a new content management system could offer tremendous value in content reuse, version control, and production efficiency, the new software cannot magically address the messiness of the content or undocumented workflow. If your team has been organized and have very structured content with a well documented and agreed upon workflow (even if you are using legacy technology), then services to implement a CMS should be relatively small.  

If you are embarking on a content management initiative, I would highly recommend that you have an honest assessment of your content structure and your workflow.  If these pieces are in order, then you have just increased your odds of a successful content management system implementation and reduced the required services to implement the software.


See RSuite in Action

Topics: content management for publishers, RSuite, content management, DITA for Publishers, CMS, CMS project, Barry Bealer, content conversion

The Disconnect Between Publishers and Adobe

Posted by Ed Murphy on Aug 20, 2013 12:26:00 PM

The Disconnect Between Publishers and Adobe and Where RSuite CMS FitsI was recently reading Dorothy Hoskins' provocative LinkedIn thread on Adobe's embrace of the magazine market at the expense of the educational publishing market and it made me think. So, the options covered in this thread are to work with Adobe by adding requests to their product wish list or have IDPF front an industry request to support merging standards, assuming EDUPUB rather than a better version of ePub is a standard worth sponsoring.

The real question is whether InDesign provides the capability of producing derivative structures that support different standards. It's not looking that way, not now. Maybe production editorial folks in ed publishing houses will embrace other options, like batch pagination systems as an alternative to InDesign. Or use off-shore vendors to force feed *ML through a few manual conversion steps to make ePub files. This push and pull between the making systems like InDesign and the market demands for multiple file formats from a single source puts production and editorial managers in a challenging position.

What's missing from this thread is how Component Content Management Systems (CCMS) fit in, where in the workflow they add value. As a CMS software vendor for some ten years, we at RSI, makers of RSuite CMS, see the movement from IT-based CMS systems, XML repositories with some workflow added, to robust publishing systems supporting a variety of editorial and production workflows.

Enter DITA For Publishers, a standard which RSuite supports which provides the extensibility publishers do and will need to connect editorial, production and the market demands for multiple file formats from a single-source. Click here for our DITA For Publishers White Paper.


Click me

Topics: RSuite CMS, DITA for Publishers, Component Content Management Systems, Adobe

DITA for Practitioners Volume 1: Architecture and Technology

Posted by Marianne Calihanna on Apr 24, 2012 3:18:00 PM

Eliot Kimber | DITA For PractitionersEliot Kimber, senior solutions architect at RSI Content Solutions, spends most of his days helping publishers implement RSuite CMS, proselytizing DITA For Publishers, testing XML-to-EPUB3 conversions, and tending to his brood of hens and rooster. In his spare time he wrote a book: DITA For Practitioners, Volume 1, Architecture and Technology published by XML Press. On behalf of all his co-workers, congratulations Eliot!

Eliot has spent the past 25 years entrenched in generalized markup languages. He was one of the founding members of the XML Working Group, a co-editor of the HyTime standard (with Charles Goldfarb and Steve Newcomb), a long-time member of the XSL-FO working group, and most recently, a founding member of the DITA Technical Committee.
The goal of this book is to provide a detailed look at DITA aimed at engineers, tools builders, and content strategists – anyone who designs, implements, or supports DITA-based systems – as well as experienced DITA authors who want a deeper understanding of the technology they are using.

Click me

Click me


Topics: DITA, CMS for publishers, RSuite CMS, DITA for Publishers, Eliot Kimber

This Changes Everything: Content Management + DITA for Publishers

Posted by Marianne Calihanna on Mar 9, 2012 12:21:00 PM

 DITA for Publishers - content management comes alive

Publishers understand the value of XML but sometimes the cost of entry into an early XML workflow is difficult, expensive, and time consuming. The open source project DITA for Publishers combined with RSuite CMS changes everything.

DITA is a sophisticated XML-based application architecture for authoring, producing, and delivering information. While enthusiastically adopted in the TechDoc world, DITA is less understood among traditional publishing organizations.  Until now. DITA specialist Eliot Kimber and technology evangelist Christopher Hill are hosting a webinar in March that details how RSuite CMS and the open source project, “DITA for Publishers" is  the toolset that launches publishers into the XML world and why this is critical. DITA’s unique extensibility architecture makes it a better business value than any comparable XML alternative. Eliot and Chris' enthusiasm combined with a straight-forward approach to CMS and DITA, will have you starting to take DITA seriously.

Webinar details

Wednesday, March 21, 2012 2:00 PM - 3:00 PM EDT

How Successful Publishers Deliver Content: RSuite CMS & DITA for Publishers

Panelists: Eliot Kimber & Christopher Hill

Click me

Topics: content management, DITA, RSuite CMS, DITA for Publishers

Comment below