Choosing a DITA CMS

DITA CMS Vendors Signpost
Many DITA CMS Vendors, Many Different Potential Paths to Take
(original How to select DITA CMS technology by Ave Maria Mõistlik, from Wikimedia Commons)

One of the projects I have been working on for a while is a list of CMSes that claim in some way to be DITA-capable, done largely because no such list seems to exist elsewhere.

One of the things I have discovered in the process of surveying various CMS marketing materials is that it is a) often opaque, and as a result b) it is hard to nail down equivalent features between products. This makes it much harder for anyone to come up with a list describing what is merely “DITA capable” versus what is “DITA optimized”. All the more reason why anyone seeking to purchase a DITA CMS ought to come to the table with a good idea as to what they are looking for rather than relying solely on the claims of CMS vendors.

Here are my recommendations for the steps in selecting a DITA CMS vendor who best suits your needs. The basic steps are:

  1. Figure out your new Content Strategy
  2. Sort out your “Must Haves” from your “Nice to Haves”
  3. Start researching DITA CMS vendors
  4. Refine your criteria
  5. Request a demonstration
  6. Choose CMS vendor

Here are the detailed explanations for each step in the process:

1. Figure Out Your New Content Strategy

This is your opportunity to improve your existing processes, not simply to fossilize them using new tools. This is a separate-though-related process for any ROI argument for purchasing a DITA-capable CMS in the first place, as your goal is not just to make your technical writing processes more efficient, but to ensure that what you are doing is still relevant to the audience that is reading your content.

This is the stage where it makes sense to work on your Document Architecture, starting off with a content audit to learn what material you have and to figure out how much reusable content you have and how much you plan to migrate to the new CMS. How well do you know your audience? This is the best time to find out – run surveys, talk to your clients, or attend company sales/training functions where you can get first-hand accounts as to how and where your current material is (or is not) being read.

This is also a good time to start thinking about updating your content delivery process. Is there a need to provide more customized content to your customers than you can currently deliver? Maybe you are looking to provide content to readers in an eReader-friendly format, or want better feedback mechanisms on your content. All of this is possible, and whatever you decide is important ought to go into a list of features you are looking for in a DITA-capable Content Management System.

2. Sort out your “Must Haves” from your “Nice to Haves”

Now that you a have a list of features that you are looking for in a DITA CMS, sort out the most important features (the “Must Haves”) from those that you would like but aren’t critical (your “Nice to Haves”).

For example, for ROI purposes you may need a CMS with a mature localization process to reduce translation costs, while it may be “nice” to have a system with workflow processes in place for checking completed work into an edit cycle, but is not a deal-breaker. Another example might be that you require some sort of check-in/check-out mechanism for your content, and it would be a bonus if there were different permission levels available so that some people could only view content while others can actively change it.

It is important to make your criteria as specific as possible. For example you might want a system that works with DITA 1.2, but “DITA 1.2 compliant” is not the same as “optimized for DITA 1.2”. It would be better to specify individual features that are important to you in the DITA 1.2 specification, such as how keys/keyrefs are handled, how metadata schemes work within the system, or any tools that ease your migration from your old documentation toolchain to DITA 1.2.

Put all of this information into spreadsheet and rank all of your “Must Have” and “Nice to have” items in terms of their priority to you.

3. Start Researching DITA CMS Vendors

Once you know what features you are looking for, start researching the available DITA vendors and use your spreadsheet to assess objectively which vendors meet the majority of your “Must Haves”. If you have more than one vendor with the same number of “Must Have” features, rank them by the number of “Nice to Haves” that are present.

In my own researches of the various DITA-compliant CMS vendors out there I can tell you that the information that you find may not fully answer the questions that you have, but this is still a good starting point, and it may help you winnow out some of the lesser players from those that better meet your documentation group’s needs. Drop the vendors from your list that do not meet your critical “Must Haves”.

4. Refine Your Criteria

