Single-Sourcing is a Software Project (not a Documentation Project)

Understanding the staffing requirements for a production quality single-sourcing system depends on two things:

  1. understanding the difference between IT and engineering
  2. understanding why a group, which has not (at least in recent history) required specialized skills to operate, suddenly does

Think of IT as a mall and TechPubs as a Store in the mall.

Both the mall and the store have specialized staff who help run their business. Both groups have staff members who are responsible for the operation and success or failure of the their particular business. The store depends on the mall to provide a physical location in which the store can do business. The mall depends on the store to provide a source income in order for the mall. The mall depends on the stores it houses to provide attractions that bring consumers to the property. The stores depend on the mall to provide a safe and secure location for customers to do business. Both groups have responsibilities that center around the same customers; both groups work together to achieve the same goal.

But they don’t use the same staff to operate both businesses. While the two groups would have several staff members with overlapping skills, these same staff members have completely different focuses. For example, both groups have sales associates. The sales associate for the mall would never be the same sales associate for the store. If the staff for both groups were the same, the mall would be responsible not only for the operation and success or failure of the mall itself, but the success or failure of the stores operating within it as well. This would mean that the mall’s sales associates, who would normally be selling space in the mall, would not be doing that because they would be spending their time selling products at every store in the mall.

The focus for each group is fundamentally different. For the mall sales associates, every sale is a single sale: a one-off deal. For the store sales associates, every sale is a repeat sale: every sale is tied to the dynamically changing nature of the rest of the store.

The store can afford to try different approaches, to move products around. If one display works, then everything’s great; if it doesn’t, then the sales associates change the display and try something else. One failure isn’t fundamental to successful operation. More importantly, because of the frequently changing nature of the store, one bad display, particularly one that isn’t there very long, isn’t visible to customers.

It’s different for the mall sales associates. Stores contract locations for long periods of time. Malls cannot afford to have individual store spots empty for long periods of time. One bad contract can mean success or failure: and that success or failure is glaringly obvious to everyone who comes into contact with that mall.

The same things are true of engineering and IT. Engineering groups can try different things out; they can change things on a daily basis in order to improve they way they operate.

IT doesn’t have that luxury. IT focuses on projects that support the entire business structure. IT’s failures are failures that everyone sees. A failure for IT is a big problem: it’s lost money. As a result, IT cannot afford to have people tied up supporting engineering groups on a daily basis. Successful IT organizations bank skills in order to deploy teams to implement and manage the large parts of one-off projects and then move them off to the next one.

TechPubs is one store in the Mall. TechPubs has products and customers and requires a certain amount of infrastructure support from IT, in order to operate effectively. However, in recent history, TechPubs has not required specialized skills, that have overlapped with skills traditionally found in engineering or IT organization. With a single-sourcing system, that’s no longer true.

Implementing a single-sourcing system is not a trivial replacement of applications. Since the mid-80s, technical publications departments have been able to trade authoring tools with very little assistance: Let’s use Interleaf! Now, let’s use FrameMaker! Look, PageMaker! Microsoft Word!

These applications could easily substitute for one another on the author’s, editor’s, and text processor’s desktop computers.

With an XML authoring and production system, this is no longer true.

For example, authoring consistent and publishable documents in Microsoft word requires adherence to a Microsoft Word Template (.DOT) that governs the styles, spacing, and pagination of a document authored in Word. IT would maintain the Word application on each author’s desktop, but it would not normally develop the .DOT template document. Word user specialists would create, maintain, and deploy the .DOT template to the authors using the application. So, just as IT would maintain the authoring application and the publishing application but not maintain or develop the required templates for publishing from a desktop publishing application, they would not do that development for an XML publishing system either.

Look at a typical PeopleSoft implementation. IT would maintain the application, machines, and application specialists. They would typically develop and maintain the workflows that are required for efficient processing. The HR department would also have a PeopleSoft specialist, who would administrate the application, train new users, and provide or restrict access to certain records in the database. In an XML authoring environment, IT would maintain the database and repository, from the application perspective, but someone from TechPubs would have administrate, train, and provide or restrict access to documents in the repository.

