Craig: I’ve been helping large enterprises deploy and run a variety of business applications for the past 10 years and for the past 2.5 years have been focused on SaaS type applications. During this time, I’ve seen the nature of these deployments shift from large, highly-customized, in-house projects taking 6-18 months to very quick, flexibly configured deployments completed in a few weeks.

In my role at Astoria, I am responsible for all customer deployments which includes professional services, training, technical support and SaaS Operations. The primary focus of my organization is to ensure that our customers get up and running quickly, make the best possible use of our software and need never worry about the smooth operation of their system.

Chip: Over the years, I imagine you’ve seen your fair share of successful content management projects – as well as a few that weren’t so successful. Of those that were successful, what three things were critical to their success?

Craig: I think the most important success factor for any organization is a good, detailed understanding of the key pain points and business reasons driving the need for a CMS. This will focus all players on the reasons for the change, and it is a change for most involved, because bringing in a CMS will require abandoning some legacy processes, modifying others, and adopting new ways of working. A detailed understanding and communication of these issues can help ensure management’s support for your initiative.

The second important success factor for a CMS implementation is properly scoping and staffing the initial deployment phase. The best approach is usually a small core team that has in-depth understanding of business processes and authority to change them as required. This team should be able to coordinate, communicate, negotiate and drive these changes across all organizations affected. The core team will be responsible for configuring the features and workflow of the CMS plus adapting their company’s processes to best leverage the features of the CMS. The scope of this initial deployment should be small and focused on proper configuration and planning for larger scale rollouts. Subsequent phases can then focus communication and training of the already validated and working CMS.

The third most important success factor is to think beyond just the features of the CMS software and consider the wider aspects of Change Management that the new application is introducing. Most CMS implementations I’ve seen recently are coincident with a more pressing need to realize the benefits of DITA. This shift to structured (topic-based) authoring requires non-trivial changes in writing processes. For example, DITA’s separation of presentation (visual layout) from content may be a big change for authors and somewhat for reviewers who may be used to seeing fully rendered, full documents on each review cycle. DITA’s reuse paradigm focuses first on content-only reviews, with a final visual review done for each form of rendering chosen (web, pdf, hardcopy, etc.).

A Change Management Plan considers these wider aspects of implementing a CMS. Organizations I’ve worked with that address this up front are much quicker in adopting the system and seeing its benefits. Emma Hamer addressed some of these issues in Managing Cultural Changes Triggered By A CMS Project.

Chip: Software companies spend a lot of time talking about critical success factors. They are explained in white papers and webinars (and on blogs like this one). In order to succeed, organizations not only need to know what to do, but they also need to know what NOT to do. In your experience, what are the three biggest mistakes an organization can make when making the move to content management? And, better still, what are the implications of each of those mistakes and how can they be avoided?

Craig: First, don’t go for the big bang implementation in one go-round. More specifically, tying the deployment too closely to major production deliverables may catalyze a sense of urgency to get the system running, but this most often leads to sacrifices and shortcuts in the configuration and change management plan that actually slow down adoption and realization of benefits. Instead, start with a smaller project that exercises the full scope of the system and its processes. Apply Project Management resources to keep on track. Refine your work processes, develop training and rollout plans during this phase, then roll the system out to a reasonably sized group or team. Lather, rinse, repeat.

Second, don’t insist that the CMS automate everything and match your existing processes. This will lead to costly customizations of the software and limit its adoption. Having a broader perspective on Change Management as I mentioned before will help avoid this pitfall. Bringing in a CMS and DITA is a recognition that processes must adapt and change. The best approach is a balance of CMS configuration settings plus adapted work processed that get your system running in the minimum amount of time.

Third, don’t forget to “sweat the details” during the configuration and initial deployment phase. Spend the time to exercise the key CMS workflows and processes fully to make sure they integrate effectively with other external work processes and organizations. Conversely, don’t ‘sweat too many details’ by trying to detail out every possible process. Just focus on the ones that are important to your needs.

Chip: Experts I’ve interviewed previously have pointed out that cultural and organizational factors can impede content management projects because they introduce changes that are, to say the least, challenging for some organizations. That’s definitely true. But, I don’t think there’s enough attention being paid to the changes content management creates for content contributors. The one that comes immediately to mind is the importance of recognizing that not all writers can easily adjust to writing topic-based, modular content appropriate for reuse. What types of changes should technical documentation, training, and support center managers be aware of?

Craig: Managers must plan time to gain a thorough understanding of the shift to topic-based writing by establishing best practices, providing author training and ongoing review processes to monitor and manage the shift. This should also be applied to understanding DITA’s separation of presentation from content.

Given the importance of these changes and the need for a smooth transition through this shift, I also think these considerations should be part of the overall Change Management Plan. Documentation, Training and Support managers should seek assistance with Change Management from their Company’s Project Management Office and/or some external consulting for advice or help with execution.

Chip: Things are certainly changing rapidly in the content management software arena. We’ve made big changes here ourselves. At Astoria, we have made the move to the hosted content management system model (often referred to as Software as a Service or Saas), an approach that provides on-demand access to the content management system via the web. This is good news for companies who have content contributors who work in geographically dispersed areas, and for those who travel and need access to the system. It’s also a big selling point for those organizations that don’t want all the hassle of installing and managing the system themselves. When an organization adopts a hosted content management solution, what responsibilities are transferred to the SaaS provider? And, what are the not-so-obvious benefits of this increasingly popular approach?

Craig: At Astoria, we are fully responsible for the overall operation of the system. This includes ensuring that the system is always available at or above the promised service level (at Astoria its 98.5% uptime). Because our business and our revenue stream is dependent on the reliable, secure operation of our CMS application, our CMS users have told us we often provide better service levels (less downtime and faster response times) than for in-house applications managed by IT.

There are also benefits for a Customer’s IT organization as well. In addition to not having additional servers to manage, maintain and back-up, the IT organization does not need to train any of their already stretched resources on the lower level application administration, configuration and tuning aspects of the CMS.

Astoria’s personnel ensure that the CMS is optimally configured and updated at all times. The SaaS approach ensures a reliable, available solution to CMS users while allowing IT to focus on their core areas of technical expertise.

Chip: What advice do you have for managers who are struggling to make the case for content management in their organizations? What can a manager do to make the business case for content management?

Craig: Examine the whole business process behind the creation, review, distribution and maintenance of technical documentation. Since the technical documentation process has many cross-functional interactions, include the many stakeholders that touch the process like engineering, marketing, production and most importantly, the consumers of the documentation, your end-users or Customers. Consider the use-cases that drive your publications process: change orders, new product releases and delivery media types.

