»
Business Value of DITA - When Does Hierarchy Get in the Way?
Like many of you do, I follow several good Darwin Information Typing Architecture (DITA) blogs, e-mail groups and web sites which discuss the technical merits/issues of the standard. I’d like to use this blog to discuss the business merits and how users justify a migration to DITA from older methods. Also, I’m interested in a discussion around the business factors that drive users to adopt DITA and how they justify this with their management. It always boils down to money and how you get funding for deploying new projects. I’m also interested in discussions regarding an even wider adoption of DITA that could expand its use beyond technical information (marketing? sales?? Who else?).
When meeting with Astoria customers I always ask what pain points are they trying to solve – what is broken with the current process. A primary pain point (but not the only one; others will be discussed in the future) is the ability to keep their documentation configured to match changing or new product configurations. This can be a result of a company merger or combining products not originally designed to work together. The challenge is to create a unified look and feel for your customer that is sourced from content written for a different purpose or by different people.
DITA has emerged as an important new standard for managing technical information. It is shifting the way many of us think about technical information; for years many of us attempted a topic based approach with mixed results. In retrospect, much was asked of technical writers to develop the perfect hierarchy to support a single source approach. DITA has provided a simple and eloquent solution for solving complex content and structure problems by distributing the responsibility for who manages the content or structure. XML provides a nice separation of content and presentation; in the same way DITA topics and topic maps provides a nice separation of content from hierarchy.
DITA is well designed to manage always changing product configurations in combination with minimalist practices for keeping content tightly written. Several years ago the software industry adopted modular code writing; it’s easy to re-combine applications into new bundles. DITA matches that technique by providing much of the same flexibility with topic-oriented authoring and conditional processing. This separation is critical because topics can quickly be re-combined (via topic maps) into new deliverables. This fast re-combination is a dramatic shift because you are no longer burdened by the painful separation of content from its original document structure and hierarchy.
The challenge is to gain business acceptance of this new topic approach and at the same time maintain a clear understanding of what is a customer deliverable – an Adobe PDF, HTML Help, Web content, etc. Success stories I’ve seen are starting to prove this ability to rapidly re-combine topics, and will be a critical success factor for wider acceptance of DITA for managing technical content.
