Tesla

An Introduction to Single-Sourcing: Definitions and Real-World Considerations

Can single-sourcing save you time, money, and rework? In most cases the answer is yes, if you can devise a system that meets your organization’s requirements. This article describes single-sourcing and outlines one basic method for identifying single-sourcing requirements.
What is Single-Sourcing?	You can describe single-sourcing from several different perspectives, but many basic, general descriptions include these concepts:The idea of one central repository, or data layer. This can be any sort of data or content, authored in any proprietary or out-of-the-box tool. Your repository can be a set of FrameMaker files, Microsoft Word files, XML files, or structured entries in a custom database. A truly usable single-source repository manages all special cases (such as conditionalization, tagging, or variables), removing the need to tweak any item specifically for any given deliverable. This means that, for example, you tag all your UI field names the same way within the repository, and later your conversion layer interprets that special case to create the appropriate visual representation of your UI field names in each deliverable format you must produce.Next, the concept of systematic recreation, or a logic/conversion layer that takes your raw content from the repository and transforms it into one or more different deliverables. Your conversion layer can take many forms. It can be a tool like WebWorks Publisher or Doc-to-Help, or a custom UNIX script that takes your raw content, transforms it to XML, then uses style sheets and customized web-ready templates to create printed or online documents.Finally, the idea of several different deliverables, or presentation layers, which vary in format, content, audience, scope, or style. These deliverables–be they HTML files, PDFs, Word files, XML+style sheets, or other custom file formats–may differ across various customers, audiences, or products; they may also need to meet various translation, internationalization, or other customization requirements. The key is that all deliverables are created from your single repository without your needing to manually tweak the deliverables after they’re generated.At present, most of the best single-sourcing information you’re going to find is contained in books and articles with “Content Management” in the title. However, it’s important to realize that single-sourcing is not equivalent to content management. Content management is broader than single-sourcing. It includes many more functions, such as completely separating content from formatting, version control and revision tracking functions, workflow management, and repository administration. A full-blown content management system (CMS) is not required for single-sourcing, but it can be helpful, especially if you’re dealing with extensive content or numerous writers.
Devising Your Single-Sourcing Scheme	There seems to be an impression that single-sourcing can only be done with months or years of lead time, with return on investment (ROI) evident only years later. However, it is possible to implement a small-scale single-sourcing project in a matter of months, if you’re working with a small amount of content, few writers, and established tools that support a scheme that meets your requirements. But no matter what your timeframe, understanding your organization’s single-sourcing requirements is essential to crafting a usable, efficient, and scalable implementation.Here is a basic methodology for crafting a single-sourcing scheme. Keep in mind that, depending on the size of your organization is and how much content you’re working with, each of these steps could take a few days to several months to complete.1. Analyze your deliverable needs/presentation layer: “What deliverables must we produce?”Most people are thrown into single-sourcing because they receive requirements to produce new deliverables. So the first step is usually to determine exactly what types of deliverables are required, what basic content must appear in each, and what look and feel constraints you have to work with.2. Analyze your existing content/data layer/repository: “What content do we have, and how is it structured?”Next, determine if your existing content is structured to meet your deliverables needs. Be aware that content analysis is a large topic, and there are several content analysis methods you can use. The goal is always to determine if your current authoring environment and methods will support the deliverables you need, without tweaking each one after generation.3. Plan to manage your content reuse/conversion layer: “How will we convert our content into the required deliverables?”Once you’ve analyzed your deliverables and your content, you must decide what sort of reuse scheme will best fit within your organization. Ann Rockley describes two models of content reuse; most implementations use a mix of both models.Opportunistic reuse requires each author to know that content exists and make a conscious choice to reuse it. It is the most flexible method, but it requires some level of human involvement to be implemented correctly. You may have to document where the content lives, how to correctly import/reuse it, when NOT to reuse it, and so on. The ROI tradeoff for this method involves the amount of human effort required to maintain the scheme vs. the flexibility each author has in deciding when and where to reuse.Systematic reuse relies on one or more tools to insert content programmatically. Metadata is required for cataloging and retrieval, so someone in your organization must manage that task, to ensure that the proper content is reused in the places it needs to be. This method is less flexible and more expensive, but can produce more consistent results because there is less room for human error. Extensive systematic schemes may require metadata management, fully automatic updating, and workflow management functions that are best served by a full-featured content management system.4. Choose tools: “What tools support our deliverable, repository, and conversion requirements?Except in cases where you know from the outset that you are limited to only the tools you currently have, the tools you choose for your single-sourcing scheme should not be your focus or starting point. Your tool decision ideally happens after you have thoroughly analyzed your deliverables and content, and once you’re clear on the amount of human intervention vs. systematic constraints your authors are willing to live with. Ideally, your chosen tools should be the means to an end—meeting your repository, conversion, and deliverables requirements. Tools are therefore ideally chosen as the last step, and should not be the driving force behind the structure of your implementation.Tool decisions almost always incite debate. In the end, each organization has to choose whichever tool meets their unique requirements, fits into their organization culture, and falls within their time and budget constraints, even if that means choosing an unpopular tool or figuring out ways to work single-sourcing in with the tools they already have.It’s easy to be awed by tool vendor presentations that show you completely new ways you can structure a repository, manage extensive reuse methods, or create various deliverables. But always keep your organization’s specific deliverable, content, and reuse method requirements in mind. A tool that perfectly meets the requirements of some other company may be a terrible fit for yours. Your tool choice must meet your repository, conversion, and deliverables requirements while also fitting into your organization’s culture. Most importantly, the tools you use must leverage the amount of human time and financial resources you have to invest in a single-sourcing scheme.Single-sourcing does require some up-front planning, but the return on your investment in terms of time, money, and rework can be substantial, even after just a few months. Starting with a small project is usually a good trial run for any plan you devise. Don’t be intimidated into thinking you have to change everything to single-source. There are an unlimited number of workable single-sourcing implementations. The key is finding one that works most efficiently for your situation.