A strong business case will include tangible improvements in areas such as: faster product release and maintenance cycles, efficiencies gained through content re-use/single-sourcing, reduced costs of translation and publication. These specific benefits should be measurable and lead to financial benefits. This type of analysis will help reveal the hidden costs and inefficiencies that can easily be improved by a CMS. This is especially revealing when those costs are borne or incurred by other organizations. For example, a last minute engineering change order might require separate re-editing and review of the web, pdf and hardcopy media. Depending on priorities, this could lead to a delayed product shipment impacting sales, or inaccurate documentation impacting serviceability and Customer Support, or incur additional re-translations costs.

Finally, once a solid business case is in place, conduct a pilot project focused on validating the key benefits that are expected. Doing so will help you understand how best to scale up your implementation and plan your full production rollout.

Chip: Craig, thanks for sharing your lessons learned with us. I really appreciate it.

Craig: No problem. I really think this subject is an important one that more and more technical documentation managers will be forced to address as they make the move to content management. I'd like to encourage your readers to check out our webinar archive where they learn more about several of the issues I discussed with you here today.

Not all content management systems are alike, however. They vary greatly in the ways that they manage the actual content itself –- the text, media assets, cross references, and links -- and how they manages the changes to these items over time. The ability to manage the changes to content over time is a key way to differentiate various CMS applications.

CMS applications to support Dynamic Product Documentation require very demanding approaches to maintain conformity to product releases. Typically, this content is delivered in multiple formats such as PDF, HTML Help, etc. and is subject to frequent changes/updates and requires tracking these changes at a very granular level.

Many of our customers need to maintain complex documentation sets. Efficiently managing the creation and delivery of these information products involves keeping track of multiple versions and the changes made to each, as well as publishing the right information for each target audiences in the appropriate languages. The ultimate challenge is to maintain older products (and their legacy documentation) at the same time you create and deliver newer configurations of the same or derivative products. These information products all share a common set of content and require a very granular management approach to track the differences and configurations for each release. These variants all need to map to customer deliverables and are typically published in multiple languages.

A dynamic solution calls for a very fine-grain content component management system to manage complex deliverables. These requirements go beyond a typical document or file management system. Dynamic content solutions need to manage the complex product variations, versions, languages and links typical of documentation, help files, service guides and training materials. Managing the relationships of the content and their changes over time requires extensive management of content components –- text, graphics, rich media –- and all of the links tying them to product deliverables.

Content component management systems like Astoria provide a very easy approach for creating and managing content for reuse. Components of larger documents (or components of DITA Topics) can easily be shared between deliverables. An advanced, object-oriented content component management system does not require you to define “minimal revisable units” or MRUs to reuse content nor do they need to “burst” a document into “chunks.” This saves significant time and effort when designing component reuse models and lets you easily adapt your reuse model in the future.

The higher percentage of reuse within a deliverable, the greater the consistency of information provided to your customer. Reuse also builds in protection from future product changes by minimizing the time required to make changes. With advanced content component management systems like Astoria, you can easily change the content reuse model without any programming or database administration. A component approach also provides applications with the ability to automatically assemble documents based on search queries, customer profiles, or specific content. This greatly expands the potential derivative documents that you can provide –- customers can receive custom- tailored documents on-demand designed to meet their specific needs.

However, not only are you required to manage component changes, but you also need to manage the changes to the component relationships over time. For example, a newer version of your product may have dropped support for Windows NT, but the older version continues to support it. Without a CMS, you are forced to mange two (or more) sets of documentation, even though 80 to 90 percent of it is identical. Differences usually are just in screen captures, procedures or menus. Add localization into several languages, and you have a configuration nightmare that can grow to become unmanageable when storing this content on a typical file system.

Finally, your customers do not want to figure out what documentation applies to the products that they purchased from you. Customer satisfaction surveys show that consumers believe that they are often provided too much documentation, much of which is not related to the specific version of the product purchased. Too often, they report, they are forced to cull through content that does not apply to them at all. This leads to customer dissatisfaction, and in many cases, increases in calls to your support center. In some circumstances, customers get fed up and take their business elsewhere.

Often in customer meetings the discussion moves towards the “ripple effect” that Engineering Change Orders (ECOs) have on documentation. Product changes always have impact throughout an organization. The closer it is to the product ship date, the larger an impact ECOs have on product documentation and the ability of the technical documentation team to manage updates in a timely fashion. ECOs have a compounding effect when content has already been sent to the translation vendor -– people have to work all hours of the day and night with costs skyrocketing. The better prepared you are to manage them, the smoother the process for implementation.

A component management system is designed from the beginning to anticipate the ripple effect providing several critical features to minimize their impact. First, you can quickly identify what content components are reused -- and where (and by whom) -- within the information products you create. When you update a source content component, it automatically updates all other references to it. In this scenario, only the source content requires review and approval, saving critical time. Finally, only the components that have been changed will need to be re-translated, again minimizing time as well as costs.

In conclusion, a content component management approach provides the disciplines of a CMS while providing an easy way to manage and adapt to future business requirements that were not relevant during your initial implementation.

Chip: Emma, thanks for agreeing to chat with us today. Can you share a little background information about yourself and your role as a performance strategist and change management consultant?

Emma: Looking back with 20/20 hindsight on my career, I've landed in jobs where there was either complete chaos, or nothing yet started, which involved either restoring effective order, or creating it. So, it turns out I've had a change and performance focus all along. I like to think that going independent and starting my own company some 5 years ago hasn't really changed what I do, it just removed some distractions.

Chip: As a change management consultant, why did you decide to focus in on helping organizations move to content management, instead of some other niche discipline? What makes content management so important as a performance tool?

Emma: Timely information is key to good customer relationships. Good customer relationships are key to a business staying competitive and profitable. Content management is about distributing information. Ergo: content management is key to business success. In a greatly compressed form, that's the thought-path that got me where I am now. Implementing CM however, goes far beyond simply installing some software. I believe that it also requires a fundamental re-think of the way you've done business so far. And with a fundamental re-think comes fundamental change; revolutionary, radical change, as opposed to gradual, incremental change. It's in helping companies anticipate, prepare for, and ultimately overcome the human performance challenges of such change that I see my most valuable contributions.

Chip: You’ve written previously about the importance of recognizing that cultural and organizational factors can impede change. When moving to content management, are such changes inevitable? In other words, can a CM be implemented without an impact on the corporate culture? If not, why not?