In a very general sense, every IT project is a “one-off,” a singular project that supports part of the enterprise. IT costs are overhead costs. As a result, if an IT project doesn’t work, it’s a big problem: the company has lost money on it.

In contrast, functional tools teams can support proactive projects: try something, if it works, good, if it doesn’t work, it’s not a problem. Engineering organizations are expected to try apply new approaches and new technology to existing problems. Likewise, functional tools teams who support engineering products can also do proactive software development.

For a single-sourcing project to be successful, the way you define the line between the IT team and the functional team (the “tools” team) becomes important. In many ways, this depends on the charter IT has in your enterprise. At Juniper, IT had a very specific job: whenever company purchased a new application, IT would dive in, learn everything there was to know about it, and support it. But they rarely went beyond that point. If an organization needed daily support, they added a functional tools team that took things from there.

IT builds the roads, the functional group buys the cars; the functional tools team customizes and maintains the cars, all while following IT’s rules for driving.

Finally: Adding Marketing, Sales, and Other Business Systems

Liz Fraley: This is the fourth of a series of articles based on the talk I gave at the Content Management 2005 conference. These articles focus on extending single-sourcing systems and activities to integrate content-generating organizations enterprise-wide.

Profiling Customer-Specific Purchasing Information

The customer price list is an obvious target for integrating with Marketing. What if you could automate creation and publication of the customer price list? A price list tends to be a complicated, dynamic document. Prices are adjusted based on the customer, the geographic location, the business segment, just to name a few. In addition, different customers may have different discount levels, based on any number of factors.

If you were to dynamically generate the price list, you could produce accurate, up-to-date focused price lists for every customer every time. Simple filters applied to the same information can produce different views. Profiled data turns a single data source into customized price lists for your customers.

In fact, taking this one step farther. Most websites require their customers log in to get pricing data. As long as you know who’s looking, you can profile your way to displaying targeted pricing data: you can put their most likely purchases at the top of the list, and, depending on how good a customer they are, you can alter their discount to make purchasing more attractive.

How about the parts list? You can provide customized parts lists to your customers if you integrate their purchasing history with the parts database. Mission critical custom tools can bridge systems through the simple application of XSLT to XML data acquired through XML interfaces. You get documentation stubs for free, that an author or editor can polish and deliver directly to customers.

In addition, you can improving customer experience by integrating purchasing data and portal personalization. XML web service technologies can help coordinate information for customers. Use customer purchasing data to delivers product updates, white papers, and data sheets. The profile connects the docs, linking in field articles relevant to the products customer has ordered in the past or may be interested in today.

Separation of Form And Content

The separation of form from content is particularly important for marketing. Separating form and content makes changing look-and-feel very easy. This applies to more than just the CSS stylesheet applied to a company’s web pages: this includes any PDF documentation, any text (README) type files, any presentation slides or self-service, knowledge base articles. Each one of these is content clothed in a particular look and feel that can and will change over time.

The average company changes the look and feel of it’s external website every 4 or 5 years. The more tightly integrated the content is with look and feel, the harder it is to upgrade your look. At Juniper, the marketing team outsourced a new look-and-feel to a web services company. It took nearly 9 months to migrate all the pages to the new look. It took another year to convert the pages to more easily maintainable ones.

The web services company had traded maintainability for precise look-and-feel. As a result, they had little pixel gif images all over the place, embedded throughout every single page, so the page would “look perfect” every time in every browser. As it turned out, it didn’t look perfect in every browser; it didn’t look right in half of the FreeBSD-Mozilla browsers internal to the company. And it made updating pages, with changing content lengths extremely difficult.

On the other hand, if they’d automated page generation, updating pages would have been a breeze. Update information in a stub-page, send the stub through a generator, and boom! You’ve got a well-formatted page that fits the new content. What you don’t have is a lot of manual effort to tweak all of the various little spacers that the web services company threw in just to get one page to look just right.

