The cost of DITA specialization
One of the greatest benefits of using DITA is specialization. However, specialized DITA is more challenging and expensive to implement than standard, out-of-the-box DITA, which is something you should consider before you take the plunge.
In this follow-up post to Making metadata in DITA work for you and Tips for developing a taxonomy in DITA, you’ll learn about the cost of specialization, and how to decide whether it’s worthwhile for your business.
Know what’s involved
You’ve determined that DITA is the best solution for your company’s content, but now you have a choice to make—whether or not to specialize. Specialization means customizing the existing structure of DITA by adding, modifying, or removing elements to suit your needs.
The first step in your decision should be learning about what’s involved in the specialization process. If you specialize, you will need to:
- Create a content model, or framework that shows how your content will be structured in DITA.
- Develop the specialization, including custom DTDs, elements, and attributes.
- Test the specialization with your content.
- Make sure that your conversion process, output transforms, and tools work with your specialization (or modify them accordingly).
Implementing a DITA specialization will cost more—in terms of both time and expense—than standard DITA. Make sure you account for the added effort of specialization, especially if you’re on a tight schedule or budget.
Analyze your content
The structure of your content can help give you an idea of whether or not specialization is the best option for you. As you review your existing content, ask yourself:
- How is your content structured? Keep in mind that even if your content is currently stored in an unstructured format, it probably still has an implied structure.
- How closely does your content match the structure of standard DITA? If your content fits within standard DITA except for a few cases, it will likely be more cost-effective to rewrite those pieces of content than to create a specialization to handle them. However, if your structure differs significantly from standard DITA, you can probably make a strong case for specialization.
- How consistent is your content? It can be tempting to use specialization to accommodate an inconsistent structure with numerous edge cases. But just because you can create specialized DITA doesn’t mean you should—especially if reworking your content to be more consistent is cheaper than specializing around it.
- What semantic value does your content need? Can you assist your content creators by using element names that are more meaningful to them? If you’re in an industry with very specific language, such as pharmaceuticals, or if your company has a large, complex system of product names and categories, it might make sense to specialize—particularly when it comes to metadata.
- How will your content be tracked? Do you or your audience need to search for and extract specific pieces of content (for example, a list of supplies from a datasheet for a certain product)? If so, creating a specialization that allows for semantic tagging might be the best (or only) way to accomplish this.
Estimate the costs
You’ve determined that your company could benefit from specialization based on the structure of your content. Now you’ll need to evaluate the costs involved in specialization so that you can present a strong business case for it. Here are some costs that could occur when you implement a DITA specialization:
- Development costs. Do you have people in your organization who have the DITA knowledge and skill it takes to create your specialization? If so, you’ll need to account for their time and effort in your budget, especially if they already have other responsibilities. If not, you’ll need to reach out to an external resource (such as a consultant) or try to hire someone.
- Conversion costs. Do you have legacy content that you plan to convert to DITA? How much? If you have enough content that you’ll be using a conversion vendor, ask them to estimate how much it will cost to convert your content using your specialization.
- Output costs. What types of output will you need? How will your specialization affect the development of your output transforms? Depending on the nature of your specialization, your transforms may be more difficult or time-consuming to create than they would be with standard DITA.
- Tool costs. What kind of support do the content management systems and authoring tools you’re considering have for your specialization? How difficult will it be to manage and update the specialization once your content is integrated? These factors can not only help you estimate the costs, but can also help you choose the right tools.
- Localization costs. Do you need to translate your content into other languages? If so, keep in mind that the tool chain for any localization vendors you use must support your specialization, which could affect both vendor selection and implementation costs.
- Testing costs. You’ll need to test your specialization at various stages throughout the implementation process, so make sure to allow for the cost of the time involved.
Specialization isn’t cheap or easy, and the decision to implement it shouldn’t be taken lightly. However, if it’s the best approach for your content, the costs involved are probably worthwhile. Now that you have a better understanding of the factors and costs of DITA specialization, you can make a more informed decision about whether or not to specialize—and support that decision with a stronger business case.
Larry Kunz
Thanks, Gretyl. This is a good, factual summary of the things to consider when deciding whether to specialize.
It seems to me that one barrier to specialization is the need to collaborate. Documents that I develop using a specialization won’t be interchangeable with documents from other parts of the organization or from other organizations (which comes into play in the event of a merger or a business-partner arrangement). Do you see this as a barrier as well? Would it be worth pointing out that the DITA community has been developing specializations, like learning & training, that might meet a client’s needs without shutting the door to collaboration?
Gretyl Kinsey
Thanks for your comment, Larry. When it comes to collaboration, if one group in an organization needs to use specialized content from other groups (or other organizations), they can do so by integrating the custom DTDs and/or processing that define those specializations. (Not quite as straightforward as sharing non-specialized DITA content, but still possible.) You bring up a good point about DITA community specializations like learning & training—these can be especially helpful if they are a good fit for organizations that need something more than standard, out-of-the-box DITA, but don’t have the time or budget to create specializations of their own.
Leigh White
Very valuable post. In-house knowledge can’t be stressed enough. If a doc team develops specializations or hires a consultant to do so, and is using a CMS, they’ll need to understand that the CMS support team, while very knowledgeable about “standard” DITA, has less knowledge of the specialization than the doc team or consultant. There’s always going to be that additional layer in the support process of determining if a problem lies in the CMS, in the specialized content, or in the specialization architecture. The doc team must have the in-house knowledge to do some basic triage and participate knowledgeably in the troubleshooting process or have an ongoing maintenance agreement with the consultant for that participation. Full disclosure: I work for a CMS vendor and am entangled in just this situation right now. Frustration all around.
Gretyl Kinsey
Thank you, Leigh. It’s great to hear about DITA specialization from the CMS vendor side. Your comment shows how complicated assessing and ensuring compatibility between a CMS and a specialization can be. The process doesn’t just end at making sure the CMS will support the specialization—it also involves ongoing testing and support during and after implementation.