Emma: The short answer: No. There's no avoiding impacting the corporate culture. Let me give you an example: How can you expect people to develop new ways to collaborate when you keep them 'locked away' in separate, cubicle-heavy silos? Only letting them out for an occasional 'project team meeting'? Cubicle culture has to go - and not a moment too soon. If we want and need people to collaborate, we're going to have to physically house them in a shared open, accessible, work area. If you have geographically dispersed teams, give them virtual collaborative tools and spaces. It is also apparent to me, that you can't foster cross-functional collaboration, if you try to maintain a subtle, but rigid unofficial caste system, where the opinion of an engineer is valued more highly than that of a writer.

Chip: Why do some organizations seem to underestimate the impact of putting in a CM system? Where do you think the confusion comes from? And, what advice can you provide to those who are preparing to adopt a content management system?

Emma: First of all, let me say that there are many organizations that - deep down - sense the need for these developments, and are open to them. Increasingly, responsible vendors, integrators and vendor-neutral CM consultants are broaching the topic of change and the need to manage both the change process, and the organization's expectations of what a CM project can - and cannot - accomplish. Ultimately, a CM project succeeds or fails based on the acceptance and adoption by the users. It follows that focusing resources and efforts on helping the users adjust will bring a huge return on investment - especially compared to the expense of the hardware and software. I also believe that CM is what is commonly called 'a game-changing concept'. Some organizations don't necessarily see at the outset just how revolutionary the change will be. It's not uncommon, typically if IT is heavily involved in the initiative, that companies view it as "just another piece of software; so, provide application training, and move on". And most underestimate the impact on their staff, because they underestimate the impact on the way they've always done business. Either way, the introduction of CM will jolt organizations into action. They can choose to prepare for the changes, or not. But change they must, or the CM project will fail. Guaranteed.

Chip: Many organizations recognize that they need to provide information and training to those who will be expected to use a content management system. What else should they do, in your opinion? What are some common mistakes organizations make that may seem practical at first, but may negatively impact the success of their projects?

Emma: To elaborate on what I just mentioned: "Provide application training, and move on" is clearly insufficient. A top-down approach, where the users are barely involved until the implementation phase is imminent, may seem efficient, but my contention is that is it not effective. CM, with its aspects of XML and structured authoring, reuse and repurposing of content objects, creates a perceived loss of control for some users, and this requires a guided bottom-up approach. A migration to content management invariably triggers changes in workflow, procedures, governance and accountability. These changes require users to change their behavior - and require the organization to facilitate that behavioral change. Learning to look at the work from different perspectives, learning to think in novel ways, adjusting the informal power structures to the new reality - these are difficult because people have invested so much in making the old ways work, and it's hard to give up that mastery, unless you can get some help understanding how things will be better in the future.

Chip: How are companies generally handling the change management component of a CM project?

Emma: The best ones are at the very least aware of the impact change can have on human performance, and deploy internal and external resources to help management and staff deal with the impact. The worst ones seem to believe that telling people what is going to happen, and when, will somehow miraculously result in a successful, painless implementation. The latter are in for a bit of a shock, I'm afraid.

Chip: Explain to us your ideas about increased collaboration between disciplines, and why you link it to corporate culture change?

Emma: As content converges, and content components are reused and repurposed over an increasingly wide array of platforms, 'owning' a document is no longer possible. Point of fact: our definition of 'document' no longer really suffices. To get the cross-fertilization required for true innovation, walls between disciplines need to become more permeable, and content silos will become more and more integrated. When the wall comes down, the culture changes; we need only look at the Berlin Wall for proof of that.

Chip: How does a CM project impact the social contract between employee and employer, for instance?

Emma: CM systems deal with information - creating it, reviewing it, collecting it, distributing it. The conjunction of information-hungry customers and information-rich organizations increases the demand for better, more timely, more personalized, more relevant information. The old 'manufacturing' model - already under considerable pressure - is being replaced by the 'information' model. As a consequence, the way companies think about employees has to change; the concept of the interchangeable - and easily replaceable - 'assembly line worker' is gradually morphing into the highly knowledgeable and difficult to replace 'information worker' - even in classical manufacturing environments. As the understanding grows that people make decisions rather than things, the value of the embedded knowledge within workers inevitably will change the employer-employee relationship. Already demographics and outdated HR practices are causing tremendous retention and staffing challenges. The "two Toms' - Davenport and Peters - have contributed greatly to the clarity around this imminent corporate culture shift.

Chip: How can companies accelerate the implementation process; does every CM project need to take up to 12 months?

Emma: I don't believe every project needs to take that long; in part the methodical, carefully-planned and phased approach is a consequence of the still dominant corporate culture of risk-avoidance. Not too long ago, the dominant belief was that software development required strict adherence to a carefully laid out, structured and phased plan. For many types of software development, that is still valid, but witness the emergence of Agile Software Development practices, we can imagine situations where a more agile and iterative approach to implementing CM is appropriate. Another indication of the push towards accelerated implementation is the Software as a Service (or hosted) CM solution; vendors offering these solutions claim they can have a customer up and running and getting value from their investment in far less time than traditional CM implementations.

Chip: What if people can’t adjust or make the necessary changes?

Emma: It's 'Darwinism' at work. That sounds harsh, but in my belief it is unrealistic to suppose that everyone can - or even should - make the transition to a new way of thinking and working. For the employee who is 10 months away from retirement, it doesn't make sense to invest a lot of money, time and energy in what may be a very painful and difficult adjustment process. Be creative - use their strengths in other ways, perhaps as a mentor, perhaps as contributors to process redesign. For the employee who has neither the talent nor the ability to work in a decidedly more complex and demanding environment, it is cruel to retain her in a job where her only option is failure.

Chip: What then is your advice if some staff need to be let go? Why?

Emma: If some staff cannot complete a journey they never asked to go on in the first place, then companies should take it as an opportunity to be both generous and responsible. Help these individuals, who've contributed their best to the organization so far, transition into a job that will allow them to be successful. If such jobs are not available within the organization, then help them transition out. Allocate funds in the budget to 'restructuring costs', offer a generous severance, and pay for career transition support. In the long run, the cost is worth the 'peace of mind' in the remaining employees. The respect and appreciation garnered - and the consequent commitment and engagement of the staff - contribute to the long-term success of your organization.

Chip: What role does line management and senior management play in the successful implementation?

Emma: Both have significant - but very different - roles to play. All too often, once the purchase of the software has been approved, the project devolves to line management, with the mandate to "make it happen". Senior or executive management however, has an ongoing role to play: three critical roles, actually.

1. Champion Change
2. Enforce Compliance (with new rules)
3. Transition Lost Employees

