The politics of DITA
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?
Data interchange
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.
Technology risk
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.
About the author
techwriterkai
Glad to see some German coverage on your blog, Sarah! 🙂
I can confirm that European tech comm scenarios are prone to the NIH syndrome, along with its evil twin SCR (“special content requirements” – to coin a new moniker). One cheeky way around this is to draft a custom content model which is a subset of DITA. You get to be special and don’t have to deal with the DITA idiosyncrasies you don’t need (or understand). And you haven’t burned any future bridges…
Thanks for pointing out the issues with DITA to exchange data. It’s surely plausible enough that most companies would choose the first scenario, but I had never considered it!
Oh, btw: Your post is missing a closing /ul tag before the h2 of “The lure of custom XML” – the unaligned bullet indentation gave it away… 🙂
Sarah O'Keefe
Funny you should mention hiding the custom model in a DITA specialization. I’ve been looking at doing exactly that for a joint German-U.S. project!
(and I fixed the closing ul, thanks!)
Walter Hanig
Nice article. What’s not considered in the assessment of custom XML is the cost (time, money) of hiring and training. DITA is DITA, at least in theory. So, DITA experience an employee has with company A is transferable to company B. Not so much true when the experience is based on custom XML.
I don’t know that DITA is especially valuable for data interchange. I think the value for data interchange comes from XML. Sure, DITA eliminates the transformation step/cost.
The Bus Problem is also known as the Winning Lottery problem 😉
Sarah O'Keefe
Hi Walter, This is also a good point. The counterargument I hear is that “our XYZ content is so specialized that we’ll never find people that have subject matter expertise *and* know DITA. If we have to choose, we pick subject matter knowledge over DITA knowledge.”
Marie-Louise Flacke
IMHO our German colleagues are reluctant to implement DITA because:
– they spent so much time and energy to learn and apply “Funktionsdesign” so that they don’t want to learn anything new
– they spend so much time including all sorts of warning signs and messages in their documentation that they have no time left to think about “task – concept – reference”
BTW, I once met a documentation manager explaining why he did not implement plain DITA : “…because my team members won’t understand what a concept is” (now, which kind of doc’ manager is he if he hires such technical writers???)
@techwriterkai
Uhm, the kind of doc manager who had no say in hiring the writers s/he now manages and can’t very well fire them all? Just guessing, though…
Julio Vazquez
Interesting article, Sarah. I find that some of the arguments are the same sorts of things we encountered when first moving to DITA many years ago from a much larger and complex markup set. Laughably, we got push back and we were simplifying the content model from one designed to support the output structure.
As for the step of going from database to XML to DITA and then out the publishing chain, I’m a little perplexed. One of the first workflows I got involved in after moving to DITA was defining how to go directly from source code to DITA so I would expect that going from a database directly to DITA would not be very difficult. Then it would only be a matter of adding the additional supporting content.
One can always finds reasons not to change current methodologies; it’s more difficult to find good business reasons for change. 😀
Mark Baker
Sarah, I would certainly challenge you on “Their content is special and no mere standard can support it. (This belief is almost always incorrect except for their metadata requirements.)”
It is not so much that the content can’t be supported, in the sense that it can’t be expressed in a generic form. Clearly it can, because that is what generic means. But what a generic form cannot do is support the author guidance, validation, auditing, and content automation (as opposed to publishing automation) that a custom data format can.
But what I feel is missing in most discussions of the benefits of different forms is markup is that they always seem to assume that one form or markup has to be used for all functions within a system. That is, there must be one form that is used for authoring, for publishing, for content management, and for data exchange.
To say that authors must write in a format that is used to directly feed the content management or publishing engine and is also intended directly for data exchange is equivalent to saying that when we use the ATM, we should write directly into the tables of the bank’s accounts database. That is both too difficult and to insecure to be reliable and effective.
The beauty of structured semantic markup is that is to so easy to transform programmatically from one form to another. We can give each author an input format that is suited particularly for them (just as the teller and the loan officer in the bank have a different interface to your accounts than you do through online banking of the ATM) and then transform that into a common format for publishing, and into whatever format is desired for any particular exchange.
As long as we try to have a single format that is used for authoring, publishing, content management, and exchange, it will at best be really good at only one of these things, and probably be not very good at any of them.