This blog post is about your business processes, particularly those surrounding the ways your content is authored, managed, approved, and published. Think about the way those processes look today: the people involved, the tools you use, and finally the workflow, whether that’s an ad-hoc peer review or a highly formalized set of approval gates and feedback loops. What are some words that you might use to describe those processes today?

If you’re like a lot of your peers, chances are you came up with something like the following:

• Inflexible
• Time-consuming
• Non-collaborative
• Siloed

Sound familiar? We’ll talk in a moment about how some of those challenges can be addressed. But first, I want to tell you a story.

The Industrial Revolution

During the late 18th and early 19th centuries, factories sprung up throughout Great Britain. These were most notably involved in the production of textiles to feed the British global trade empire. Gains in productivity (and eventually standards of living) were enormous, as machines were used to weave fabrics much faster than any human hand could.

All of these machines were powered by a recent and wondrous invention: the steam engine.

To deliver power to the individual machines, the factory had to be configured in a very specific way. There would generally be a centrally-located steam engine, which would turn crankshafts that ran then length of the factory floor. Then, leather straps were used to power each machine. It was a bit dangerous – many workers lost one of more fingers to these contraptions – and it looked something like this:

Factories were frequently multi-floor facilities, built that way to accommodate as many rows of machines as possible. Individual machines could not be switched on independently of the others, either – it was an all or nothing affair.

Does any of this look or sound familiar? Think back to those words you thought of to describe your current content processes – and remember, this may look archaic and backwards to us today, but this is how a revolution started!

Electrification of factories

With the advent of electricity, a more efficient means of powering these machines became available. The first factories to electrify simply tore out the old steam engine and replaced it with an electrical one. The machines all stayed in the same configuration as before and gains in productivity were minimal at best.

Why was this? What mistakes were made?

The problem was that the factories were originally designed to accommodate the needs of the available technology; in this case, the steam engine that powered the whole thing. Simply tearing out one technology and replacing it with another wasn’t going to make much difference one way or another.

What they were missing was the fundamental advantage electricity provides: the ability to move the machines away from a configuration based on a centralized power source and into one that facilitates efficient processes.

It was only after factory managers started to redesign the layout of the factory floor itself that the real power of this new technology was realized. By arranging the machines so that work flowed efficiently between various stages in the process, productivity went up and the elimination of all those leather straps meant that more of the workers got to keep their fingers!

It’s not (all) about the technology

So what can we, as content creators, learn from the textiles factories of a century ago? What did they do wrong that we can do better?

First, we can understand that technology alone is not the answer to (or the cause of!) all of our problems. We can’t just swap in new technologies, like DITA, and assume that everything will magically become more efficient.

Yes, authoring structured content can drive efficiencies in terms of content reuse, decreased translation costs, and collaborative writing, but DITA is not a magic bullet by itself. We need to think carefully about not only our processes – how is content authored, reviewed, approved, and delivered – but also about the people who touch our content along the way.

It IS about flexibility

One of the first DITA projects I worked on was bound from the beginning by unrealistic expectations. For years, we had been authoring content in traditional desktop publishing and HAT tools. There was little reuse, and some very well-established guidelines for the look and feel of the deliverables.

Going into the project, one big assumption was that we needed to replicate this look and feel more or less exactly, using DITA-OT instead of the proprietary publishing engines of the legacy tools.

It was a lot like yanking the steam engine out of the factory, replacing it with an electric dynamo, and expecting everything to magically work. Instead, there was a lot of reverse-engineering of page layouts and dynamic behaviors in HTML output, and we never quite got there.

Eventually, we figured out that this was an opportunity to redesign and modernize or deliverables.

We stopped trying to reinvent the steam engine and reconfigured our factory instead.

And let’s stop with all the dead trees

Traditional publishing solutions are a one-way street that also happens to be a dead end. Once we’ve got all my content written, reviewed, and approved, we click a button and eventually we get a PDF, or a webhelp system, or maybe even a .chm file.

And once we’ve done that, the content can never come back. We can’t get feedback on it (at least not directly), we may not be able to tell who is using it, and how often, and we certainly can’t do anything like dynamic updates. Your content is stuck on a one-way, dead-end street.

True dynamic publishing can get our most up-to-date content into the hands of our readers immediately – as soon as it’s approved, it’s available.

If your content can’t be published to a live knowledge base or portal, it’s stuck traveling down a one-way, dead-end road, probably in a steam-powered car. What we need to think about is building a “content service” that makes your content available not only to PDF readers, but also to dynamically updated web portals, and other applications as well.

Monolithic documents are steam engines

One place I still see a lot of this is with review and approval processes. Structured authoring requires us to chunk our content in such a way that those unfamiliar with the strategy sometimes can’t wrap their heads around it. They often want to see “the whole document” – really something they can scroll through – before they feel comfortable approving it.

Sometimes, this is because topics are too small. More frequently, it’s just the fact that people like processes they’re already familiar with. And everybody wants to provide their feedback. On everything.

But as content professionals, it’s our role to help move the needle on the benefits of structured content.

I’ll talk about that in my next post.