The "System" in CMS

Since I am having trouble untangling what I would like to say about maps and the way the delivered document hierarchy is produced to the point where the resulting post might be short enough that merely contemplating reading it would not crush the spirit of anyone so brave as to entertain the notion, I'm going to produce something of a meta-issues post instead.

A content management system is a system; that is:

1. A system is an assembly of components connected together in an organized way.
2. The components are affected by being in the system and the behaviour of the system is changed if they leave it.
3. This organized assembly of components does something.
4. This assembly as a whole has been identified by someone who is interested in it.

This understanding of system has a bunch of implications for both what you decide to implement, and how you decide to do that. I'm going to cover three of them.

The Purpose Of A System Is What It Does

This becomes the acronym POSIWID. Initially, the idea seems tautological; of course the system does what it does, it exists to do that, doesn't it?

There's a sort of mental trick involved, similar to looking at a clear night sky (somewhere there is little or no light pollution) and seeing it as something with depth, rather than little lights stuck to a firmament.

In the system case, the trick is to see all the results and side effects of the system, including the bad results, as what the system is designed to do. You should not presume malice, but equally you should not accept unintended side-effect as an explanation. If the CMS you're using causes suffering, causing suffering is what the CMS is for. (Hopefully, causing suffering is not all of what it is for.)

Since a DITA CMS will be new, and people will have to learn it, and change how they do things, and take a chance on blown deadlines the first time they do something deliverable with the CMS, there's always going to be some initial suffering, or at least anxiety, involved. That's not the suffering I mean; that, hopefully minor, suffering is the price of change.

The suffering I mean is the suffering that arises when you know how the system is supposed to work, what to do with it, and wind up suffering anyway. That kind of suffering is an indication that you need a different system.

Maybe a little different—changing the way the search dialogue works, or altering how the output processing handles notes—or maybe a lot different—changing XML editors, or the way XML validation rules are applied—or maybe completely different, and you start over.

Any implementation is going to need a little different levels of change to correct suffering in use. A well-specified, well-planned implementation should not ever wander into the a lot different or completely different categories unless some radical technological change occurs.[1]

You Get What You Reward

People are not the whole of the system, but people are, must be, part of the system. People are also both self-adjusting and markedly difficult to adjust in the sense that you can adjust the user interface colour scheme.

One of the traps with setting up a DITA CMS (or any other technical documentation CMS) is to make it systemically permanently new, and thus hard, and it therefore becomes and stays laudable to use the thing at all.

Other areas of endeavour with content management treat the content management systems as essential and normative; you can't do the job without one. (Consider the reaction of the people setting up a corporate finance system being asked to do it without a database, too.) Because so much technical documentation is still done as what is effectively piecework by individual craftsmen, the expectation that of course you're going to be doing this as part of an industrial, distributed, staged production process with formal divisions of labour and as much automation support as practicable to get productivity up simply isn't there. That expectation of piecework is going to conflict, badly, with a DITA CMS; the better the CMS is, from the point of view of potential productivity improvement and automatic support of those functions (like output, managing work order, and distributing effort by defined role) that can be automated, the worse the conflict will be.

So it's important to decide what you want—I could say effectiveness, but that's palming the card; what constitutes effective for your organization is something you know and I don't—and make sure to reward that. I caution only that you don't want to reward the presumption that DITA, XML, or your CMS are, individually or severally, difficult to use.[2]

A Viable System Is Built From Viable Systems

A clever fellow named Stafford Beer invented the Viable System Model to describe how organizations work.

The whole of the viable system model is something you can easily search for; the article under the link is a reasonable overview from the viewpoint of knowledge management. The point I want to make here is that systemic viability is recursive, in the systems sense of recursive; what looks like a single unit of production ("Implementation", Level 1 and the most basic level of the model) can contain an entire complete system itself. (In much the same way that your body, a system, is made out of cells, which are systems.)

The example usually given is how a subsidiary manufacturing plant is a whole viable organization itself but is seen from head office as simply that place where they make pop rivets and other fasteners. The example I would like to give is the individual writer; they're going to be doing Implementation, Co-ordination, and Control[3] with respect to their unit of production, the DITA topic. If the system does not work for them, it won't work, period, because the broader levels of organization (assembly of topics into maps to meet deliverables, discovering the appropriate persona and scenarios to meet your customer's information needs via scenario based authoring, etc.) are all dependent on the basic production layer working.

Software design might refer to this as getting the primitives right, where primitives are primitive operations; I might refer to it in terms of the meta-data information stratigraphy necessary to get from version control to scenario-based authoring, where it does not good to have a higher layer if you don't have the layer it rests on.

The whole system is made up of a group of smaller systems. The members of the writing team must understand topic-based authoring as an objective before they can write topics. Topic production must work before maps will work. Maps must work before you can attempt scenario-based authoring.

The implication of the necessary systemic recursion, in the pleasantly theoretical general case, is that when you implement your actual, concrete Content Management System, you need to build it, or, if you're buying an existing system that has all the pieces, start using it in the appropriate order. This also means that you can't go on to the next, increased level of complexity until the current level works. If the current level of system doesn't work, the next level can't.


[1] For "someone creates an XML editor that's completely intuitive to the naive user", or "someone starts selling a quantum tree transformation processor for cheap" values of radical technological change.

[2] There had better not be any factual support for "this CMS is difficult to use", either.

[3] Levels 1, 2, and 3 of the Viable System Model. All five layers are Implementation, Co-ordination, Control, Intelligence, and Policy.