This book is not about technology...its real topic is a major
underexploited asset in your company; the information stored in documents.

A Book for Executives
If you are a member of the intended audience for this book, then you are a business person -- a senior executive, a general partner, a director or departmental manager. Whatever your title or role, you work far more as a "generalist" than as a "technologist." So why should you read a book that appears to be about technology -- a technology used to put books on CD-ROMs, turn documents into databases, or publish information on the World Wide Web?

You already have plenty of books and articles to read. Not to mention reports, email messages, and maybe even a few of those old-fashioned things called "memos." And you have people in your company whose job is to handle technology issues. It is their responsibility to keep up with technology developments, to recommend what products to buy, and to offer advice on building the kinds of systems your company needs. Why should you read this book instead of just giving it to them?

Well, you should read this book because it is not about technology. It discusses a technology, true -- a technology known as the Standard Generalized Markup Language, or "SGML." But its real topic is a major underexploited and uncontrolled asset in your company: the information that is created, stored, maintained, and distributed as documents. Information that ought to be as useful and as valuable to your company as the facts and statistics that you capture and store in databases, but that currently is not. This book is about why that information -- that intellectual capital that your company spends money developing and that you could be leveraging for competitive advantage or putting to commercial use -- is underexploited and poorly controlled despite years of investments in high-powered desktop computers and software. It is about why your technologists have not, by and large, recognized the extent of this problem and addressed it already. Most of all, it is about companies that did recognize their problem in managing this information and about how they used SGML to solve it, with tangible benefits that went far beyond their original goals.

And this book is about what you can learn from those companies -- indeed, what you must learn from them. Because your technologists can tell you how to solve problems. It is your job to tell them what problems to solve. That is why you should read this book: because it is not so much about a new technology as about a better way of thinking about your company's documents and the information they contain. It is about a fundamental business issue, and the resolution of such issues must begin with you.

Why "The Billion Dollar Secret"?
SGML gives your organization a degree of control over documents and the information found in them, that you never had before. But does this really make it a billion dollar secret weapon? For any one company, obviously not. Most of us would be ecstatically happy to see our companies achieve billion dollar sales, much less find billion dollar savings. But when you look at the costs of manipulating document-based information on the scale of whole industries, a billion dollars starts to look conservative. Just adding up all the direct and indirect savings achieved by companies mentioned in this book, and factoring in all the new products and capabilities SGML made possible, you can see a good start on a billion dollars.

Consider your own organization. If it is a medium- to large-sized organization, then the problems that SGML addresses can easily be costing you millions. These millions are spent:

• Finding out which of the three different answers you got from three different design engineers is correct, because you don't have a pool of design specifications and status information that all the groups involved in the product development effort share.
• Retyping or reformatting the information one department sent you before the people in your department can use it.
• Writing yet again content that has already been published, because you can't get your hands on the existing copy -- and, even if you could, it would be in the wrong file format anyway.
• Redoing the files you received from one of your component suppliers before you can integrate it into your own product documentation because, even though they gave it to you in your word processor's format (an additional task for them; an additional cost for you), it is still organized completely differently from your corporate style.
• Providing phone support to customers because the information shipped with your product was incomplete.
• Handling the rejects sent back by your customer's QA department because they tested your product against your published specs, which were already out of date by the time you shipped the product out the door.

How the Book Is Organized
This book is written so that you can use it to learn what you need to know quickly. Ideally, you will read all the case studies. Often companies discover that the information problem they thought they were trying to address, whether it was building a World Wide Web site to support customer service or publishing their technical product information on a CD-ROM, turns into a very different set of problems once they get started building the solution. Reading about the variety of problems that other companies have tackled can help give you a broader set of ideas for solving your own.

However, you can also read this book in bits and pieces. Each case study is a story unto itself. You can start with the cases that seem most relevant to your business or situation and read the others at your leisure. Each case study is introduced with an executive summary that provides an overview of the company's business, the problem they had, and how they solved it.

I recommend that you read the first two chapters before turning to the case studies themselves, because those chapters set the stage for understanding what each company accomplished. Chapter 1 explains why the current technologies used to write and publish documents has failed to provide us with useful pools of information assets. The documents our companies create are not "data" in the way that our customer databases or our automated order-entry systems or our financial records are. This chapter explains why, and it introduces another approach to creating and managing that information that dramatically changes what we can do with it.

