Deciding on a content model is a critical step in many of our projects. Should it be DITA or something else? The answer, it seems, often has more to do with our client’s corporate culture than with actual technical requirements.
DITA adoption in Germany
Adoption of DITA in the German market is much lower than in the North American market. Some interesting factors are at play here:
- A lot of German tech comm is heavy machinery, which is governed by the European Union’s machinery directive. A lot of North American tech comm is software, which is governed by, well, nothing.
- Many German companies standardized their tech comm efforts a long time ago and view DITA as a half-baked newbie.
- The German market is full of (relatively) inexpensive content management systems, most of which use proprietary content models. CMS evaluation in Germany is often driven by workflow and not content models.
- There is at least a touch of Not Invented Here syndrome.
- Overall, German tech comm is more concerned than North American tech comm about localization and less concerned about non-PDF deliverables.
The lure of custom XML
Building a custom content model is appealing to some clients. They are typically found in industries that demand precision (that is, rarely software but rather medical devices or other regulated industries) and have staff with a high degree of technical expertise. The interest in custom XML rests on the following assumptions:
- Their content is special and no mere standard can support it. (This belief is almost always incorrect except for their metadata requirements.)
- Implementing custom XML will make the transition easier for the content creators, who are highly qualified in the subject matter (such as nuclear power plants) that they write about but not comfortable learning new publishing technology.
- Using custom XML makes it possible to clone the existing (implicit) structure onto a content model, thus neatly avoiding change management issues. (Highly unlikely.)
There is also a strong correlation between custom XML advocates and FrameMaker aficionados. The thinking seems to be that a transition from unstructured FrameMaker to structured FrameMaker is easier than moving to a non-FrameMaker XML editor. (As if!) And since structured FrameMaker can happily support custom XML, then why not use it?
DITA is or was billed as a way to exchange content. For data interchange, however, we find that DITA is not compelling. We have worked with several customers who had a data source (usually a database) and needed to extract data, format it, and align it with additional information from elsewhere. There are two basic options to attack this problem:
- Database to XML, XML to publishing tool, integrate with additional content in publishing tool
- Database to XML, XML to DITA, integrate with additional content in DITA, DITA to publishing tool
Most customers chose option 1. The advantages of integration in the DITA layer are not compelling enough to justify the investment required to build the database to DITA configuration system.
This is the outlier case where technical considerations drove the decision.
DITA (and XML) are perceived as much riskier than publishing or help authoring tools. The argument here is “What if Key Technical Person leaves? Nobody else would be able to maintain the DITA system.”
Does DITA offer compelling benefits? If so, why would an organization allow a single person to be the only expert on this technology?
We refer to this as the Bus Problem. The success or failure of your system should never be dependent on a single person. What if that person gets hit by a bus? (Or leaves the organization? Or retires? Or joins the witness protection program??)
If you have only one person who is capable of understanding the intricacies of a DITA implementation and no possibility of hiring or training more people, then you have a serious problem. It’s not just a DITA problem, though.