Why do enterprise documentation teams need component content management?

A few years ago I was talking to a documentation manager who described her workflow to me. She was updating a warning label, which she said she was updating in 23 places, and was worried she was missing 4 more. She was using a spreadsheet to track a spreadsheet that tracked her updates to the content.
Most teams reach the wall after around 5-10 employees. After that documentation simply becomes too much to handle and will start to take over the entire team.
The thing about scale that nobody warns you about
Copy and paste is a fine system when you have 5 products and 2 writers and everything is in 2 places. But once you have 10 products, 5 regions, 10 compliance requirements, and 8 languages — then you’re localizing online product description content on 23 different online product description channels. Yes, this is a real scenario that I have seen. It is not pretty.
The issue is not that teams are disorganized. No, the issue is that documentation was written for documents, not for content at scale. Managing content at the enterprise level means thinking less like a writer and more like an architect — designing structures that can flex, recombine, and hold their shape even when the ground shifts. That’s a fundamentally
The traditional documentation model for finished items (documents). The new way of managing content at the enterprise level, to manage the growing amount of content, for re-use in different finished items. A single source of content for different combinations of finished items. Architectural models of buildings are created by architects to represent possible finished buildings. Finished documents created by writers as models of finished written information.
What component content management actually changes
A Component Content Management System (CCMS) is a system that treats content as components or building blocks of content. Each component is a self-contained piece of content, for example, a warning, a procedure or a product specification. That same component is stored once in the system, and then it can be used in many output channels such as web pages, PDFs and printed documents. The same single source edit to a component is then automatically published to all places in the system where that same component is used. Seeing all those edits to a component automatically published in forty or so different documents in one place is a very powerful experience for any writer.
Here is what changes for your team when you stop making copies of your content:
- Updates happen once, propagate everywhere. Change a regulatory notice in the source component and every document referencing it reflects the update automatically.
- Errors become far less likely to hide. There’s no version drift, no “which PDF has the right torque spec” scramble.
- Localization costs drop significantly because translators work on each component once, not every time it appears in a new document.
- Writers spend less time hunting and more time actually writing.
Reuse is only half the battle. A team can be superb at Reuse, yet struggle desperately to enforce a set of solid Governance rules on the very same pieces of content that they managed to Reuse so effectively. Unfortunately, most teams do not have sufficient experience in this area to fully appreciate just how difficult it is until they are right in the deep end and drowning.
Governance isn’t glamorous, but it will save you
A key aspect of ensuring compliance with regulations within documentation is potentially very expensive. We have already touched on the area of formatting which could lead to extreme costs should an error be found. However, there are potentially even greater costs in relation to product recalls and possible fines for non-compliance with regulations. The greatest potential for cost is however, a potential disaster of a different kind. Imagine that your organization has a critical safety instruction in place that must be followed to avoid serious injury or even death. However, there are three different versions of this safety critical instruction currently in circulation. The worst case scenario would be that the worst version of the safety critical information is followed with potentially tragic results. This is a scenario that many documentation managers currently fear and it is a very real problem that documentation managers are currently trying to solve.
A CCMS is a tool for enforcing a certain structure of your content. That means your authors will be working in a certain way within a certain framework of rules that define how topics and procedures can be put together in the best way. The process and methodology of structured authoring supports this kind of workflow. DITA is a widely used standard for the creation of structured content in many industries. Topics created in DITA according to a strict set of rules for organization and makeup can be reused in many different outputs and in many different channels. In conjunction with a CCMS, topics created in DITA can be managed, tracked, and published in ways that unstructured content cannot.
But for most large companies, approval workflows, and other CCMS features are considered ‘advanced’. And for that reason, the tools are used for something that you are extremely grateful to have when something goes wrong with the documentation. For large companies with documentation at the enterprise level, something goes wrong. And the only question is, will you have a system of governance in place to approve documentation changes, or to fix documentation mistakes quickly? Most companies do have documentation at the enterprise level that needs to be maintained by a team. The real question is, does your team have the right tools in place.
(And yes, the features of a CCMS which have the greatest impact on winning management approval for a CCMS are the governance features. Writers and others can be easily convinced that the other features are a good thing, but it takes a lot of convince to get them to see the features of a CCMS which enable compliance as a good thing. Money talks, and nothing says money as much as saving it from potential penalties.
On localization specifically
Localizing content without a CCMS is similar to performing an operation with gardening gloves. It can be done, but it is not very sensible.
Modular content is also easy to translate and integrate into the Translation Memory of your localization tool. Instead of having to send off 200 page PDFs to translation, you only send off the single components that need to be translated. These are then automatically assembled into a new document. Repetitive content is only counted once. This also means that Reviewers only have to approve single components instead of having to search through and through in a 200 page document for the 3 changed paragraphs. And when the source content is updated, you immediately know which translations need to be updated instead of having to search folder after folder for the right Word file with the right version (e.g. “UserGuide_FR_v4_FINAL_revised”).
So which system should you actually use?
Now that we’ve established the value that a CCMS can bring to documentation, it’s worth taking a look at what systems are available and which might be a good choice for your organization. It’s not easy to present a perfectly neutral view of the CCMS market given that IXIA (now part of MadCap Software) is the maker of the IXIA CCMS system, but I believe that the strengths of that system along with the value that it brings to users make it worth taking a hard look at as a potential choice for your organization. The system is particularly well-suited to support large, enterprise-level documentation efforts, especially those that are based on structured authoring and that make use of DITA topics. It has a number of strong features, particularly when it comes to localization and to support for rigorous governance. Such features are critical for organizations in industries such as manufacturing, government, software, and technical publishing.
There’s a simple before and after diagram that nicely demonstrates the large improvements made to documentation by large enterprises using Single Source documentation systems.
| Area | Without a CCMS | With a CCMS |
| Content updates | Manual edits across multiple files | Single-source updates, automatic propagation |
| Localization | Full documents sent for translation repeatedly | Components translated once, reused everywhere |
| Governance | Informal, inconsistent review processes | Structured workflows, audit trails, permissions |
| Version control | Filename-based (“final_v3_REAL.docx”) | System-managed, tracked, reliable |
And now we get to the really hard question: What is the cost/benefit to your organization of a CCMS? I went through the above list, put numbers next to each item, and my wincing ceased as the cost/benefit clearly shifted to the positive side. Yes, there’s the loss of automatic version control (as opposed to manually updating a field every time you save a file), but the benefits to your team, to your content, and to your organization are such that…
Limitations of CCMS Systems and Benefits to Authors and Writers
We want to make it clear that a CCMS does NOT solve ALL problems with documentation. Writers must still make good decisions. Subject matter experts must review information in a timely manner. The content strategy is still important and cannot be automated.
A number of problems within documentation teams at companies revolve around documentation as a workflow problem rather than a content problem. The root cause to many problems facing documentation teams, though, tend to reside in the documentation’s infrastructure. So long as a writer is saddled with terrible documentation infrastructure, they’re going to be working within a set of problems. There’s a terrible tendency for people in power to blame documentation teams for not meeting impossible targets, telling the writers that if only they worked longer, all would be well. But the reality of the problem, the root of the problem of a writer struggling to make headway with 23 labels of warning (in different states of completion, naturally) — all spread across hours of the worst sorts of spreadsheets — is that the writer is working within a terrible documentation infrastructure problem that’s been painted as though it were a completely normal part of writing and that the writer just needs to work harder. But that’s not true.
Once you have stripped away the additional processes and items of little value that are put in place because of lack of proper documentation processes, and are left to do the writing of good documentation, it’s amazing how little time is required to generate really great content. However, as I alluded to previously, writing great documentation is not a solitary activity and there are many people and factors that can influence the process. These include subject matter experts, management, as well as internal and external policies and procedures, and even external regulatory bodies. Documentation can also be very political and in many cases used to further one’s career. Often the reason that people create and manage so much content is for reasons that are not healthy for the organization.



