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)
Get useful tips and valuable resources every month
Join the thousands who know just how much we share.