Continuous Publishing for NonStop Customers
What Is Continuous Publishing?
Continuous publishing, as implemented by the NonStop Enterprise Division (NED) of Hewlett-Packard Company, is a combination of automated processes that update Web sites with information slated for publishing. The system updates or replaces existing information and also publishes new information on its release date. The customer-accessible information is posted on the NonStop Technical Library (NTL). Customers can configure NTL to display a personal view of information that has changed since their last visit to the site. NTL is available to the public at www.hp.com/go/ntl.
Why Do We Publish Continuously?
NED creates computer hardware and software that companies use to run systems and applications that need to be up all the time or nearly all the time. For example, NED systems power many financial applications, such as ATM machines, credit-card processing requests, and stock exchanges. Another typical use is by 911 systems and hospitals. NED customers require round-the-clock access to information and quick access to updated information.
Of course, we want to provide customer access to new product documentation at the time of the release. However, customers also require 24x7x365 access to previous versions of the documentation. Many NED customers run hardware and software versions that are old by most computer-industry standards-some as old as 10 years. We support previously released software for a long period of time, and we continue to update the documentation. We must make updates available to customers and employees quickly.
New products are released throughout the year. Most products release quarterly, but some products come out whenever they are ready (these products are called independent products). Also, support information for individual products can come out at any time. The publishing system must be able to publish information daily and quarterly. We accomplish both by publishing “continuously.”
How Does HP Achieve Continuous Publishing?
A few simple concepts are central to publishing in NED:
- All source documents and their viewable renditions are stored in a content management system (CMS).
- Publications project managers who understand the contents and expected use of each document provide metadata about each document. The metadata provides information about when and how the document will be categorized, indexed, released, and expired.
- Project managers control the submission of documents to the CMS.
- Project managers specify the publish date of each document. This is the date that the customer can view the document.
- Automated processes check the CMS for new or revised documentation that is ready for publishing; these processes push the new or revised documents to servers that are the delivery channels.
- The same automated processes check the CMS for documentation that has expired for a given delivery channel and remove it from the appropriate delivery channels.
Storing all documentation in a CMS and marking each document with metadata allows the document to be published at its designated publish date. The CMS tracks and assigns a version number to each document and maintains information about when each version was published and when it was expired. Our CMS uses Documentum and technology developed in-house.
In NED, as with many companies, a typical product requires multiple documents such as a reference guide, user guide, and hardware-support guide. Project managers know when documents are complete, which documents support which products, and which documents support which versions of the product. Their accurate choice of metadata is critical to making continuous publishing work.
What We Deliver
NED provides customer information on a Web site and on physical media (CD and DVD). See Figure 1. Right now, the customer-facing Web site contains slightly more than 90,000 regularly maintained files (5+ gigabytes). The information covers 10 years of quarterly releases, 19 independent products (all versions), release notes for all products for the past 68 releases, and 14 years of support information. Typically, we update about 500 megabytes of data in a calendar quarter. Some of the data is restricted to customers or partners only. We also provide an internal-only Web site with slightly more information for HP employees, including early access to upcoming release information. NED technical writers and other employees in the greater HP community provide content.
The process has three basic parts:
- rendering and staging
A process we call TSPP monitors and controls rendering and staging and publishing. TSPP is a combination of off-the-shelf and internally developed technology.
Technical writers authoring in HTML, FrameMaker, or XML provide most of the content. Support personnel provide some of the content; most of that content is written using a proprietary markup language.
When a document from the technical writing community is completely reviewed, edited, and determined to be finished, the project manager submits the content to the CMS through our content management interface and marks it as ready to distribute. At the time of check-in, the project manager supplies key information about the document, including the title, the products and software versions that the document supports, whether viewing of the document is restricted, and the date it should be published.
The publish date can be immediate (usually for updated material) or it can be set to the future. The publish date can also be set to an alias. All the documents for a specific upcoming release use a single alias so they can adjust to schedule changes in unison. Because the project manager specifies the publish date, the manager controls exactly when the document will be published.
Content from outside the technical writing community is stored in a separate database on a NonStop server. Automated scripts run daily to query the database for new data. New content is parsed and transformed into HTML documents and moved directly into the rendition management system (RMS).
Rendering and staging
TSPP checks regularly (every 30 minutes) for documents marked as ready to distribute in the RMS. RMS processes transform the files to a viewable rendition (PDF, HTML, and so on). TSPP posts renditions to a staging area that is similar to how the customer will ultimately view the document. TSPP also sends an email request to the project manager to review and approve the document and its metadata for navigation, search, and content. Posting to the staging area is actually one of our four delivery channels, as described in the “Publishing” section of this article.
The project manager (or the author, if the manager chooses) validates that the document is as it should be for customer delivery. The project manager also checks that all of the metadata is accurate. This step is critical. Once the project manager approves the document and its metadata, the document is marked as approved and publishable in RMS.
All of the publishing processes are automated as part of TSPP and set to run at different intervals depending on the delivery channel they populate. We currently publish to four delivery channels, as shown in Table 1.
Customer Benefits from Continuous Publishing
Customers have constant Web access to information, updated daily. Customers can configure the Web portal to show only the information in which they are interested. Each time they visit the site, updated information is marked, making it easy for customers to keep up with new information. This feature is called the My Library in NTL.
Switching to continuous publishing requires certain disciplines in an organization:
- Project managers assume the responsibility for the accuracy of the content and the metadata. Incorrect metadata can lead to a document being placed in the wrong taxonomy on a Web site, going to customers when it should not be externalized, or even not being released at all!
- Since all publishing is automated, validation is left to the project managers. Our system notifies the managers when their publication reaches a delivery channel. If a document is published a long time after it was written and approved, managers can forget about it. If something goes wrong, they might not remember to look for the document on its publish date.
- The writing community and the tooling group must work closely with each other to set the requirements for the automated processes.
How Did We Get Here?
The NED publishing process has been evolving over the last 12 years. Customer data has been available on a Web site since 1996, and NED has been using document-management principles and technology since 1991. Continuous processing of documentation as described in this article has been in use since September 2003. NED has staff members with extensive knowledge about configuring and optimizing document management systems to meet business requirements. We would be happy to discuss our system and how we developed it with teams that are interested in implementing similar systems.
About the Author
Catherine Lyman is an inspirational manager with a long-term record of coaxing maximum effectiveness from her teams. Her team at HP is responsible for creating, managing, and delivering technical documentation for the NonStop servers. Her team is also responsible for managing the internal information for the NonStop division. Prior to her work at HP, Catherine managed a technical-publications group at Informix software, after writing in their database-server group for several years.
Catherine has a BSE from Princeton University and has been involved with information development for 17 years.