As for line management, unless the organization is sufficiently large to support dedicated change and performance management specialists, bring in outside help to support the line manager in the change effort. Most line managers have neither the bandwidth, nor - realistically - the coaching skills to do this important task justice. And as I've indicated before, to ignore the human impact of change is to jeopardize the success of the CM project.

Chip: What are some of the other cultural changes triggered by a CM project?

Emma: There's no stock answer to this question; it's going to vary from one company to the next, depending on each specific situation. I also want to stress, that some companies are so ready for the changes a CM project may trigger, that they'll breeze through the implementation. Change is both desirable and inescapable, but success is neither guaranteed nor compulsory. Success takes hard work, and commitment, a willingness to try new and unproven things, and clear-eyed preparation. For cultural change to be truly successful, there can be no sacred cows left standing in the pasture.

Chip: What is the top priority from a program management standpoint for a CM implementation to meet its goals and objectives?

Emma: Communication, communication, communication. Communication is by definition a two-way street, and both the technical and human performance change management plans need to incorporate multiple avenues of communication, in multiple directions. Fear is resolved through information, and there is no such thing as too much information during a period of rapid change.

Chip: How can companies become more aware of, and prepare for, cultural change?

Emma: The organization's readiness for the impact of cultural and procedural changes should be assessed, preferably by an external consultant, since most companies suffer from 'familiarity blind spots' when it comes to identifying potential pain points. Some assessment methods are better suited to uncovering the reality below the surface than others, and need not cost a fortune or take long. The effort put into identifying the areas of concern pays off handsomely when the project gets underway - and it prevents nasty surprises.

Chip: Emma, thanks for helping us better understand the change management and human performance challenges associated with content management projects. I know our readers appreciate your expertise.

Emma: Thank you, Chip. I hope your readers find our discussion useful. As always, I'm happy to answer follow-up questions on this blog or via email. ]]> http://www.astoriablogs.com/blog/2007/02/managing_cultural_changes_trig.html http://www.astoriablogs.com/blog/2007/02/managing_cultural_changes_trig.html Mon, 26 Feb 2007 05:51:39 -0800 Analysts have been writing about Enterprise Content Management (ECM) for a few years now, creating reports that focus on such things as enterprise content trends, content management software applications, business requirements, vendor profiles, and best practice recommendations. A majority of these reports focus on unstructured content and content primarily destined for Web sites.

A recent report, though, issued by the Forrester Group Forrester Wave Report: Content Centric Applications, Q1 2006 raised some eyebrows and heated discussion from the content management community, and makes the subject of how to use and interpret analyst reports particularly timely. The Forrester report highlighted several important business requirements for “multichannel customer experiences and primary interaction points” for “quality content.” The report went on to discuss content-centric applications and several technologies available from large ECM vendors.

The controversy arose in what the report failed to examine, i.e. the world of structured content, including Component Content Management (CCM), an alternative approach that manages “content at a granular level...rather than at the document level” to quote content management guru Ann Rockley, president of The Rockley Group. According to Rockley, author of Managing Enterprise Content: A Unified Content Strategy (which spells out a strategy for managing granular, reusable content), "Content components represent a single topic, concept or asset (e.g., image, table). They are assembled into multiple content assemblies (content types) and can be viewed as components or as traditional 'documents'. Each component has its own life cycle (owner, version, approval, use) and can be tracked individually or as part of an assembly."

For background, the component management approach uses granular “building blocks” to assemble customer-centric information. Typically, the components are managed as XML and can easily be re-assembled on-demand based on business rules and the requirements of the content consumer. This approach allows organizations to deliver the right information (personalized by role or interest area), to the right people, at the right time, in the right language, and in the right format.

In the technical publications industry, there's a big push to take advantage of component-based content models. One such initiative, The Darwin Information Typing Architecture (DITA), an technical publications standard, manages content at a very granular level (Topics) and provides authors with a easy method of reusing content components (Topic Maps) to create deliverables.

The oversight in not including component content management in the Forrester report, is in the fact that content management strategy and solution evaluation should be relevant to the requirements of the end deliverable and its application - i.e. how, and for what purpose will the the information be consumed?

In the case of component content management, the approach is additive – you assemble or build components that match the needs of a specific product (or customer) deliverable. This is especially relevant to industries with products that have various configurations, languages, platforms, audiences, releases, etc. and are subject to constant change at the component level.

Since customer satisfaction is a key metric for many companies, constantly improving product information deliverables such as user guides, online help, parts catalogs, repair guides, and customer support and knowledge centers, etc., is a given. In addition, a growing business requirement that supports use of a component-based content management approach and tools is where companies want to dynamically deliver personalized content in any required configuration. Since it is not always possible to anticipate all the potential ways your product is used, a component management system provides advanced ways to manage the relationships (or links) between components, which really is critical if your content components are heavily shared, and re-used. Component reuse relies on metadata to include just the information required for a specific deliverable, ending the "here's everything we have, look through it and find what you need" approach used by far to many organizations today.

Component content management shows its best colors when applied to a deliverable that has topics that are related, such as supporting the 'how to' requirement of an online help system. Users require rapid search and navigation to help them zero in on the information they need to complete a task. They can click on related topics link(s) if these desire further details or require additional information. If too much information is presented, users can grow frustrated and perhaps overwhelmed. In these situations, they often give up looking and search for alternative ways to find the answers they need.

A suggested way to use analyst reports

What’s troubling to me is that too many analyst reports fail to focus on the final purpose of the content or the content components that are to be managed. Assumptions are made that do not fit business requirements. It’s difficult to talk about software tools and applications when the true purpose or 'use scenario' is not identified. Analyst reports can focus too much on technology trends and not enough on the actual application for that information.

Despite these shortcomings, analyst reports can be a source of relevant information; however, your mileage may vary from analyst to analyst. The best approach is to evaluate the information provided by a diverse set of resources (analyst reports, customer case studies, white papers, and articles). This approach can help you locate the information you need to solve your business problems.

No matter what type of resources you look to for guidance, it’s important to start with a careful understanding of your organizational and business requirements and rank them by priority. Much of this information can be found within your customer surveys, product plans, and company goals and objectives. Clear interpretation of your requirements provides much needed clarity and will help you make the best use of the information included in analyst reports.

So what useful information can be found within an analyst report? Usually the best analyst reports include information about actual customer deployments - providing comparisons of what was planned and their actual results. Additionally, user satisfaction results by similar companies provide realistic insights on objectives, and results of the solutions implemented.