Finally, a few ways to include internal business processes

  • Services to support Sarbanes Oxley activities
  • Audit trails
  • Branding turnover
  • Acquisitions
  • Connecting to operations, manufacturing, and document control systems
  • HAZMAT database integration
  • Universal Business Language (UBL)

Look for places that create source data that is repackaged for different audiences and different purposes. All of these places are potential targets for cost savings through XML tool development.

We’re all sold on structure — that’s why we’re here

Remember:

  • Structure is added work
  • If you make structure onerous or make adding it hard/expensive time-wise, people will not do it
  • You need to be careful about what you choose to do or you will end up with structure that may not really be useful: <temperature>47C/104F</temperature>

Special Benefits For Training

Liz Fraley: This is the fourth of a series of articles based on the talk I gave at the Content Management 2005 conference. These articles focus on extending single-sourcing systems and activities to integrate content-generating organizations enterprise-wide.

Time to Integrate Training

Training materials are perhaps the best example of repackaged data. On the one hand, training materials are perfect targets for reuse: content can come from published manuals to customer support to sales and marketing collateral. Training is the one place that you want to ensure information consistency. Customers pay for training and expect that what they learn in training will always be of value.

At the same time, the training materials themselves are a perfect example of repackaging data based on the idea of varying levels of detail. From one source, you can create scalable training materials:

  • Student materials
  • Instructor’s materials
  • Presentation slides

In addition, with very simple tools, you to go up and down — increase or decrease — the level of detail.

For example, one of the best trainers I know teaches the skills required to do exactly this. G. Ken Holman teaches XSLT and XPath, the language that transforms XML data. He prepares one large XML document with all relevant, tagged information. From this one document, he can produce the student materials, the instructor’s materials, and his presentation slides. He can switch from one to the other dynamically to address questions on the slides or in the materials, right before the students’ eyes, with a simple click of the mouse.

At the same time, he can produce the individual student name plates, the registration materials, and the student contact information sheets just as quickly. He creates one large document with all required information tidbits. Because he can generate all the output files, he can process registrations and provide accurate data to the students and his class helpers right up to the last minute. One quick transformation and he can print out the latest information for distribution 5 minutes later when the class begins.

It’s powerful stuff.

Special benefits for training…

Training in an organization happens at a number of levels — internal, external, and management training classes. Most training classes get canceled because not enough people sign up.

What would happen if you aggregated the schedules of all available training opportunities? You’d get a master schedule of training classes — one-stop shopping for training, if you will — that everyone could consult. That way, employees can find classes that fit into their existing schedules, reducing the amount of time that training impacts their day-to-day deliverables while at the same time reducing the overhead costs of less than full classes.

When you combine aggregation with profiling, you can generate schedules on-the-fly for different audiences simultaneously:

  • This Week, This Month, Next Quarter
  • Internal, External, Management
  • Certification, Webinars, Tutorials, Online Training

A trainer I know does this on an inter-company basis. He gives training classes himself, and licenses his training to other people to deliver. He posts an XML version of his training schedule; his licensees post XML versions of their schedules. Each one also has a filter that pulls in the other person’s information at run time.

This means that whenever someone clicks on Ken’s class schedule, that person sees not only Ken’s deliveries, but Laurie’s too. Ken only needs to modify his own schedule: he never needs to update the master schedule. The master schedule is updated whenever a potential student clicks on Ken’s schedule link: XSLT fetches Laurie’s latest data, integrates it with Ken’s, and displays both to the student. The customer is served: the student can always find the best class that fits his or her schedule.

It’s a simple scheme that works because all business units can participate with minimal effort.

Just a note about RSS

RSS is a family of XML file formats for web syndication used by (amongst other things) news websites and blogs. The RSS formats provide web content or summaries of web content, links to the full versions of the content, and other meta-data. In addition to facilitating syndication, RSS allows a website’s frequent readers to track updates on the site using a news aggregator.

Different news and weblog sites use RSS feeds that are automatically updated whenever a new article is posted. The site determines how much information is posted to the feed — the whole article, a teaser, or just a headline. Readers can use their favorite RSS aggregator to access everything that interests them without having to visit every single site. It’s a great way to keep your customers up-to-date and connected to you.