Death of the Document: It’s Time for a New Way of Thinking about Document Authoring Software
Paul Trotter, Founder and CEO at Author-it Software Corporation
When people first started creating software to automate their business processes, it was natural enough to think of it as a kind of simulator to imitate what was already happening on paper. So in accounting, for example, you got these massive spreadsheets that basically just simulated the ledgers accountants were working with at the time. In its way it was marvellous because it meant you could use formulas to add stuff up and automate a lot of the work that accountants previously had to do manually. Even so, it didn’t take long to figure out that working with your data in its final form really restricted the way that you could manipulate and control the data itself.
From there you got the database-driven systems. These offered best-of-breed solutions in very specific areas, so you had your human resources programs and your accounts receivable programs and your inventory programs. But while they were really good for what they did, you had to integrate them all if you wanted them to talk to one another, and eventually you ended up with a strip-mall of products from all sorts of different places. Not only did businesses have to spend a lot of money on integration consultants but they also tended to get stuck with the basic versions of the platforms because they’d put so much work into integrating them that upgrading just wasn’t worth it.
The third generation of software was the end-to-end systems, which could take care of absolutely everything your business was doing in one tidy package. While these were a lot easier to get going, the downside was that the single modules tended not to be as sophisticated as the best-of-breed products. Still, that was hugely outweighed by the fact they were a single product, and over time it all improved and now the best-of-breed products have all but disappeared.
That brings us to Software as a Service (SaaS), which has of course changed the game completely. Because all the SaaS products have their own API, they’re very easy to integrate. So as a customer you have the freedom to go with consolidated systems or best-of-breed solutions, whatever suits your needs. It’s flexible, it’s scalable and it’s just going to keep growing.
So, accounting software has gone through those four generations, Customer Relationship Management software has gone through them, everything has gone through them – except documentation. Documentation has remained stuck solidly in that first phase, where we’re just simulating what we’d do on paper. Even when we create Web pages, we’re still just simulating what we’d do on paper. No one has moved past that first step into a more database-driven model where you can store content and produce a variety of deliverables from that same information. The format the document is saved in has changed – maybe instead of saving in .doc we’re now saving in .docx – but fundamentally it’s still the same idea.
In fact, we’ve had to develop software around the problem, like smart search engines that can search a document to dig out the knowledge that’s stuck in there. But that doesn’t solve the problem that if you make a change to that document, you have to make an entirely new copy of that document, so you have version 1.1, version 1.2, and so on.
The solution: an Enterprise Authoring Platform
Why hasn’t documentation followed the path of other technology? I think it’s because it just hasn’t been an important part of running a business. In financials the more information you have the better the decisions you can make.
But when it comes to documentation there are only two reasons to change: when it gets in the way of running your business or when it costs you a lot of money. What a lot of business owners don’t realize is that it’s doing both of those things right now.
It’s costing a lot of money because every time someone wants to create a new document they’ve got to start from scratch and hunt around for the information – information that may be written out 10 or 20 times a day, not to mention the time spent messing around with formats. It’s also getting in the way of business because people don’t want to work that way anymore. Take training – people don’t want to sit around for a week watching videos or reading manuals; they want to learn as they go, figuring it out for themselves when they can and looking for help when they get stuck.
So what’s the solution? A mindset change along with adoption of an Enterprise Authoring Platform (EAP). We’ve got to stop thinking of the document as a store of information and start thinking of it as a deliverable that you can produce from text stored in a pure state, in the same way that a financial report is something you can produce out of figures stored in a database. You have a user interface that makes it appear that the user is working on a document; but when they type something in, the system analyzes what they’re typing and offers suggestions for what they want to say. That way everything is uniform; you can make updates without having to create new files and the same information doesn’t have to be written out over and over again.
The technology is there – we just have to change the way we think. To fix the document problem, we have to kill the document. Starting now.
This article was originally published on SandHill.com
Paul I agree with you about EAP. There is so much need for it yet most people don’t understand it. They don’t appreciate how the brain handles data, data becomes atomic and that collaberation and the reduction of duplication is the goal – for example: does the brain duplicate data?
But instead of EAP, I would prefer EKM (Enterprise Knowledge Management), because in a true EAP, the author and platform becomes irrelevant – it’s the knowledge that you are managing on any (agnostic) platform.
A full discussion of EKM is outside the scope of this reply.
Rich
Comment by Richard de Crespigny — May 10, 2012 @ 6:58 pm
There is a contradiction in this article. In the beginning, the article says database-driven systems have limitations. So, if such systems are beset with limitations, why should that model be adopted or how will it work for documentation?
Comment by Sai — May 11, 2012 @ 4:32 am
I would agree that many companies do not think of Documentation on a company-wide basis. Documentation is written by individual teams as needed. Just having an enterprise doc solution doesn’t mean anyone would buy it and implement it properly in a truly top-down manner.
If top-down doc is done, you’re talking about an Enterprise CCMS with something like Acrolinx or SDL AuthorAssistant integrated to maximize reuse. Tying in localization, if both the Loc team and the Doc team used a central Terminology database, then you’d have the optimal package. Everyone would draw from the same database, using the same tools.
The problem is philosophical, and compounds based on the company’s size, in my opinion.
Comment by Joseph Campo — May 11, 2012 @ 11:29 am
Good discussion starter, but I don’t think it accurately reflects the state of the technical writing world today.
I’ve been a technical writer for quite a while now, and I have to disagree with you that things haven’t changed. It’s been a long time since I’ve written a classic “document” such as what you’ve referred to in your article. The source content for the online help for our products is stored in a knowledgebase and updated as needed. Updates are live as soon as we want them to be, and we don’t have any sort of “version” on the entire set.
Beyond that is DITA, which I believe functions much like you’re describing. It is a database of structured content pieces that can be pulled together to produce a specific content set, just like pulling a monthly financial report. The same pieces can be rearranged to produce a different type of “document,” as needed.
Are we completely there yet? Not by a long shot. I was recently asked to update a document about an API, and it’s a classic Word document of the type that you describe in this article. But it may be the best format for the type of output needed by the audience. A database-driven solution might not be the right fit in all situations.
Comment by Steve Nay — May 15, 2012 @ 10:01 am
Hi @Rich, we selected the term Enterprise Authoring Platform(EAP) because it describes the value and capability our solution provides, and will not be confused with what other products in the Content Management, Document management, or Knowledge Management space which offer completely different capabilities. Often we integrate with these products.
Knowledge Management is such a vague term that it is very unclear exactly what is being provided. While management of the information is inherit in the Author-it platform, the primary task that we are replacing/centralizing is the authoring of content. The management is a necessary part of that, and the delivery of it to multiple outputs is a large part of the benefits users are seeking.
We purposefully used platform, because full applications/solutions can be developed on our platform using our APIs and underling capabilities.
Comment by Anonymous — May 15, 2012 @ 2:30 pm
Hi @Sai, I believe you are referring to the second paragraph, discussing best of breed systems. You may have misinterpreted the message here. The intention was to highlight that while Best of breed systems used databases, which was a positive step forward, the scope of each product was so narrow that integration was necessary with many other parts to create a “whole” solution. The integrations part were so expensive and difficult to maintain, that the were eventually usurped by end-to-end systems such as SAP and Oracle.
In documentation, this is like having one or more authoring tools, a separate CMS, and separate publishing tools. The same problems exist. Author-it is an end-to-end system, and now available as SaaS on the Cloud.
Paul
Comment by Paul Trotter — May 15, 2012 @ 2:55 pm
Hi @Joseph,
I agree that the most difficult barrier is the cultural and philosophical. We always say that our true competition is the combination of Word and apathy
Trying to change a whole organization in one step never works. We tend to start in one area then expand into other areas of need. The results speak for themselves.
Providing a common, centralized platform for authoring is a prerequisite. While tools like Acrolinx, which Author-it integrates with, bring benefits, using existing authoring tools with these enhanced proofing tools is not enough, and it is not solving the real problem, which is the document itself.
Author-it has built-in suggestive authoring memory, called Author-it Xtend, which is real-time as the user types, and much more effective than using translation memory, as suggestion are made from similar content in the source database regardless of translations, and as soon as the content has been written. The biggest opportunity to re-use content is when multiple people are working on it, not after the fact once translation has occurred. For more information see http://www.author-it.com/index.php?page=authoringmemory
-Paul
Comment by Paul Trotter — May 15, 2012 @ 3:58 pm
Hi @Steven,
I agree that many people, particularly in the technical writing space, have tried to change things, and to some degree have been successful, but they are doing so with tools and technologies designed for creating and managing documents. Mainly because that is all that is available, and all they know.
I was a tech writer for many years before starting Author-it and I tried hopelessly to bend document oriented tools and technologies to do what I wanted before I gave up in utter frustration and built Author-it.
The idea of components is not new; it’s been around for many, many years. The key difference between what we have built and what DITA is doing, is that we have designed and built a platform specifically for the purpose of component based authoring, management, and publishing. There is no document, no file, no blob of XML, only pure data in a relational database.
DITA on the other hand is just another file/document format, edited as a document, stored as a document, perhaps checked in/out to a file/document management system, perhaps just sitting on the file system. What has really changed? The size of the document? The format?
With Author-it it does not matter what kind of deliverable you want, a traditional static user manual, a help system, a PowerPoint slide deck, native XML, or dynamic website, these are all just outputs, in the same way that a Profit and Loss statement is a report out of a financial management system.
Comment by Paul Trotter — May 15, 2012 @ 5:49 pm
[...] my Death of the Document article, I talked a bit about accounting software and the way it’s evolved from the clunky [...]
Pingback by Fear of Disruptive Innovation | Author-it Blog — July 24, 2012 @ 12:42 pm