I'd like to know what your take on the role of analyst reports. Do you use them? Are they valuable or do they too often miss the mark?

Next month we'll take a peek at several analyst reports, including the recent Aberdeen Group report entitled Next-Generation Product Documentation: Getting Past the “Throw It over the Wall” Approach.

Eric and I also examine several alternative approaches some creative tech pubs departments have considered (for instance, using a code database as a content management system -- or using Microsoft SharePoint) and why they're not appropriate solutions for technical documentation teams. And, to close out the interview, we discuss the issue of cost (what is the cost of free?) when considering whether to implement an open source or a commercial content management system. This is a technology interview every technical publications professional needs to read.

CHIP: There's some confusion in the technical publications space about the various types of content management systems on the market today. A common question relates to the appropriateness of one type of content management system over another. I was hoping you would help our readers better understand why some types of solutions are appropriate for the demands of technical publications.

Our first question is a basic one. What is a content management system and what is it designed to do at its most basic level?

ERIC: That's a good place to start. In its most basic form, a content management system controls the storage, indexing and retrieval of things, be they text, images, or some combination of the two. The basic functions of any content management system are the same: open (or select), close, read (or retrieve), write (or update), create, copy, and delete. It's not surprising then that several classes of systems each qualify as a content management system, from common file systems to highly specialized native-XML databases. What separates one class from another is the type of content under management. For example, a file system gives you the basic tools to manage files; a relational database is well suited to managing characters and numbers; and an XML content management system is optimized for XML-based content.

CHIP: Okay, so can you provide us with a basic description of an XML content management system?

ERIC: Well, like all content management systems, an XML CMS controls the storage, indexing and retrieval of XML objects. Nevertheless, and this is a key point, precisely because the content is XML, an XML CMS is optimized around hierarchical and attribute management of XML content. Hierarchical refers to the parent/child relationships that exist between XML objects in a document, document type definition or schema. Attribute refers to the characteristics of an XML object itself. It's the ability to handle basic CMS functions combined with a specialized implementation for managing XML hierarchies and attributes that defines an XML content management system.

CHIP: XML content management systems are often misunderstood. How are they different than content management systems built upon relational databases?

ERIC: I like this question not simply for what it asks but also what it reveals; specifically, the inherent difference between what an XML content management system is, and how an XML content management system is implemented. Let me draw on a common example: transportation. In considering the problem of urban traffic congestion, it would be reasonable to compare two modes of travel, perhaps trains and cars, without considering which automobile manufacturer is better than another. Similarly, while charting the rise in structured content, it's reasonable to debate the various methods for managing structured content, and then address various implementations separately. No question; an XML content management system is the best method for managing structured content encoded in XML. And there are both established and fledgling vendors offering management of XML content. But, which implementation is best suited to the problem of managing structured content? Logically, you would have to give the nod to a system that handles XML object hierarchies and attributes through pointers versus a system that uses tables and relational calculus.

CHIP: Why? Doesn't that lead eventually to a question of preference?

ERIC: Not at all because you can measure the technical and business advantages of an object-based XML content management system over relational-based XML CMS. Look, in an object-based XML CMS, hierarchy and attribution are represented by object pointers. If you borrow text from another document in a content reuse exercise, or add attributes to an object to allow for a new output format, an object-based system merely rewrites or adds object pointers; the objects themselves remain intact. But a relational-based XML CMS uses tables, rows and SQL statements to mimic object hierarchies and attributes, and the resulting overhead to manage and join tables and rows imposes processing bottlenecks. Altering object relationships, particularly when revising an XML schema, involves the expense and time of a relational database administrator. Driving higher levels of content reuse means managing more rows in each table, which drags down the performance of SQL table joins and overall query processing. These costs and penalties simply don't exist in an XML CMS built on a true object database. Any business executive will appreciate metrics that show significantly more efficient output from Team Z using an object-based XML CMS than Team Y using a relational-based XML CMS, and simply subordinate any claims to preference. The metrics will show that he's got the right tool for the right job.

CHIP: Tech pubs departments are some of the first to embrace content management and XML technologies. But, they are not very experienced tool shoppers. Can you help us understand the types of organizations that would need an XML content management system?

ERIC: Speaking broadly, any organization or department looking for higher levels of content reuse needs an XML content management based on object technology. The thinking goes like this: it costs less to reuse high quality content than to create new, high quality content; so the more you reuse, the more high quality output you generate per unit of time. Then someone will ask, How granular does my object model need to be because there have to be trade-offs between reuse of entire documents versus reuse of paragraphs and sentences. The answer to that question tells you which departments and organizations need an object-based XML CMS. For example, marketing communications departments really need an object-based XML CMS because they constantly snip a sentence here and sentence there from different sources to build data sheets, product brochures, and similar non-narrative collateral. Similarly, customer support organizations and application engineering teams have a huge need for topic-based, non-narrative content for their product notes, problem-resolution knowledge systems, and other customer-specific documentation.

CHIP: Can't relational databases handle these tasks? If not, why not?

ERIC: Oh, it would be wrong to say that they can't handle object reuse, but if you read closely to what XML CMS vendors who use an relational database are saying, they always talk about "chunking" or "minimum reuse object size", or words to that effect. This is where the problem with a relational database comes to the fore. As you break up content into smaller and smaller elements of reusable content, the system adds more rows to relational tables and there is an increasingly negative impact to query processing and table joins. This means that organizations who need high levels of object reuse are limited by the underlying architecture of their relational-based XML CMS. Hence, there is a tool-based limit to the cost savings of reusing high quality content. It's not that these systems cannot manage XML content at high levels of granularity; they can. It's just that the dollar costs for efficiency -- you know, high quality output per unit of time -- rise dramatically when object granularity increases to the point where it doesn't make financial sense to pour more resources into the relational-based system. These dollar costs include being forced to purchase additional processing, storage, and memory capacity in order to maintain acceptable response times to SQL queries over an exponentially increasing data set, or limiting the granularity of reusable objects (to maintain performance on existing platforms) to the point where cut-n-paste operations nullify the efficiency improvements of content reuse. Basically, the relational-based tool is ill-suited to managing structured content where output efficiency relies on significant content reuse.

CHIP: That seems like a logical explanation. But what about software code databases? They promote reuse, too. Why cant we just jimmy-rig our software code database to be a content management system? If that's not a good idea, why exactly it is a bad idea?