Chapter 2 is a fictional account of what happens when a sophisticated, technology-adept corporation attempts to use its reservoir of technical information to build a state-of-the-art product-support tool. Trying to deliver a strategic system that will greatly benefit their customers and further cement their position as a market leader, they instead get an object lesson in just how ill suited most of today's electronic documents are for anything more than printing out brochures and manuals. The story is hypothetical -- but that doesn't mean it isn't true. The events it relates are drawn from years of personal experience and the experiences of others who have tried to create new information products for their companies. It is the story of what might well happen in your company when you try to leverage the content that you have been paying to create for all these years. The names have been changed to protect the innocent, but the story itself is very real and it is being played out in companies around the world every working day.

Acknowledgments
Now that I am winding up this project, I find myself paying attention to the acknowledgments section in other books. I used to skip over them, but no more. I read them now because they mean something to me. They say that a book was not a solitary exercise but instead the outcome of a community of effort. It was the result of one person's work, perhaps, but of many people's input and ongoing support. Certainly that has been true of this book, where I have tried to capture and convey experiences and successes achieved by others. I owe much to my community, and if this book has anything useful to say, it is only because, like Newton, I have stood "upon the shoulders of giants."

First and foremost, I want to thank Dr. Charles Goldfarb for realizing that I had a book in me before I realized it myself. If Charles had not seen the seeds of this book in some of the material that I had posted to comp.text.sgml, the Internet SGML newsgroup, I would have missed this opportunity to learn firsthand how so many dynamic, inventive people use SGML in furthering their business objectives as well as to broaden my own understanding of the applications of technology in the workplace.

Special thanks are also due to Mark Taub, the senior managing editor for the Charles F. Goldfarb Series, for waiting patiently while I learned to be an author. Mark has been always available, always supportive, and ready to help me in any way he could. He let me turn this book into something close to what I originally envisioned while helping me keep an eye on the final target -- publication. I don't think a writer could ask any more of his editor than that.

A book like this one demands a great deal of research and investigation. Even now, I wish there had been time to do more. But I would have accomplished much less had I not had the help of Fredrick T. (Tom) Martin of NSA, the National Security Agency. Tom has been a research partner and also a cheerleader, a sounding board, and a fan. Through the most demanding of times in his professional and personal life, he stayed involved in the project, tracking down leads, lining up case study candidates, and collecting information. He is one of the giants who has supported me during this project, and I cannot thank him enough.

This is primarily a book of case studies, which I could not have written without the generosity of many people. Those whose success stories are told in this book, and more whose success stories are not, gave me far more of their time, their memories, and their resources than I asked for. My deepest thanks go out to them all: Terry Badger, Jeff Barton, Elaine Brennan, Cyndie Cooper, Ed Covennan, Bert Daron, Alfred Elkerbout, Dr. Robert J. Glushko, Steve Goodman, Tom Jeffery, Ted Kell, Ken Kirschner, Vane Lashua, Debbie Lapeyre, Larry Lorimer, Pat O'Sullivan, Dave Rattanni, Joe Salerno, Gary Sargent, Paul Simpson, Lamont Thomas, Tommie Usdin, Richard Weich, and Bob Yencha.

I owe a special thank you to my employers, Darren Bryden and Mimi Brooks of Logical Design Solutions, Inc. They tolerated my absences, sudden disappearances, long phone calls, and frequent spells of distraction with quiet good humor. Without their support, this book would be far less than it is.

Many people shared ideas, reactions, insights, critiques, and a million useful observations on what worked and what didn't -- in this book as well as in the real world. In particular, I am grateful to Jon Bosak, Tom Comerford, Kurt Conrad, Joseph Gangemi, Mary Laplante, and David Silverman. They helped turn my fledgling notions into concrete substance.

This book required a lot of travel. That's what advances are for, of course, but the credit card companies would have been gleefully raising my credit limit even higher had it not been for Natalie Burgio at The Travel Gallery in Madison, NJ. Natalie took sympathy on my situation and made it her personal mission to get me to and from my various destinations at the lowest possible expense. Thanks Natalie -- the book is done and I won't have to file for bankruptcy afterall.

To Karen Florman and Francis Gambino I'll just say, "Thanks for telling me that I could do this." How many times?

Finally, no amount of thanks can come close to repaying my wife Barbara and my daughter Emma for their support, encouragement, patience, and love throughout this project. Especially the patience part. A book is like a second full-time job, and there were many sunny weekends and family events when they went off and left me behind closed doors, working on "the dumb book." Through all of it, they put up with me with grace and (for the most part) good humor. I love you both -- now we can go back to living the life to which we were accustomed.

-- Chet Ensign