Channels ▼


The DITA Maturity Model

The DITA Maturity Model defines a step-by-step methodology for implementing the Darwin Information Typing Architecture (DITA). Incremental adoption is one of DITA's most attractive features. Users can start quickly and easily with DITA using a subset of its capabilities, then add investment over time as their content strategy evolves and expands to cover more requirements and content areas.

Here the authors of the DITA Maturity Model -- Michael Priestley, lead DITA architect for IBM and co-editor of the OASIS/DITA 1.0, and Amber Swope, principal consultant in Content Lifecycle Solutions at JustSystems -- discuss the genesis of DITA, the stages and the impact of using the DITA Maturity Model, and the path to universal knowledge management. For more information on DITA, see DITA: The Darwin Information Typing Architecture.

Q: Michael, you're one of the original creators of the DITA spec. What was the inspiration behind DITA?

MP: Nothing would do what we wanted! The available tools and technologies didn't support the content we wanted to create and the deliverables we needed to produce from that content. We knew we wanted DITA to address information typing, reuse, and separation of concerns, which let us focus on information architecture and content simultaneously.

We also drew from our experiences 1) dealing with common issues like multiple products that share single sources in different configurations and 2) dealing with similar problems in object oriented programming -- say, how to deal with a variety of different content sources and a variety of different sort of application environments.

All of that led us to the separation of concerns found in DITA -- topics for content, maps for aggregation and information architecture, a common metadata scheme, and a common extension scheme through specialization.

So DITA was very much driven out of our content needs, but also informed out of the skills that we had on the original team which included a mix of XML experts, subject-matter experts, and people with a programming background.

Q: Amber, can you provide a little perspective on being a participant in one of the first commercial implementations of DITA?

AS: I was at Rational Software doing desktop product documentation, and we were trying to single-source to generate our content to run native in different IDEs. We were trying to use HTML as our source, and it was incredibly painful.

We wanted to move to XML, so when IBM purchased Rational, we hunted down the DITA team. We moved to DITA when it was in beta. That was a great experience. We learned a lot about DITA from the inside out. And DITA solved our problems right away. We were able to single-source our information, conditionally process much more quickly. We saw the benefit right out of the box.

Q: Michael, why did you and Amber create the DITA Maturity Model?

MP: One of the key advantages of DITA is its incremental adoption curve. Rather than a traditional, full-on CMS deployment that requires a bunch of up-front design and purchasing, DITA lets you start simple and scale up as go, getting as complex as you want. With DITA, the sophistication is there but it's emergent. You can start playing with it today. So, we wanted to clarify and codify the different levels of DITA adoption.

The other reason had to do with clarity of message. DITA is extremely easy to adopt. It also delivers huge benefits. But if all you do is the minimum and stay simple, then you get relatively little out of it. The huge benefits require more investment. DITA adoption and benefits lie on a continuum, so we wanted to clarify and codify that continuum, too.

Q: Has the market been asking for this sort of structure?

MP: Well, nobody said, "We need a maturity model," but I think they were looking for some clarity. And the maturity model also turned out to be a good way to explain DITA. It lays out the features in a progression of complexity and sophistication, which makes it a good explanatory model as well as a useful adoption model.

Q: Amber, could you give us a brief, high-level introduction to each of the levels in the maturity model?

AS: The first level is topics. Here, you migrate your content from its sources into DITA topics, which let you do simple, single-sourcing -- generating multiple outputs from the same content.

Level 2 is scalable reuse. Now, you have to reorganize your content and make sure that the topics are broken down into individual files that you can easily build and put back together in maps for each of your deliverables. The benefit at level two is flexible reuse.

Level 3 is specialization and customization. At level three, organizations adopt a formal content architecture to improve content quality and consistency.

Level 4 is automation and integration. By this level, companies typically invest in translation and content management solutions to automate the stages of the content lifecycle. In turn, they see speed and efficiency gains across the content lifecycle.

Level 5 is semantics on demand. By using DITA as a service, organizations can integrate content with data to achieve dynamic personalization. This is the entry point for what JustSystems has been advocating as dynamic documents and "the document as application."

Level 6 is universal semantic ecosystem. With a unified content and data strategy, companies can practice universal knowledge management -- content and data are integrated, accurate, and live at all times. We don't believe that anyone is really at Level six yet, but this is where DITA can take the enterprise.

Q: Michael, where would you judge organizations to be today across this continuum?

MP: There's a few at level 1 although most people probably jump in at level 2 or 3 with maps and some specialization and customization. There is a smaller number at level 4.

Level 5 is definitely where IBM is headed. A lot of other organizations have also realized that's where they can go with DITA. The maturity model calls it "semantics on demand." At IBM, they call it "DITA as a common currency." The idea is that once everyone's on the same page - and they all get on that page for different reasons - then you get emergent opportunities for reuse and integration that simply weren't cost effective as a driver before.

I mean, people are not necessarily going to change an entire application infrastructure just to get a better relationship with the guys down the hall. But if they made their own cost-benefit analysis and moved to DITA and a service-oriented architecture for their own needs and wind up getting better integration with the guys down the hall? That is a huge, huge bonus for the enterprise.

So, level 6 will come about naturally as more and more companies move into level 5 and realize that it enables a degree of collaboration across enterprises and across industries. It starts to bring down some of those barriers to collaboration and program share that are built into application infrastructure. It's going to be a little while before we get there. But it's an exciting goal to have in mind.

Q: Amber, what's next for the maturity model? Is this as an organic process? Or is it more or less complete?

AS: It's definitely organic. One of the reasons we wrote the maturity model was to provide a context for people to talk about what they're looking to do. Before, people weren't able to easily articulate what they needed from DITA. As people work with the maturity model, we'll see case studies about their experiences working at and moving to different levels.

As we have more of these discussions in the broader community, we can take that community feedback and input and update the model to be more relevant, with more and better examples. We may even spawn off case studies or other papers that walk through the levels for vertical markets.

The maturity model lets the community talk about DITA in a way that gets everybody using the same vocabulary. We're hoping this document will grow as people adopt the model and show the rest of us how they're moving up through the levels and where they see DITA taking them.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.