ERIC: Yeah, why can't we? After all, software reuse and content reuse are cousins, right? Yes, they are. But the distinctions around what is an object and what is reuse highlight their different parentage. One distinction: a good code management system supports the concept of information hiding, which means that you choose an object for reuse by the nature of its inputs and outputs, not by what it contains. In fact, the information about how the object is implemented (i.e., what is inside of it) is hidden from you. Not so in with XML content, where the opening and closing sentences of a paragraph are just as important as the sentences and images within the paragraph. Another distinction: a code management system is a file-based vault; the interactive development environment must be employed to provide an object-based overlay to the files so that developers can find and reuse objects. As with all overlays, the interface between the object-based development environment and the file-based code management system introduces a bottleneck during any storage, search, indexing, or retrieval operation as the object names are mapped into file names. An object-based XML content management system suffers no such performance bottlenecks because there is no overlay. XML content objects are stored, searched, indexed, and retrieved in their native form; assembly into document form occurs only during a publishing operation. Perhaps a third distinction is that code management systems do not have innate capabilities for handling object hierarchies and attributes; such capabilities must be grafted into the system, which introduces another awkward interface layer. As I said earlier, native support for object hierarchies and attributes is the defining characteristic of an object-based XML CMS.

CHIP: With the entry of Microsoft into the content management space, some IT directors are telling their business clients that they don't need to buy a content management system because they already have SharePoint. Is SharePoint an XML content management system? Can't we just use SharePoint for technical publications management functions? If not, why not?

ERIC: SharePoint, Xythos, and other such systems offer basic content services: check-in, check-out, file-level versioning, highly granular access control, workflow routing, and so on. SharePoint is the natural result of a file system married to WebDAV. The user sees folders and files, just like on his local disk, but he also gets these other services that a file system alone doesn't have, and everything is accessible over the Internet. But SharePoint cannot offer anything higher than document-level reuse, so the dollar costs for efficiency are very high for the organizations I mentioned earlier that have a compelling need to reuse topic-based, non-narrative XML content. The fact that Microsoft Office 2007 products use an XML-based file structure is incidental to SharePoint; SharePoint doesn't manage the XML fragments within these files, just the files themselves; so it isn't an XML CMS.

CHIP: It seems like there's another battle sidetracking some technical content creators when they start to think about tools. One of the most common questions we hear is "What about open source?" Can't open source XML content management systems do the same things as their commercial counterparts?

ERIC: First of all, in talking about open-source software, we should all agree that were living in the golden age of open source. And with any golden age, what is popularly perceived to be possible outstrips what is practically accomplished. Java went through its golden age, and open source is in it now. Java matured and found its appropriate application, and so will open-source once the golden age has reached its zenith. Second, my sense is that open-source will yield its biggest gains when it follows after monopolization cycle. The respective rises of Linux, the Firefox browser, and OpenOffice seem to bear this out, as does the relative obscurity of open-source databases like PostgreSQL, Ingres, and MySQL (although MySQL is making a good run). I expect that after object-based XML content management systems reach near-monopoly pricing conditions, enterprise-quality open-source alternatives will become viable alternatives to their commercial counterparts. Until then, technical content creators will read about pilot implementations based on open-source, but they won't be able to talk to anyone who bet the farm on an open-source, object-based XML content management system and came away unscathed.

CHIP: There also seems to be some confusion around the open source concept. For instance, it's often argued that open source is free? Is this true? And, if not, what are the costs of an open source solution that may not be apparent to the average technical communication professional.

ERIC: Open-source is free the way water is free. You don't pay for water; you pay for the service to deliver water to your location. Open-source is similar. You don't pay for the technology; you pay for the services to support that technology. These services take many forms. For an open-source, object-based XML CMS, you probably need to keep programmers on staff to tweak the software to meet specific requirements, compile and maintain updates to the source code itself, communicate feature requests to the source community, and tasks like that. Some open-source XML CMS systems can be installed and executed without the need to compile. However, since open-source solutions are relatively new compared to their commercial counterparts, it will be impossible to find an object-based XML CMS from the open-source community that is as thoroughly tested in enterprise-class conditions as a commercially available solution. I mean, more than a few of these object-based XML content management systems have almost 15 years of commercial service; any open-source alternative could hardly approach that level of rigorous improvement.

CHIP: We've talked a lot about when tools are appropriate. Now, Id like to ask the reverse. When is an XML content management system NOT a good option?

ERIC: This is a very good question. An XML CMS yields few benefits to organizations that need document-level management. By document-level management I certainly mean the basic content services I mentioned earlier. But I also mean services like records management, form-based routing (such as moving an insurance claim form through a an approval process), or traditional data warehousing. There are scores of enterprise-quality solutions optimized for document- or file-level management, and customers have extracted enormous value by embracing and integrating document-level management solutions. Interestingly, though, you will note that there is something of a shake-out going on in this segment of content management, signaled by the acquisition of Hummingbird by Open Text and FileNet by IBM, respectively. A shake-out period immediately precedes an era of monopoly pricing, which should then trigger the rise of viable open-source, document-level content management alternatives.

CHIP: If an organization is planning to move to XML content management, what new skills would their staff require? And, can they get started developing these skills before they've selected tools? Can a head start (for instance, the development of structured XML authoring skills) help an organization get their content management project completed faster?

ERIC: To your second and third questions, yes and yes; a head start in structured authoring is imperative because it is the first in a sequence of skill upgrades that ultimately lead to higher quality output within a unit of time. In fact, recent survey data from Aberdeen Group (The Next Generation Product Documentation Report: Getting Past the 'Throw It Over The Wall' Approach), indicate that best in class companies are 46% more likely to author structured documentation. These companies meet documentation deadlines 92% of the time (on average) or more; take half as long as some others to translate product documentation content; and make 2/3 fewer post-product release documentation changes. To your first question, the skill upgrade sequence starts with structured authoring and progresses quickly to adoption of topic-based authoring and minimalism. The last upgrade is effective reuse, which answers the question, How minimal does a topics text need to be to drive the highest level of reuse within the organization?

CHIP: Is there any thing else you'd like to add?

ERIC: Well, yes there are a few. First, the arguments in favor of an object-based XML CMS over a relational-based XML CMS can drift into the realm of religious warring if you ignore the axiom that in the long run, the best software tool harmonizes the object model with the object implementation. Second, our company deploys open-source software in its Astoria On-Demand product; notably, the Lucene search engine. Lucene enjoys increasingly widespread adoption to check Google's benevolent despot but otherwise near-monopoly status. Finally, what works well for document-based content management cannot work well for XML content management. After all, an elephant cannot count to five on one hoof, even if you change the size of the hoof.

CHIP: Eric, thanks for your time today. You certainly helped us clear up a few misconceptions. I appreciate it.

