| Previous | Table of Contents | Next |
Getting SGML implemented in an organization can be a complicated undertaking. Many issues must be addressed in order to successfully build and implement an SGML production system.
It’s not uncommon to feel intimidated when you start out in your SGML project. As you consider all of the issues, challenges, questions, and topics up ahead, implementing an SGML system might seem like an overwhelming proposition.
Many people implementing SGML for the first time will feel the need to dive into document analysis, so that they can rapidly get to the goal of producing SGML documents. But before you dive in, you might want to perform some analysis up front. By performing this analysis, you might avoid a few mistakes later.
This chapter explores the issues and approaches that can aid you in successfully bringing this about. As with many things, there is no absolute correct way to go about this. Your individual circumstances may well dictate some deviations from the approach that this chapter takes. However, in this chapter, you will explore some ways and techniques to successfully complete an SGML project. As you do so, a framework will emerge.
To do this, you will examine the phases of SGML projects in the following sequence:
As you examine the issues involved in constructing your SGML environment, you should periodically ask yourself, “How does this issue affect me and my organization?” Although many of the same issues may be relevant to various organizations implementing SGML for the first time, the particular “mix” and importance of issues are likely to vary considerably depending on your own particular circumstances.
In this phase, you should define just what you want to accomplish in your project: where you want to go, what you want to achieve, and in what timeframe. In other words, just what are you intending to accomplish by bringing SGML into your organization?
For example, do you intend to maintain a set of documents for a long time, say 10 years or more? If so, having a portable document repository maintainable across several generations of document processing systems may be very important to you.
Do you currently produce a variety of hardcopy documents, but want to position your organization to deliver information electronically, such as on CD-ROM or via the Internet? In this case, having a document production system and document architectures that facilitate both types of delivery may be a major goal.
In still other situations, you might want to build a repository of information “objects,” organized so that you can build documents on the fly, maintaining reusable portions centrally. That way, you know that these objects are both consistent and accurate.
All of this and more can be facilitated through a thoughtful and focused use of SGML in your organization.
To define the scope of your project, you should ask yourself a number of questions. Among these are the following:
As you look at what you want to achieve, talk to people. Ask them for their perspective on the project. Examine the mandate that you received when the project was first initiated. Talk to the sponsor of the project. Find out what their expectations are for success.
Examine your goals as they relate to the future. Do they relate to where your organization wants to be in two years? In five years? In 10 years?
After you have gathered all of this information, write it down and examine your findings. As you examine the list, ask yourself, “Is what I want to achieve realistic?”
Although there are many variables at play, it is not unreasonable to expect a significantly sized SGML project to take 2-3 years to bring into production. When you are going to spend that much time on a project, the up-front planning and analysis can be pivotal to success.
As you lay out the scope of your project, you need to develop a list of the document types that you’ll include. In looking at document types, you should consider “families” of documents. These may include such classes as Operations and Maintenance Manuals, User Manuals, Parts Lists, Product Data Sheets, Service Bulletins, and so on.
Document families should consist of documents that are related in structure, content, function, and appearance. For example, if your company produces both jet engines and toasters, it is a good bet that the User Manual for these two products would differ considerably and, therefore, not be in the same document family.
If your organization is new to SGML and your project is considered to be a pilot, you might want to define a limited document set for your initial efforts. Chances are that you will want to repeat the whole process later with the benefit of your experience from your initial efforts.
When approaching your project, you should have a clear set of goals in mind. These goals might range from reducing documentation production costs to delivering your organization’s information on the Internet. Some common goals of an SGML implementation project are:
The important part is that you have a set of goals that can be clearly communicated and understood by your project team. By clearly defining your goals, all of your project participants can share a common understanding of where you are headed.
| Previous | Table of Contents | Next |