Send this Page to a Friend

Printer-Friendly Format

9.5 Secrets For Managing DITA XML Migration

How much change is too much? Asks Don Bridges of DCL.

Just as the Personal Computer in the 1980s and the World Wide Web in the 1990s revolutionized the way we process information, XML may yet turn out to be the technical innovation of this decade. But XML implementation doesn't exist in a vacuum; there are a number of other innovations and projects vying for your attention at the same time. How XML is leveraged and how much you do at one time can be the critical factor in the success of an implementation.

This article looks at planning an approach that meets your corporate requirements, while you traverse through an XML construction zone.

"...there has been a change in the past year - the real world implementation of content reuse as a major part of the ROI calculation."

Nobody ever changes data formats just for the sake of change. If it is not making money or saving money, it is probably not happening. We’ve addressed some of these issues in the past (see http://www.dclab.com/businessxml.asp for a basic primer on the business drivers of XML), and these ideas are still valid. But there has been a change in the past year - the real world implementation of content reuse as a major part of the ROI calculation.

So what is content reuse?

Single source publishing was touted as a prime benefit of XML. This means having your information in a single repository and delivering information to multiple delivery devices (including the web, print, CDs, and PDAs) by automated processes. A further extension of the concept is maintaining content granules that you only need to edit and maintain once, but the changes take effect in multiple places and in multiple versions throughout your publications. We’ve addressed some of these issues in the past (see http://www.dclab.com/content_reuse.asp for a basic primer on the value of content reuse), and, again, these ideas remain valid. But why now? Because there has been significant maturation in the tools and technology to implement reuse. And DITA may get the most credit in the Technical Documentation community because it is an open standard that embraces reuse through the use of CONREFs.

Jumping from theory to the real world

So you have done the research and have an empirical feel that XML solves some of your real problems. And there are other convergent technologies that may be worthwhile to attack - or at least to plan for - at the same time. How do you define an approach that is practical and realistic? Once you have done the all important homework, we feel the elements below are the ones that will prove critical to your success:

1. Get Smart.

Learn the basics of XML and DITA before you start. Talk to peers. Attend conferences. Ask those that have traveled the path before you. In the end it will be your reputation at stake, so you'll want to separate the golden nuggets from the mud and silt. It takes knowledge to do that.

2. Set expectations accurately.

Every level of the organization should be aware of the pros and cons of an XML implementation (at a level of detail that matches their involvement with the project). Mistake #1 is to oversell XML as a technology that is easy to implement and solves all of your problems - just to get the project approved. The truth is, it is NOT easy and it won’t solve all of your problems.

3. Incorporate the technology that addresses your requirements.

If a benefit does not address an issue you are facing, it is not relevant. As simple as it sounds, too many people forget that the requirements should drive the solution (instead of the solution driving the requirements). The RonCo Veg-O-Matic, for example, was able to offer wonderful Julian fries, but when was the last time you really craved Julian fries?

4. Get the users involved in the decision and implementation process.

Ultimately the writers and illustrators are the people that will embrace the solution or sink it. So why not get them involved early? It is your job to paint a vision and provide direction, but the users can help you differentiate the possible from the impossible. And they are much more likely to support and endure a system (and approach) that they helped define.

5. Get IT involved early.

Just as the users need to buy in to the plan, implementing XML with all the related technologies will require support from many parts of your organization - not least your Information Technologies group. Make sure you get them involved early in the process.

6. Understand and manage internal resistance to change.

Learning new processes and methods is painful. Using XML is significantly different to using a word processing format (like Word or Interleaf). One of the biggest changes is that with separation of formatting from content, all those formatting issues, such as which font or paragraph indentation to use, have left the building. With XML “12 Point Times New Roman”, for example, is no longer part of the writer’s vocabulary (it is still relevant, but is now part of style sheet development). And for more than one writer, this is a hard concept to swallow and impossible to embrace. Here is where understanding the work force and training become a critical part of the successful process.

7. Get cleaned up.

1. Harmonize similar content to leverage reuse. DITA Topics that express the same concept with different words (even a single different word or punctuation mark) are considered different topics. Perform a manual or automated audit to have as much reusable content as possible.
   
   
2. Fix legacy content that is 'DITA Unfriendly'. Examples are: NOTES created as tables, more than two levels of steps, and Tasks/Procedure authored as tables. It's usually easier to fix these before migrating to DITA.

8. Be sure your processes are scalable.

Sure you can hand craft a solution that works for a small data set, but is this the same process you would use for your regular migration process? Always check for utilities and processes that will allow bulk automated processing of documentation to keep you out of a manual process.

9. Divide the project into manageable steps.

1. Proof of concept pilots. These allow you to test and refine the system and/or processes on the side. You can understand what you are getting into before you commit time, money, and resources to implementation. And you will be able to demonstrate results up-front.
   
   
2. Manage the workload. Writers and illustrators will go through a culture shock during an XML implementation. Their work universe is changing. Besides their regular workload, they have the added burden of learning new software and methodologies. The load becomes even heavier if data clean-up or data harmonization get added to the requirements.

9.5. Easy does it.

Part of dividing your project into manageable steps may include technology phases. In working through projects with our customers, the migration plan often utilizes a “Divide and Conquer” approach: (1) Normalize on XML initially for one set of information; (2) Implement reuse as a second phase. While this is typically a more expensive approach, it does offer the advantage of a more controlled implementation.

Don Bridges, DCL
September 18, 2007

>>>Read more on implemeting XML

The Business Case for XML
http://www.dclab.com/businessxml.asp

Content Reuse, The Killer App
http://www.dclab.com/content_reuse.asp

Send this Page to a Friend

Printer-Friendly Format