ERIC: No problem, Chip. It's been my pleasure. If your readers have any questions about XML content management systems they would like to ask me, they can do so by leaving a comment at the end of this post. I'll gladly answer any questions posted.

Note: If you're interested in learning more about how a content management system can help you increase efficiency, enable content reuse, cut expenses, and drive a positive return on investment, check out this free one hour Astoria on-demand webinar (featuring JoAnn Hackos).

Chip:  Joan, please tell our readers a little about yourself and your company, Lasselle-Ramsay.

Joan: I founded the company in 1982, the year the IBM PC came out. Our first clients were start-up companies developing applications for the PC. We served as their technical documentation department creating software and hardware documentation. Since then, we maintained our focus on the high technology market and the creation of new product documentation, but, of course, have expanded the markets that we serve and the services we provide. We have three main practice areas: technical documentation, learning content development, and content management. We serve clients in high tech, bio-tech, medical device and life sciences, as well as in the finance and insurance space.

Chip: You've been advising clients and providing technical documentation services for nearly a quarter century. How has the world of technical communication changed?

Joan: Well, certainly there have been many changes in the tools that technical writers use. When I first started in this business, many documents were typeset. We then moved on to line editors followed by word processors and desktop page layout programs. Ten years ago, it seemed like SGML held some promise, but because ease-of-use was not its strong suit, it failed to gain widespread adoption.

Today, we see more and more clients moving toward XML authoring combined with a content management system. This approach is an effective one because it solves many of the expensive challenges -- not just content creation problems -- faced by organizations who are looking for ways to reduce overall expenses and rid their companies of wasteful processes. By combining a solid content development strategy with an XML content management system and authoring tools that support the goals of those who use them, we can deliver a more complete solution to our clients.

Today, we have an opportunity to change -- even elevate -- the role of the writer within an organization by helping them gain valuable new skills, adopt smart waste reduction approaches, and become more effective content creators, collaborators, and publishers. In effect, by respecting content as a valuable corporate 'asset'  worthy of being managed efficiently by a content management system. Technical communication professionals are able to say, "Hey, we're not just commodity writers. We're strategic players in this organization that contribute to product and customer satisfaction, and we have a stake in the overall outcome. We're looking out for waste and finding ways our entire organization can become more efficient. We're valuable and our efforts and output can be replicated and leveraged across the enterprise to the benefit of everyone in every department."

Chip: At Astoria, we have identified a trio of content management environmental drivers, velocity, volume, and variability, that are putting pressure on a an organization's content and documentation publishing processes. These drivers have significant bottom-line impact, especially for manufacturers managing the product information publishing process - authoring, publishing and updating - for all the critical information associated with launching and servicing complex products and services over their lifetimes, everything from user documentation to suport and customer service information. I wrote about these drivers in early 2006 in an article for DM Review. But, I'm interested in your take. What do you think is driving the trend for XML content management adoption in the technical publications space?

Joan: The competitive business environment is major factor -- globalization, increased regulation, cost, competition, shorter product life cycles, and a recognition that information is a business asset. All of these business needs (and more) can be supported by a move to XML content management. The semiconductor industry provides a good example of that. 

Chip: Why is semiconductor industry such a good example?

Joan: Semiconductor is a fast-paced global industry. Global competition drives product innovation and also drives cost reduction efforts. All semiconductor companies have COO (cost of ownership) reduction initiatives. In the past, companies have focused their efforts on the manufacturing side of the business to drive down costs. Now they are looking at other, previously unrealized areas for cost reduction -- primarily efficiencies made possible through standardization, structure, process improvements, and the elimination of manual tasks. Content management provides a good opportunity to extend the cost savings beyond the fabrication process.

Chip: What else is happening in the semiconductor industry?

Joan: All semiconductor companies are facing shorter product life cycles and faster time-to-market presssures to be successful.  But, in addition to being faster, companies also need to be more competitive and that means providing more capability at the best possible price. Therefore, the ability to reduce cost while maintaining quality is a strategic advantage, a corporate differentiator, and a competence that needs to be pursued.

Another important trend, is product line extensions and multiple configurations - companies are addressing a wider range of semiconductor products for multiple markets. Basically everything that we touch these days from computers to cell phones to digital cameras and even our car has a significant amount of semiconductor content. It all starts with a wafer and a chip. The proliferation of products is truly incredible with a worldwide semiconductor market estimated at about $230 billion in 2005.

Chip: Where did semiconductor companies focus cost reduction efforts in the past?

Joan: The primary cost reduction efforts have focused on technology and manufacturing. How do you produce these highly sophisticated devices at the lowest cost?  To accomplish this, integrated device manufacturers (IDMs) and foundries made billion dollar investments to move from 200mm (8 inch) to 300mm (12 inch) wafers to lower cost per die. This required building larger new fabs with new equipment.

The goal is to realize economies of scale drive down costs, find cheaper material and source the best most qualified talent accross the globe. In the semiconductor industry -- outsourcing has become the norm rather than exception. It is not unusual for a product to be designed in one country, manufactured in another, and packaged and marketed in a third. The separation of design and manufacturing capabilities has spurred rather than hampered industry growth.

Again, the emphasis has been on the manufacturing side. Little has changed on the information management side of the house. So, as you can imagine, there is significant potential for improvements that can be made.  

Chip: Why has the focus shifted to outside the fabrication process?

Joan: Looking for ways to improve product documentation management, lower documentation costs, and extend the cost savings outside the fab cannot be overlooked in a business environment that is truly global and cost-sensitive. Content management systems (CMS) are becoming more of a requirement because companies are realizing that all of the tasks involved in creating and managing product documentation, specifications, and datasheets figure into the calculation of total product cost.

A CMS provides tremendous benefits to large global businesses, like the semiconductor companies that have a diverse audience and extended product lines. It allows them to re-purpose content, lower localization costs, have a tighter version control, allowing them to reduce overall product cost, and also to reduce risk/liability in publishing inaccurate information. They need information that addresses the global audience and information cannot be a barrier to time to market commitments. The engineering time is also becoming more valuable and more constrained, as more and more products being developed, so enhancing and automating the collaborative environment between engineering product specialists or owners and information experts becomes even more important. A CMS that facilitates ease and speed in collaboration and review cycles becomes mandatory.

Chip:  I recently wrote an article for KM World that examines the hidden costs of product information publishing. Product documentation is an important cost reduction area that most CEOs and CIOs have yet to discover. In the technical documentation space, how can a CMS reduce costs?