Come up with more refined criteria to further narrow down which CMS vendors meet your needs. This can involve such factors as cost, the feature set of the CMS, the database type it requires, etc. By this point in the process your research into the DITA-capable CMSes out there may have highlighted some other desirable features which can be added to your spreadsheet.

You also may want to investigate which XML editors you want to use, the extent to which content reuse is supported (e.g. extensive search capabilities, ability to add metadata) and ensuring that the needs of other stakeholders (e.g. SMEs who need MathML capability, IT has specific OS or hardware requirements) are met. With this information in-hand go back online and do further research.

You may find that you need more information than is readily available from a vendor’s website to properly answer whether it meets your specific requirements. If it meets enough of them then go ahead and request further information, which also opens the door to doing an evaluation of the CMS.

5. Request a Demonstration

By now your list of requirements ought to have whittled the number of prospects down to a manageable few. If you have not already done so, get in contact with the CMS vendors who are in the lead and request a demonstration. This is your opportunity to not only see how the CMS works, but whether you and your documentation team can work with it.

If you can, deliberately test the claims made by the CMS vendor. For example, one of the key requirements for a client was that Unicode was enforced through the toolchain, so that whatever character that went in was the same one that came out. This was a “must have” to ensure that the localization part of the toolchain was not prone to corruption and thereby cause expensive problems with their localization vendors. So a DITA topic was created that contained significant chunks of Unicode and we tested each CMS to see if what went in was the same as what came out. We found that at least two of the vendors who claimed full Unicode compatibility failed this test, and were eliminated from further consideration.

Based on the results if there is no clear single winner, request to do a pilot program – with no long-term commitment – with the CMSes that come the closest to fitting your needs. Work through a sample project from beginning to end to see if the CMS lives up to its claims. Define what are your criteria for success is for individual items on your checklist (i.e. relative ease-of-use for a particular feature, whether SMEs were able to contribute content successfully, etc.), and evaluate the outcomes.

6. Choose CMS vendor

While this is the last step in this process, this is also the first step your ongoing relationship with the CMS vendor. If you have not already done so, nail down the costs involved, get an understanding as to how often you can expect software updates, and negotiate the type of support you expect.

If the vendor you chose did not have all of the “Nice to Haves” that you wanted, this is also a good time to ask whether or not any of them could be added to the product. I have run into a few cases now of DITA CMSes that have added new features to their product based on the needs of one client that ended up benefiting their other clients (and the CMS vendor).

There’s more that could be written on this subject, and whole books have been written about it, but this in a nutshell are the steps that are known to work.

A tip of the hat to Paul Wlodarczyk at easyDITA whose article “How to select DITA CMS technology” spurred me to do my own take on the subject.


"DITAWriter" is Keith Schengili-Roberts. I work for IXIASOFT as a DITA Specialist/Information Architect. And I like to write about DITA and the technical writing community. To get ahold of me you can email me at:

View all posts by

7 thoughts on “Choosing a DITA CMS

    1. @Tom and @Ian: you are both welcome! Either later today or tomorrow will post a full listing of CMSes claiming to be DITA-capable, so stay tuned for that!

  1. Hi there. Very useful article. I think number #1 on your list is hugely important for any successful DITA CMS project. Without having a vision/content strategy from the outset, your project isn’t likely to be successful. Thanks for sharing this.

  2. Hello Keith, well done!
    You may add:

    Create a test strategy or a list of scenarios the testers should go through and evaluate the result.

    Make sure the ‘must have’ include enough scalability to support your DITA implementation project as it grows in scope and domains (training & marketing, for example).

  3. Between 5. Request a demo and 6. Choose a vendor, a good practice is to get your hands on a trial version of the software and do a pilot project/Proof of Concept.

    1. Agreed. Most CMS vendors are more than willing to do this, and provide sufficient help so that people can adequately test the system and see whether it meets their needs.

Comments are closed.