Guest post by Casey Jordan. This article originally appeared as a post on the dita-users mailing list. Casey is a DITA evangelist and the co-founder of Jorsek, the creators of the easyDITA content management system: http://easydita.com.\
Update: Check out the comments – it’s an interesting thread.
DITA can be overkill for many applications. However, you also have to remember that DITA is much more than just a way to write content. It’s a philosophy and a standard which puts the user in control. Even if you are not using the full potential of the language, DITA *can* be the ultimate insurance policy on your content’s future.
It would be easy to write a whole book on all the advantages of DITA, so this is tough to fit in a single email. However, in my opinion, DITA really stands out over other methods in two regards: open standards, and native componentization of content. Regardless of how DITA may be implemented, these two things are at the core of its success.
Open standards are very important because technology changes so rapidly. With DITA, you can use your content with many different tools, customize it, move it anywhere you want, and convert it easily to other formats. There are DITA editors which are made for simple easy editing, and editors that expose a range of more powerful development tools. There are also a variety of systems that publish and serve DITA content. All of these tools can co-exist and work together harmoniously because of open standards.
More importantly though, these standards are well controlled, and transparent to the community. So the evolution of the specification can be influenced by all parties involved. Also, change is much easier to predict and address.
The second thing DITA does really well is native componentization of content, meaning DITA’s “baked in” philosophy for writing in small topics. While many tools have similar approaches, few have it so central to its core. And while this makes it easy to re-use content, it has a host of other benefits which are often more important and overlooked. For instance, separate business processes which rely on the same content can work simultaneously without blocking each other. Businesses can reduce the time for a product to reach the market, because they can develop documentation faster. This provides a huge competitive edge. Imagine if you could always release the next version of your product a month earlier than your competitors could.
While it may be hard to start on the road to DITA, the combination of these two features alone:
- Improves employee effectiveness in transferring knowledge. (It can be authored and managed with a host of different tools suited for different user types, on different platforms.)
- Helps business groups work together on the same content more effectively, preventing processes being blocked and reducing the time to completion.
- Can mitigate the risk of change because of transparent open standards.
In the long run, this means fewer headaches, faster time to market, and less money spent.
Thanks, Casey & Keith. This is a very good nutshell summary of “Why DITA”.
Ironically, it also explains why many people go DITA half-way. As does the company I work for: We took the DITA 1.2 specification, threw out all the parts we didn’t need, adopted the rest as our information model and got the tool that suited us best – which turned out to be MadCap Flare (which only imports DITA, but so far doesn’t create or validate it).
This way we believe we get most of the benefits of DITA (esp. compared to our less-than-structured legacy content). And speaking to people at WritersUA 2011, it seems that we’re not the only one to move from less-than-structured writing to XML and close to DITA.
Kal,
That is an interesting approach, and pretty forward thinking.
I have been thinking a lot about “Democratizing DITA” lately, so your process is very intriguing. What is a typical workflow for your team from authoring to publishing? Do you write both DITA and semi-structured content and merge them at publish time? Or does your information model work with MadCap since its a subset of DITA?
Have you discovered that adopting DITA as your information model, but not committing fully to a entire DITA solution has helped smooth out the transition from less-than-structured to DITA from a technology and culture standpoint?
How do you see this evolving in the future?
Thanks for sharing!
-Casey
Thanks, Casey, for your interest.
We’re moving from a collection of unstructured topics to structure with our own brand of “faux DITA” as a “halfway house” for strategic reasons. Going straight all the way to DITA (or a fully structured CMS),
- we couldn’t have gotten management support, mandate or money and
- we would have overtaxed the documentation team culture where more than half of the writers are well versed in business aspects, but not so much in structured writing.
So our explicit goal for the first half was not DITA or structured writing, but task-oriented topic-based authoring. We sold and focused on method and processes to write more consistent documentation more efficiently.
Technically, we’ve defined the DITA elements we need as divs in the Flare stylesheets, but otherwise pretty much use the straight Flare authoring-to-publishing workflow. Flare is agnostic to whether a topic complies with DITA, is somehow structured but not complying or totally unstructured. Which means we currently have no means to automatically validate or enforce the DITA-based information model.
We are committed to writing new topics structured, so they follow the information model, and to cleaning up unstructured legacy topics in a “soft fade”, moving them towards structure one by one.
So we will have been working in Flare and with our home-grown information model for a long while, before all topics actually comply with the model. But THEN we will have a documentation set which we can feasibly move into real structure, whether we opt for DITA or some other XML-based CMS.
There are probably some purists out there that would disagree with you, but personally I think that’s pretty smart.
There are so many organizations that just keep doing things the wrong way, because they perceive change as being too hard. A lot of companies forget that they can only be as agile as their information is. Eventually, change is necessary in order to be more competitive and they are too far behind to catch up.
You have shown a great example of incremental change which has minor short term costs for your organization, but big long term potential. Kudos, I truly hope it pays off.
[...] post is an elaboration of a comment thread on the "Why DITA?" guest post on Keith Soltys' Core Dump 2.0 [...]
[...] post is an elaboration of a comment thread on the "Why DITA?" guest post on Keith Soltys' Core Dump 2.0 [...]