Yes, the cost model I propose is DITA specific, but I do not mean to imply that DITA is the only solution. There are many reasons to use DITA and just as many to not, depending on your content and publishing requirements. In the use case where you have several products that are similar, you may have a high opportunity for reuse and DITA might make sense. In other use cases DITA (and other XML), may not make sense. The cost to implement may be greater than the savings. So, perform your content audit, understand your content requirements and use this cost model to help you determine is you should make the move to DITA. If DITA doesn’t make sense, there are probably many other wonderful technologies and methodologies that will.

At several conferences I’ve been approached told that my cost model could be used for XML schemas that support content filtering and/or content referencing. True. Change the content elements from DITA to the elements in your schema and update the cost per element. My topic-based cost model is based upon traditional cost models, the cost of a page. So, take this model, customize it to your content or your XML schema and please share your results. I’d love to hear them. As a community, the more we share, the easier it will be to justify the tools and technology we need and prove the business case and value of content management.

That said, having gone through major conversions several times, I can understand where Meg and Marcus are coming from. The cost of moving to a new environment can be very high, and I would argue that simply moving from an unstructured environment to an XML environment with all other elements remaining equal (including, and maybe especially, the level of reuse) will likely not be cost effective.

To make the case, I think you need to consider additional benefits. For example:

1) Additional reuse: does the technology help you reuse more content? Also, how extensive is your current reuse strategy? Many organizations are unknowingly duplicating more information than they think they are, and unstructured formats make that duplication harder to discover.
2) Localization cost: does the technology help you reduce localization costs?
3) Single sourcing: do you need to expand the number of output formats, or can you reduce the cost of producing the ones you already produce.
4) Cost of tools: can you reduce the cost of your tool chain?
5) Productivity: does the technology allow you to reduce the cost of developing and maintaining your content?

Against this, you need to balance the costs that Mark will address in the next part.

In some cases, and Meg and Marcus’s cases may be among them, the balance will remain in favor of unstructured content. However, I suspect that for a significant number of organizations, especially those that are currently not seriously reusing content, XML is the right way to go. I also suspect, but cannot quantify (maybe Mark can consider this in a future article), that the larger your organization and the more content you have, the more you will save with a well-designed XML strategy.

One last thought. While DITA is cool, it is not the only XML game in town, and I believe, as Steve comments, that you can have a good reuse strategy in non-DITA environments.

On the other hand, if you are using that content to output to three different guides, each branded differently (with a different format), then standard Frame is not so effective any more. Applying and reapplying formats in file sets with text insets can be time-consuming to get right. DITA, with the separation of content and format inherent in XML, is definitely more effective in that scenario. For example, I am working on a project where individual topics can be reused in upwards of 6 different guides, each published in multiple formats, plus two different flavors of HTML. DITA is the right solution for us.

I’m someone who has been helping customers for over 20 years to move from proprietary-based systems to standards based systems (DITA, XML, and prior to that SGML). You both make some very valid points, and they represent a theme that I have heard many times during my career.

In fact, the arguments that you make are the exact same ones that I heard from Interleaf users in the late 1980s-early 1990s. Unfortunately, many of the people who stayed with their proprietary/closed Interleaf system ran into a lot of trouble later on when the technology evaporated, customer expectations for delivery formats changed, and they had to completely redo all of their hard work.

This is the biggest concern I have when I hear people praising the virtues of unstructured FrameMaker. I agree that it has proven to be a very effective tool for creating reusable topics that can be shared, and it is quite capable as a publishing system as well. I applaud you for putting the thought into your content structure to be able to leverage FrameMaker’s capabilities to reuse content.

However, the core problem still lies with the fact that you are completely dependent on the technology of a particular vendor in order to accomplish this. If, like Interleaf, the day comes that FrameMaker stops being supported, what will you do?

The single biggest advantage of moving to DITA is that is is an open standard. It is completely independent of any single vendor’s technology. If one product disappears, in theory you can take all of your content and start working (almost) seamlessly with another tool, as long as it supports the same standard. This helps to ensure that all of the thought and work that you put into designing your content to maximize reuse is not lost.

Other advantages come into play as a side benefit of migrating your content to DITA, including:

- Your content is now format-neutral, not proprietary. This greatly simplifies the process of rendering this content to another output format as market needs change. (EPUB or Kindle, anyone?)

- It also greatly simplifies (and lowers the cost of) localization of content into other languages, if this is a requirement for you. FrameMaker files have to be converted to a format that a translator can work with in their translation management system (Trados or whatever). Translation vendors are slowly coming around to the benefits of XML/XLIFF as a superior means to make the localization process more efficient and cost-effective.

- I don’t know what your situations are, but I have seen many technical writers/authors/editor get bogged down in formatting issues, trying to make the page “look” right. This tends to go away once people start authoring in DITA/XML (formatting is done as a post-process at publish time), and it frees the authors to spend more time doing what they do best: write! You can use this extra time to beef up the attributes you are associating with the content (to improve the quality of search/query), as an example.

There are many more that I could list, but these are the main ones.

-Dan

- You can centralize the content that you are reusing so there’s a single source. Makes it easier to manage and find. It also eliminates the problem of reusing the same content from multiple sources which can lead to synchronization problems.

- Architected reuse. You can make a library of reusable content available to all so that reuse isn’t ad hoc. It’s planned for and folks can nominate candidates for reuse when it makes sense to do so.

- Planned correctly, you can target content in a base topic, but have it be product-specific in the final output by having a different resolution at build time. Using the keyref feature of DITA 1.2 makes this even easier to accomplish and extends filtering/reuse possibilities significantly.

- Findability. Because DITA source is XML, it’s easy to build queries that search through content and find places where content is reused or find something that may meet your needs when deciding to reuse content. This is difficult to do with binary files.

- Modularity. Because you’re not designing for a monolith to begin with, you tend to write differently and those differences make reuse easier. There’s no need to rewrite to fit the current context because you’ve already accounted for the fact that the topic, or piece that you’re reusing will be used in multiple contexts and you write that way, which you may not do when writing in a narrative style.

- Metadata. Something that you cannot get in any unstructured environment is the ability to describe the information to a degree that will help you filter information in the final output or allow your user to obtain precisely the information that fits their use case.

One final note. When converting unstructured Frame with text insets to DITA, you wind up with multiple copies of the same content, effectively breaking the reuse scenario. The best way to go from Frame to DITA is to start with structured Frame but that’s not even a guarantee.

How about assuming that I’ve got a fantastic reuse system going with unstructured FrameMaker and text inset usage? In that scenario, what sort of ROI could I expect to achieve after converting to DITA?

thanks.