Entry #2 – Content Reuse Implementation at Brocade

Company Name: Brocade
Name of Submitter: Lelia Wright
Email Address: [email protected]

1. Efficiency:

After helping to make the software technology taxonomy part of the corporate taxonomy, we defined the basic content unit for reuse as a technology chapter (DITA sub-map). Most of our technologies map to protocols, such as BGP, SNMP, and RADIUS, but some technologies are constructs, such as licensing or configuration fundamentals. We leverage the use of the software technology groupings from the taxonomy to create our deliverables. We recast our writers as technology owners across three platforms instead of separate writers within each of the three platforms writing about the same technology. Each technology owner gains additional expertise with each new feature for the same technology, and can manage the reused content across the platforms. Our resulting efficiencies allowed us to deliver a new documentation set for a new platform without adding additional writers. Technology owners are more empowered to make decisions about the reuse for their content. Where once our writing teams consisted of an average of 6 writers per platform handling 8 to 12 publications with a lot of technology overlap among three platforms, now each writer owns an average of 4 to 5 technologies across four platforms and we publish 10 to 14 configuration and reference guides per platform. The average number of XML objects (maps, topics, and graphics) per guide is 440. Metrics also show that 59% of the technologies in the new platform are reused with at least one existing platform.

2. Customer Focus:

Some of our customers complained that we did not provide enough examples in our documentation, our command references were limited, and content was inconsistent. Part of our efforts with content reuse has focused on reworking our content from documenting one command per topic to creating multi-command tasks with real world examples that customers can use to advantage. In each task, we may not use or describe all the command syntax. Creating new command topics that are contained in a separate command reference has been an integral part of this process. Some tasks build on other tasks, and we have developed some complex configuration scenarios that bring different tasks and different technologies together. Our metrics show that, of the technologies in our new platform, 52% are reworked. (This percentage will be higher by mid-August).

3. Transferability:

Our processes are easily transferable to other companies. The key is to define the context and basic content unit for reuse in a way that allows for analysis and mapping of content in terms of the broader taxonomy. In other companies, we often hear that reused content is moved to shared reuse folders without any context and writers are allowed to randomly reuse content, but we believe that our more structured approach has proven to be the key to our success. We initially started reusing content in some software technologies, but it was our taxonomy work that opened the door to more reuse because we had a framework that the rest of the company, and our customers, could understand. We have not fully implemented all aspects of the taxonomy across the company yet, but we have reorganized our writers and restructured our deliverables to match the software technology taxonomy. We remain flexible, and some technologies are documented in books of their own, for example, Licensing. After single-sourcing content for 11 technologies over the past three years, we have single-sourced content for 19 technologies in the first three months of this year. We believe that, with the appropriate context, other companies could see similar content reuse success.

4. Innovation:

Our innovation has been our initial adoption of an XML-based CCMS (specifically SDL Knowledge Center), which has allowed us the flexibility to implement our content reuse strategy. Developing the software technology topology and mapping our existing content into the new structure across all platforms is leading to more consistency across our deliverables. Empowering writers to become technology owners is leading to greater technical accuracy as they continue to hone their technical expertise.

5. Transformational Value:

In engineering and upper management meetings, some engineering groups have complained about the quality of our documentation. Recently, however, engineers who have been providing SME comments to our newly reworked content are turning complaints into compliments. They have noticed the multiple command task scenarios with examples, the new command topics, and they appreciate the new feature support tables that are now mapped to a similar technology hierarchy across all platforms.

6. Leadership:

We have benefitted from a strong core CCMS team and a highly supportive management team. We have provided a vision for the CCMS and we are daily delivering on that vision. Our Information Architect Designer leads our CCMS architecture innovation, and every member of the core CCMS team has contributed with projects, testing, developing process documentation, and training. We dismantled silos while still allowing release leads to lead, taught writers to use the correct DITA topic typing (concepts, tasks, CLI reference topics, and so on), and compiled writing guidelines. The writers have embraced technology ownership and content reuse. This has been a true team effort that continues to reap rewards for our entire department and our customers.