Joan: Moving to a CMS can be a challenging proposition for technical documentation departments in many industries. In the semiconductor space, it has been particularly challenging because of tight budgets and deadlines due to time-to-market pressures. Furthermore, corporate enterprise CMS implementations often do not adequately address technical documentation problems. In other words, they fail to solve the most common -- and expensive -- technical publishing problems. However, selecting the right CMS technology (one designed to handle granular content and designed with technical publications in mind) can be difficult for most technical communication professionals, most of which lack the knowledge and experience needed to make such decisions. Usually, they start off asking about tools, which, as anyone who is in the content management space knows, is the wrong first question.

At Lasselle-Ramsay, we developed a program that helps technical documentation departments navigate the obstacles and avoid asking the wrong questions. First, we help companies identify whether they are a good candidate for content management. We help them build a business case and then work with them to develop a pilot program that focuses on solving the business problems they have identified rather than on selecting a technology and trying to make it work for their purposes. Once the pilot is completed and a return on investment calculation is validated, we recommend the technology tools that will be meet their needs. The pilot allows companies to "test the water" without a large upfront investment in the technology infrastructure. We focus on information effectiveness and efficiency to help our clients reduce cost and increase customer satisfaction.

Our 10 Best Ways to Reduce Documentation Costs is a good starting point for those looking for ways to control costs associated with the creation of technical documentation.

Chip: One last question, we've been involved with the standards-development for Darwin Information Typing Architecture (DITA), and our customers are actively moving to adoption. How do you see it benefiting the semiconductor industry?

Joan: When implementing a CMS, semiconductor companies need to consider whether DITA is right for them. DITA is good option for businesses that are faced with a constantly changing environments and need to meet time-to-market pressures. DITA allows your data model to evolve as your business need changes, without obsoleting your existing tools and documents. It optimizes localization efforts by reducing translation costs and can help make you more efficient.    

Chip: Well, I've been really thrilled to be able to tap your valued knowledge and experiences since you and your organization have so much knowledge and experience in helping solve real-world information management challenges for technology customers.  And the insight on the semi-conductor companies - where these challenges are only amplified - was really interesting and hopefully gives information management professionals some good food for thought on how to look at the issues, and solutions, for their organization's content and publishing efforts. Thanks for your time.

Note: If you're interested in learning more about how a content management system can help you increase efficiency, enable content reuse, cut expenses, and drive a positive return on investment, check out this free one hour Astoria on-demand webinar (featuring JoAnn Hackos).

The challenge of information interchange is made complex by the balancing act of the need to customize DTDs vs. stay with the industry standard. You need to meet the needs of your organization, however, if a DTD is customized too much, you lose a link to the very standard designed for your industry. If you do not customize enough, authors have to deal with XML tags and attributes that do not have context for their application. Too much customization, transformation scripts become more complex. On top of this, structure and hierarchy is mixed within the information, making it more difficult to maintain transformations between information types.

DITA is an emerging standard that provides an outstanding platform to promote information interchange, in an orderly fashion, within an enterprise or with other organizations. Today much of the focus of DITA is for groups to adopt it for authoring and publishing structured information. Think of the benefits as other groups in you company or even your suppliers and customers adopt DITA – you can provide product documentation as DITA information, and they can even provide you with DITA information. This success has been documented within IBM as more groups adopt DITA. This adoption should become wider spread to ensure the success and longevity of DITA as an information model.

The success of this universal interchange model is greatly assisted by developers taking advantage of inheritance principles designed into DITA. By focusing DITA specializations at lower levels of the topic hierarchy, interchange can be easily accommodated with minimal transformation scripts. Imagine the possibilities of interchanging topics with groups, suppliers and customers, in several different languages, and rapidly shipping products to meet new product marketing configuration requirements!

DITA provides several good methodologies for managing an “information supply chain” where supplier and consumer can easily interchange topics. DITA provides an excellent infrastructure for managing information at a topic level, getting away from document hierarchies that in the past have added complexities to interchange.

Several DITA sub-committees are forming to share ideas and specializations though an open interchange. What will be of interest is how widely adopted vertical industry specialization are implemented to meet their specific business needs and to ease information interchange. It will be important to make this as transparent for authors and publishers to gain wide acceptance. Next, we have to make sure is that DITA authors adopt minimization approaches to their writing styles, but that is a different topic for a future discussion.

I realize a “standard” interchange approach has risk on assuming that DITA specializations will remain at a reasonable level. Also, I do not wish to oversimplify the complex authoring and publishing processes in place for several years. However, the adoption of a new standard like DITA provides an organization to think out-of-the-box on the potential and possibilities with a new approach.

Other complexities – what happens if you and your supplier are updating the same topics and you need to accept updates? How do you manage conflict resolution at a topic level? Do you need to manage change bars? How do you manage topic lifecycle management where information becomes obsolete and must be retired? Add or remove suppliers? What topic maps reference that those topics? How do you manage to complexities of the historic changes over time? This will be the topic of discussion for my next blog and why a content management system is a requirement to automate these tasks and others not yet anticipated.

When meeting with Astoria customers I always ask what pain points are they trying to solve – what is broken with the current process. A primary pain point (but not the only one; others will be discussed in the future) is the ability to keep their documentation configured to match changing or new product configurations. This can be a result of a company merger or combining products not originally designed to work together. The challenge is to create a unified look and feel for your customer that is sourced from content written for a different purpose or by different people.

DITA has emerged as an important new standard for managing technical information. It is shifting the way many of us think about technical information; for years many of us attempted a topic based approach with mixed results. In retrospect, much was asked of technical writers to develop the perfect hierarchy to support a single source approach. DITA has provided a simple and eloquent solution for solving complex content and structure problems by distributing the responsibility for who manages the content or structure. XML provides a nice separation of content and presentation; in the same way DITA topics and topic maps provides a nice separation of content from hierarchy.

DITA is well designed to manage always changing product configurations in combination with minimalist practices for keeping content tightly written. Several years ago the software industry adopted modular code writing; it’s easy to re-combine applications into new bundles. DITA matches that technique by providing much of the same flexibility with topic-oriented authoring and conditional processing. This separation is critical because topics can quickly be re-combined (via topic maps) into new deliverables. This fast re-combination is a dramatic shift because you are no longer burdened by the painful separation of content from its original document structure and hierarchy.

The challenge is to gain business acceptance of this new topic approach and at the same time maintain a clear understanding of what is a customer deliverable – an Adobe PDF, HTML Help, Web content, etc. Success stories I’ve seen are starting to prove this ability to rapidly re-combine topics, and will be a critical success factor for wider acceptance of DITA for managing technical content.