In this paper, I discuss how we made single-sourcing work at Juniper Networks. This is a practical discussion of issues, problems, and successes.
This paper provides a case study in single-sourcing, examining how the Technical Publications group at Juniper Networks has been implementing single-sourcing. In the past three years, there has been much theory about single-sourcing, but not enough practice. The literature is full of information about single sourcing from a theoretical perspective. So, this paper is more about what isn't covered in the literature than what is.
For example, it's not about how to choose a tool or evaluate a product, how to code XML, how to get cost savings through single-sourcing, how to write modularly, or how to structure your documentation. And it isn't about amazing product features, the Juniper Document Definition, the Juniper-specific applications that we developed.
Most importantly, this paper is not a set of generalized rules for making single-sourcing work. It is one long a concrete example because, in the end, that is what the developer of a single-sourcing system needs to see. And interestingly enough, it's what the users of that single-sourcing system need to see, too.
Presented by: Liz Fraley, Single-Sourcing Solutions, Inc.
Presented at: Association for Computing Machinery's (ACM) Special Interest Group for Design of Communication Conference 2003 (SIGDOC 2003)
Presentation materials:Tooltip Text
You might also be interested in...