For almost as long as I can remember, pitchmen (especially on late-night TV) have been selling all-in-one gadgets that slice, dice, puree, and do pretty much everything.
In our world of technical communication we have something similar: “soup to nuts” authoring systems that combine all the major steps of the content workflow under one banner:
- Creating content
- Managing content
- Reviewing
- Publishing
This is actually a thing — but are you using it in your kitchen? (Source: Nostalgic Electrics)
Vendors have been offering systems like this for several years. The sales pitch is alluring: unify all of your content under the banner of one integrated toolset. Lots of content, a multi-step workflow, and one brand to rule them all.
Yet I don’t think I’ve ever seen a company, or even a decent-sized organization within a company, use one of these single-vendor systems for its entire content workflow.
I’ve used parts of these systems. For example, I’ve used easyDITA for content management and publishing, but not for content creation and reviewing. I’ve used XMetaL, but only for creating and publishing content.
In fact I’ve never used these systems for reviewing. All of my SMEs have said the same thing: “Give me a Word document or a PDF that I can mark up. Don’t make me learn a new tool.”
Do any of you use a single, soup-to-nuts system to create, manage, review, and publish content? If so, I’d like to hear from you. Is it working well for you? How easy was it to set up, get buy-in from content producers and SMEs, and train everyone?
Toward a unified content strategy
Despite the sales pitch, I think the soup-to-nuts approach actually works against the goal of a unified content strategy: a situation in which all of the company’s content is brought into harmony, is governed by the same set of rules, and reflects consistent messages and branding.
Why is soup-to-nuts incompatible with this ideal? Because in the real world, rolling out a unified content strategy requires buy-in from different organizations within the company and then settling on a common, or at least compatible, set of tools and processes.
If the Marketing department is developing content in InDesign and Word, and the InfoDev department is developing content in FrameMaker, it’s probably easier to take an incremental approach to blending the two workflows. Start by agreeing on a single publishing methodology, for example, that accommodates both content-development workflows. Then agree on a reviewing process. Then agree on a standard way of creating and managing the content. Then, finally, if you’re really feeling brave, convert your legacy content to work in the new system.
In the meantime, since the goal is a truly unified content strategy, other parts of the company ought to be coming on board. Mergers and acquisitions further complicate the process. At every step, stakeholders are more apt to succeed when they take the incremental approach rather than the all-or-nothing, soup-to-nuts approach.
Soup-to-nuts – or just a couple of courses?
So, is soup-to-nuts what we need for developing content? Obviously, there are some vendors that think so. And I guess they’ve persuaded some of their customers, or the systems wouldn’t still be on the market.
Do companies buy the soup-to-nuts systems and then use only pieces of them? That’s been my experience.
Or are some of you using them as their creators envision: one brand name, one process, for the whole workflow? If so, again, I’d like to hear from you: is it working well? Have you encountered any unforeseen challenges? How well have you overcome them?
I’m not secretly trying to sell you a product or even a particular approach. I’ve got an open mind. It’s just that there seems to be a disconnect between what the marketers are selling and the way the real world works. It would be good for us, as a profession, to talk about it.
Leading Technical Communication 
I work for easyDITA and as a DITA CCMS, we are obviously believers in the end to end workflow; in fact we are doubling down on it and will be introducing a Review function that gives SMEs a tool that works like the familiar tools they are used to but sits in the centralized database that drives structured content. The approach of using a set of unconnected tools goes against the huge advantage of not allowing content to be duplicated, something Word is totally reliant on.
Thanks, Martin. I appreciate your taking the time to comment, and I look forward to seeing the new review function in action.
It’s funny that you wrote on this particular topic this week. I spent a few hours (yes, hours!) this weekend shopping online for a replacement computer bag for its well-loved and all-too-well-used predecessor. I kept going round and round on the product comparisons until I realized my problem: I needed to cover two very separate use cases. So I bought two bags, each much better suited to its corresponding use case than any one bag would have been.
At work, we’re also migrating away from attempting a one-size-fits-all approach. My team develops its own and integrates third-party authoring and publishing tools for inside-the-company use. The dilemma is that our content development requirements are growing more and more diverse over time, at a time when we collectively have fewer resources than ever. So we scrubbed down our tool set (some components of which went back 20 years) into a set of loosely integrated services. This year, we’ll work with our stakeholders to refine the services we provide AND do our best to identify emerging gaps in coverage. So much for one-size-fits-all 😉
Thanks, Susan. Your experience, both with computer bags and content-development systems, sounds similar to mine. I like your use of the phrase “loosely integrated”: the tools and services play well together but are nimble enough to address a range of requirements.
There is a fundamental moral hazard for the developer of any soup to nuts system. They are paid based on some formula or another that amounts to time in the interface. Therefore they design systems that require the maximum time in the interface.
I used to work for a company that made a content automation tool. It was originally licensed as using a licence server and you paid based on number of concurrent licence tokens the users needed. As corporate networks grew to connect all the offices of a company across the world and as computers became ever more powerful, this economic model became untenable. Even the needs of a vast organization could be met by purchasing a single server token, since jobs completed in seconds and a single license server could be accessed from anywhere in the world.
There are variation on how you can do the licensing for this kind of product, and corresponding variations on how an organization can get round them. There is a reason that most automation tools are open source today: even though our IT systems depend on them: it is very difficult to devise a viable economic model for selling them. Thus key parts of our infrastructure are open source projects that are essentially funded by for-profit corporations who make their money selling other products and services that depend on that infrastructure.
Now lets suppose that we could design a content system where content could be written with very simple tools using a markup language that anyone could learn in a few minutes (like MarkDown, but not MarkDown), and that involved no esoteric concepts that were difficult to understand or that required any knowledge of how the content system worked. Suppose that you could use many different methods to engage stakeholders at the touch points. Let’s suppose that very little in the way of complex content management was required and that something like GitHub would suffice as a repository for most organizations. And let’s suppose that all of the linking, organizing, formatting and publishing could be done automatically by scripts with no human intervention.
Would that system be highly desirable and make documentation departments more effective and productive? Of course it would.
So why are there not multiple vendors selling such systems? Simple: because there is no economic model that allows them to make money selling such a system. Processing power is too cheap and abundant for them to make money on the back end of a system. The only way to do it is to create a system that requires most people using the system to be tied to the licence-paid interface for most of the time they are working on the project. So the products that they design and offer for sale are designed to be interface intensive, to require constant interaction with a highly complex system through a proprietary interface. It is a basic moral hazard that means the best system for the customer will never be offered for sale because there is no way to make money from it.
Of course, there are the Docs like Code people, who are doing something similar to the system I describe above, with the significant exception that they are using Markdown, which means they can’t do anything like the kind of sophisticated automation that is actually possible. Even so, that model is highly effective for many organizations, and it is implemented using almost entirely open source software.
Is a vendor going to jump on the Doc like Code bandwagon and attempt to serve that market? Not likely. The fundamental moral hazard says there is no way for them to make money from it.
And so we are likely to see the situation you describe continue: People buying soup to nuts systems because that is all vendors have an economic incentive to offer, and people choosing to use their own nuts because the stuff that comes with the soup is mostly stale and mostly peanuts.
Thanks, Mark. You make a persuasive case for why things are the way they are. I am, however, seeing an increasing number of “lightweight” content editors and CMSs — a few of which are even being offered free of charge. I imagine that vendors offer these tools as a means of getting their collective foot in the door: to establish a business relationship with a company and then sell them higher-priced, perhaps even unrelated, tools and services. Is that your perception as well?
Certainly. The freemium model is well enough known. But in order for it to work, there has to be some component, that you need to get full functionality, that you will have to pay for. The freemium strategy can increase a technology’s footprint which lessens the barriers to entry — there are more people who know how to use it, more information about it, etc. But the design imperative remains the same: the premium version needs a viable economic model, and so the free stuff still has to follow the same design pattern: it has to interaction intensive.
We should note in this regard that being interaction intensive does not mean that you have to make you money on the editor. You can make it on CMS seats just as well. The key to that, though, is the the system has to be designed to require a live CMS link through all or most of the each user’s interaction with the system. DITA is almost perfectly designed for this purpose. Its ad-hoc reuse tools more or less demand a live connection to a server so you can see the result of your reuse in your editor. If your reuse were algorithmic and semantically driven, you would not need the live connection. Indeed, the author would not explicitly know that reuse is happening. But DITA is all about hand-built reuse. DITA has the perfect economic model for consultants and system vendors, which is the largest reason for its success of late.
But, as you point out, users are not actually thrilled with soup to nuts systems, or with the interface complexity that is essential to their economic model. Thus you get things like Wikis and Docs like Code. It is worth noting just how much simpler such solutions are compared to any of the commercial soup to nuts systems. Less full featured, perhaps, but radically simpler, and many companies seem to be finding that an acceptable trade off.
With the right techniques, though, it is possible to get back a lot of the functionality without compromising the simplicity or re-imposing an interface intensive user model.
Hi Larry,
Firstly, thanks for writing this article – it was a great read. I totally get why you might be skeptical towards ‘soup-to-nuts’ authoring systems: but I’d like to share some of my positive personal experiences working with such a system, namely Atlassian Confluence.
The company I work for (K15t Software) uses Atlassian Confluence in combination with several of our own Scroll add-ons for all aspects of content management – including our internal knowledge base, user help centre, blog, website, and pretty much everything else, too. Everyone in the organization works together on the same platform – completely avoiding the creation of departmental knowledge silos, and giving everyone access to all the information they need at all times.
We author help content in Confluence and use the Scroll Versions add-on to manage and publish multiple documentation versions. Scroll Versions even has an integrated workflow feature, so you can use it to manage the reviewing process, too. We also work with an add-on called Scroll Viewport that takes Confluence content and adds a web theme for a better viewing experience. If you want to learn more, there’s plenty detailed information on our website: http://www.k15t.com/solutions.
The setup supports our agile documentation approach (we are big believers in the ‘DocOps’ philosophy) and means that everyone on the team can make changes to content. From a technical writer’s perspective, it’s really great being able to have my work checked by our developers from within the same system that they use for their own work.
As support and documentation are both managed within the same team at K15t Software, collaboration works like a charm when it comes to updating the docs. Whenever a customer indicates that a doc page is unclear, our agents either directly make the change (if it’s minor), or create a JIRA task for me (the company’s tech writer), and then I can work on the docs and add whatever is missing. (For that, I do require access to our Zendesk system to let me access all the information, but that’s not such a big drawback).
I must admit that I’m a bit biased because I work for the company that makes these add-ons. But the positive customer feedback we get confirms my opinion that this is a really solid setup – for a thorough overview of how the whole thing works, see this blog post about how CA use a similar system to power their DocOps approach to delivering technical content: https://www.k15t.com/blog/2014/12/webinar-how-ca-technologies-broke-the-rules-the-docops-approach-to-agile-technical-content.
I hope that this short introduction to how I work in a ‘soup-to-nuts’ content management and authoring system managed to provide some insight into the benefits they can have. If you (or anyone else of course) have any questions or comments I’d be delighted to discuss this topic further.
Cheers,
Tom Walker.
Thanks, Tom. I appreciate your sharing your story. It’s exactly the kind of story I was hoping to hear.
It interests me that everyone in your company is using Confluence. Am I right in assuming everyone was using it right from the beginning? Or did you go through a process where some people had to give up their old tools and start using Confluence? If the latter, I’d be very interested in hearing how that was accomplished so successfully.
Also, if I may ask, how large is your organization — both the total size of the company and the number of people whose main job is producing content? I would expect that a smaller organization would be more apt to settle on a single tool. But your experience might prove that is not the case.
Hi Larry,
First of all I’d like to apologise for replying to you so late – I actually tried to post this message several times last week, but it seems there were some issues with the comments system that stopped the reply from being posted. Now I’ll get back on topic:
Everyone has been using Confluence since the company began – it’s always been integral to how we work. That means we’ve never really had to migrate on a large scale from one content editor/CMS to another, so I can’t comment on that out of personal experience. However, we did successfully migrate our website management processes (including content management) from another tool to Confluence (in combination with our Scroll Viewport add-on) a number of years ago, and from everything I’ve seen, I’d say that whole process has been successful.
K15t Software has almost 40 employees in total, and there are about 7 of us who are regularly involved in content creation. However, there are multiple examples where large enterprises have successfully used Confluence with Scroll add-ons for documentation authoring and publishing. Two examples I can think off of the top of my head are CA (https://docops.ca.com/home) and Atlassian (https://confluence.atlassian.com/alldoc/atlassian-documentation-32243719.html), both large companies who have achieved (in my opinion) good results using a setup like this.
I hope I’ve managed to shed some more light on the situation, and I’d really like to discuss this further if you have any more questions.
Cheers, Tom.
Thanks, Tom! That’s good information, and it sounds like a good success story. I encourage readers to check out the links you provided for more information.
Pingback: Questions from the old year, questions for the new | Leading Technical Communication