Coordinating SGML Projects to Maximize Corporate Benefits

CALS Expo International '95 Conference Proceedings [pp 247-253] National Security Industrial Association Long Beach, California – 1995

Joseph Gollner – Euclid Consulting Group Ernest O'Dell – Department of National Defence CALS Office

Abstract

The Canadian Department of National Defence (DND) has made reducing the cost of published information a major priority. The Department recognizes that a sizable portion of potential savings will result from improved information quality and usability. The challenge lies in ensuring that all areas of potential savings and quality improvements are addressed and addressed in such a fashion that facilitates a constructive synergy between modernization activities. DND is looking at a number of technologies and management disciplines as tools for meeting these objectives. Emphasis is being placed on object orientation in the design, development and deployment of reusable Standard Generalized Markup Language (SGML) components and the application of Configuration Management (CM) practices to these objects. DND is currently designing an environment that will allow projects to share SGML objects and continuously coordinate the implementation of new capabilities without undermining the corporate benefits of an integrated approach.

1: Maximizing Corporate Benefits

The kind of the reductions and cost savings currently being demanded of DND can only be realized through department-wide improvements in efficiency. This is widely accepted. There is even a general management consensus that many of these efficiencies will be the result of better resource sharing, with resources understood to be any type of asset – data, infrastructure, personnel or systems. This environment has been conducive to the growth of SGML in DND. SGML is seen as a mechanism for improving the quality, timeliness and cost-effectiveness of documentation through the use of standard document structures and corporately-shared systems for creating, publishing and maintaining information.

Following the line of thinking that stresses the importance of sharing resources, there are some who would conclude, erroneously, that the surest way to realize these corporate benefits lies in establishing standards and mandating compliance. This is an erroneous conclusion in part because it has been tried before and has failed. In fact, it has

been tried many times before and has always failed. The main reason why this is an erroneous conclusion, and why attempts to base implementations on this conclusion have always failed, stems from the fact that a single, static solution cannot successfully address any problem where variability and change are significant factors. Unfortunately, variability and change characterize most of the problems confronting large organizations like DND. This is not to say there are no solutions, only that there are no easy or fixed solutions.

Let's translate this into the SGML domain. Say that it is one of our primary objectives, and it is, to ensure that the many SGML projects ongoing within DND ultimately result in a set of corporately-shared applications to facilitate the creation, publication and maintenance of information. The development cost of these applications would stabilize after their completion while the benefits associated with their use would grow for as long as these applications remained operational. We might find this so compelling a prospect that we establish a management infrastructure for SGML initiatives that would ensure that all initiatives and Programs use these applications, and the document structures that support them. Through various policy instruments, we might even attempt to strip Programs of the ability to deviate from the mandated standards and practices. To guard against the possibility that the corporately-shared applications may not yet be perfect, we would establish a change management process whereby modifications would be proposed by Programs or SGML initiatives and approved by a suitable control board after an exhaustive analysis of the impact on all corporately-shared applications. Having done all this, we would feel that we had succeeded and had made a sizable contribution to the efficiency objectives of our organization. We would be wrong.

What we would have in fact done is commit the logical error outlined above. Our desire to establish corporately-shared SGML applications would have been valid. Even our desire to promote uniformity among implementations to safeguard the benefits of corporately-shared applications would have been essentially valid. Where we made our error was in hoping, even believing, that once established the corporately-shared applications would be basically sufficient to address unforeseen or changing requirements. We also erred in thinking that a single, centrally-managed process for change control could successfully handle the rising tide of change requests that were driven, not by minor deficiencies in the corporately-shared applications, but by new requirements from new Programs and new initiatives. This latter error was the fatal one. What we should have done was make the change management environment itself a corporately-shared application that was designed to ensure that all corporately-shared applications would be adaptive to the variability of Program requirements and the inevitability of change.

2: SGML in DND

Within DND, SGML has been enjoying a steady rise in popularity. Many policy documents, including the Information Management Directives that establish the role of CALS (Continuous Acquisition and Lifecycle Support) within the Department, are currently authored and published using SGML. These documents now find their way, in electronic form, into every unit and organization within DND. In the domain of technical information, the DND CALS Office has made significant progress in developing, validating, implementing and modifying a Document Type Definition (DTD) to describe and manage all operations and support information currently published for DND equipment. With this expanding base of SGML-encoded information, the opportunity presents itself to develop, and introduce into service, corporately-shared applications designed to leverage the investment in SGML structures and improve documentation quality and usability.

3: Departmental Initiatives and the Role of SGML

3.1: Automated Translation

Bilingualism is a reality in Canada and the cost of translation between the two official languages is something DND must continually address. One area of ongoing effort is automated translation whereby an application attempts to establish a sufficiently accurate "understanding" of a text to be able to render a tolerable translation. This can be sufficient for "ad hoc" translations (i.e. to quickly determine the general content of a text) but, depending upon the clarity of the source text, there can remain insurmountable ambiguities. Obviously, this is not acceptable for official documentation which must always be available in both official languages. This applies, significantly, to all technical documentation. In these cases where accuracy counts, automated translation can be used to perform the initial translation with the intent that this will reduce the amount of time and effort required by highly skilled translators to complete the translation. It is for this reason that SGML DTDs within DND associate English and French content as consecutive elements typically within a container element. High volume automated translation applications will be able to "fill" one language element based on the content of its twinned counterpart. This approach permits translators to view both elements (English and French) simultaneously, saving on cross-referencing time, and facilitate verification that everything that requires translation has been translated.

3.2: Simplified English

The language of composition for most documentation in DND is English and therefore the typical translation process takes content from English and translates it into French. As mentioned previously, ambiguities in the source text make translation

(automated and manual) more difficult and therefore more expensive and error-prone. English is notoriously prone to ambiguities and it is generally conceded that reducing the cost of translation from English will be a function of reducing the ambiguity of the English source. This is, in part, the rationale for Simplified English (SE). SE also realizes benefits in making the English text more readable for native English speakers. In effect, SE establishes a constrained vocabulary and restricted syntax that are applied to the content of official documentation. Different SE rules can be applied to different document types (e.g. a Policy document versus a technical manual) and to different parts of the same document (e.g. theory of operations versus a safety precaution). The link to SGML is obvious in that SE rules can be invoked according to the appropriate document type and element. For example, the SE rules may be very explicit about the vocabulary and syntax of a maintenance step requiring that the sentence describing a step always begin with an action verb (themselves selected from a restricted list of possible action verbs). This type of quality control application would be directly dependent upon the available SGML structures and element names (e.g. <Mainttask> <Step>).

3.3: Defence Terminology Management System

Implementations of SE must make specific exceptions for technical terminology which obviously will not comply with the requirements of the constrained vocabulary. The management of this terminology is the function of the Defence Terminology Management System (DTMS). As with SE, the DTMS seeks to enforce a consistent usage of terminology across the Department such that texts are unambiguous and easily translated. SGML will be used to explicitly identify occurrences of terminology (e.g. <term>) within the text and associate each occurrence of the term with the appropriate acronym and definition, themselves defined within the text. The strategy of the DTMS is to execute terminology control during the authoring process as opposed to using a downstream review activity. Terms will be defined, delineated with markup, and validated by authors with the support of intelligent applications that can locate terminology occurrences and ensure that usage is consistent across the document and reconciles with the departmental term database. The departmental term database is itself conceived as a "live" database based upon document instances that incorporate approved terminology. The population of this database from active documents will rely very heavily on the use of the appropriate SGML elements.

3.4: Publishing Services

The most immediate, and probably most significant, cost savings to be realized through a corporately-shared system will be in the publishing domain. Standardized formatting instructions are being developed that will apply to SGML instances created

according to known (and managed) DTDs and implement departmental formatting guidelines. There is also a requirement for shared publishing systems that will process formatting instructions and instances for the production of all required output formats. Finally, there is a need for a department-wide capability in high-volume on-demand printing, and electronic dissemination and retrieval. DND has initiatives underway to provide all of the above. The objective is to establish a robust and adaptable SGML publishing capability within the department. Establishing this type of capability has consequences for many SGML components and, in particular, those that are directly processed by the publishing system and that must provide sufficient information to allow formatting instructions to be applied successfully. Base text elements (e.g. paragraphs), tables and graphics must all manifest a measure of standardization and completeness for formatting purposes. Once in place, however, the benefits to be realized through a corporately-shared publishing system are not only significant in terms of cost but also in terms of reduced complexity. Programs can conceivably reallocate resources to content preparation and the specific objectives of the Program as opposed to engaging in expensive publication publishing projects.

3.5: Integrated Equipment Management Environment

It is understood that technical publications do not exist in a vacuum and that a high proportion of the information typically bundled in a "technical manual" in fact emerges from other sources. Behind the entire push toward electronic SGML-based technical information is the desire to improve the currency of accessed information (e.g. configuration status on the equipment being serviced), the level of reuse of information created during established processes (e.g. logistics data) and the ability of maintainers to execute actions when required in the context of a larger procedure (e.g. ordering a replacement part). It comes as no surprise, then, that DND is proceeding with efforts to establish an integrated environment for managing equipment information. The following are a sample of initiatives underway to ensure that SGML-encoded information fits neatly within a larger data management regime:

Logistics Support Analysis Report (LSAR) / DND CALS DTD integration is being prototyped to ensure that all information created during the Logistic Support Analysis (LSA) process that will be reused within published technical information has corresponding destination elements in SGML document structures;

Equipment Program Management Information System is an initiative, under the Operation Excelerate re-engineering project for the Materiel Group, that will establish an integrated working environment for the management of equipment

information with the consequent impact upon all information extracted from this environment and published in SGML;

Material Support Data Model (MSDM) is a conceptual data model being prepared for the information requirements of materiel support. Data definitions established here will have a broad influence on all applications, including SGML-based applications (e.g. DND CALS DTD), within the Materiel Group;

Management of Government Information Holdings (MGIH) is a government-wide policy directing the manner in which departments, such as DND, manage their information holdings. This impacts the way identification and management information is described by departmental DTDs and implemented in the resulting SGML instances.

4: Design, development and maintenance of shared SGML objects

The variety of initiatives within DND, each impacting upon different aspects of SGML implementation, forces us to consider the issue of establishing, enforcing and managing corporately-shared systems and standards. There are obvious potential benefits offered by quality improvements, reduced processing costs (e.g. publishing and translation) and better integration between published information and the management processes for that information. However, it is also immediately apparent that the complexities of implementing the required corporately-shared applications, and coordinating the impact upon in-service SGML components, poses serious risks to ever realizing these benefits. Having overcome these risks, the temptation will be great to force closure on SGML component development and modification as soon as these corporately-shared applications have been successfully implemented. As we have seen before, surrendering to this temptation would be a mistake. How then will we bring into service corporately-shared applications for translation, Simplified English, terminology management, publishing and information management, bearing the separate costs of each implementation, and ensure that new or changing requirements can be accommodated without incurring an unacceptable cost in modifying each application to suit each deviation? The answer lies in the way we design, develop and maintain SGML objects.

4.1: Object-Orientation

To date, we have designed SGML DTDs, and associated components (e.g. output specifications), strictly on an application by application basis. As soon as we must simultaneously address the requirements of existing corporately-shared applications in

addition to the specific application being considered, then, as DTD designers, we are constrained in the way we address certain functionality. What is important to determine is where, and in what manner, we are constrained if we plan to produce an SGML application that can also exploit the corporately-shared support applications. Once this has been determined, we can assess what functional trade-offs may be necessary due to conflicts between corporate and local requirements. To arrive at this point, we must be able to access SGML sub-components, or objects, that provide the building blocks for incorporating corporately-shared functionality into new SGML constructs. Following this process also has a general impact in that our DTD will be a modular construct rather than being a single, self-defining entity.

In this context, SGML objects are understood to be coherently defined groups of inter-dependent SGML components. On the first level, an SGML object is comprised of a logically integral DTD fragment together with the directly associated processing instructions or requirements (e.g. formatting specification instances) for all applications (corporate and local) to process information complying with the DTD fragment. On a second level of detail, an SGML object contains all the information required to understand and manage the functionality provided, or supported, by the object. The SGML object includes all documentation for elements/attributes of the DTD fragment, their associated processing requirements, the associated application functionality, the user community and usage scenarios, current implementations, test and demonstration instances, and management information about the object. Management information would include identification, domain, version, revision, Office of Primary Interest (OPI) or sponsor, Offices of Collateral Interest (OCI) or stakeholders, creation and revision dates, and registration status (e.g. in development or approved for use). By taking this approach we have effectively created "functional objects" that encapsulate the data definitions (DTD fragment) together with the associated methods (functionality). What we have, as a result, are meaningful SGML building blocks that make it as straightforward as possible for DTD developers to identify and understand functionality that is currently provided by corporately-shared applications.

Recalling the corporate applications being developed within DND, we can begin to see how this approach would operate in practice. Support for automated translation, Simplified English validation, terminology management, publishing services and information management guidelines has a direct impact upon the SGML object that defines base text elements as well as common structures such as tables. In establishing this logical grouping as an SGML object, the close link between the SGML structures and the associated functionality is made explicit. Changes to base text elements can potentially have dramatic implications for the associated functionality. Support for Simplified English validation and information management guidelines (in particular, data integration) depends on aspects of content specific deployments of SGML (e.g.

<Maint-task>). In the case of supporting the requirements of departmental information management guidelines (MGIH), there is a very specific association of content elements (e.g. <subject>) with desired functionality (e.g. archival storage and retrieval).

4.2: Configuration Management

Once we have created a set of SGML objects, what remains to be done is establish the overall discipline of Configuration Management (CM). The intent, of course, is not to deploy CM as an impediment to change but rather as a facilitator of orderly, effective and timely change. With SGML objects that have been defined with the intent of managing "functional objects", it becomes a natural extension to implement the change review and status accounting practices that derive from applying CM to these objects. Because data structures and functionality are encapsulated together in the SGML objects, it is possible to discretely identify the variability tolerance of different SGML elements within an object. As an example, a proposed change to the mixed content model for English text (e.g. changing the use of attributes within the emphasis element) may introduce processing complexities that would very quickly indicate that the cost of altering the corporately-shared applications outweighs the perceived benefits of the proposed change. Due to the number of applications that depend directly upon a predictable structure within the base text elements of an instance, the variability tolerance of the SGML object encompassing these base elements may be, in general, determined to be low. Other SGML objects, however, may be far more tolerant of variations and in fact support a large number of implementation-specific element variants. This is the critical point about the application of CM to SGML objects. With the proposed approach, requested changes are reviewed in the context of the real impacts of that change. If a proposed change (such as the introduction of a Program-specific content element) requires only minor changes to a single shared application then the change could be rapidly approved with the proviso that the requesting organization fund the minor changes so as to retain the benefits of the impacted shared system. This is the type of interaction between local implementers and corporate standards that encourages participation in the corporate change management process rather than forcing Program offices, with set budgets and schedules, to "drop out" of the process due to unresponsiveness or unreasonable (i.e. unfounded) constraints. This is in distinct contrast to some change management philosophies that treat any change request as a threat to the free world.

4.3: Shared Development Environment (SDE)

Responsiveness becomes a key aspect in determining whether or not a corporate change management process for SGML objects is ultimately successful in

accommodating necessary changes while protecting the benefits of corporately-shared applications. The desirability of responsiveness to local implementers attempting to address real requirements has the effect of making the change management process itself a corporately-shared application. It is for this reason that DND is proceeding with plans to implement a comprehensive SGML Registry and Repository (SRR) system where implementers will directly access SGML objects and, as necessary, initiative the change review processes associated with these SGML objects. It would be a deliberate move to name this shared application a Shared Development Environment (SDE) as opposed to a central change management process. This would make it clear that the SDE is a resource to be used by Programs in implementing higher quality SGML applications. In effect, this would recognize that the value of corporately-shared applications is the product of effective usage which is itself the product of the responsiveness and effectiveness of the SDE. Understanding the SRR as a SDE would also recognize the reality that local implementers within Programs will deviate from using corporate SGML objects as soon as the price of compliance and foregone functionality outweighs the benefits of the corporate applications. The operation of the SDE becomes a service to SGML implementers.

4.4: A Typical SDE Process

An example will serve to illustrate how the SDE would function. Suppose that we have been asked to form a DTD development team to address the publication requirements of a new piece of communications equipment. To date, we have had little or no exposure to the departmental information management and publications bureaus. After a few inquiries, we learn of the existence of the SGML Registry and Repository and its availability as a Shared Development Environment for use by the team. Accessing the SDE, we encounter a vast repository of information regarding corporately-shared applications that can be used to address our requirements. We also discover that we are not alone and that there are other Program initiatives that, from the documentation available, appear to share a remarkable similarity to our own.

Once the appropriate resources have been added to our DTD team, we begin the obvious task of accessing how many of our requirements are addressed by the available SGML objects. We discover that the publication specifications called up in our supplier contract are automatically supported by in-house publishing systems if we adopt the corporate SGML object for base text elements including tables. This makes our first decision, that of adopting this particular object, an easy one. Further analysis indicates, however, that we do have a requirement for a set of content tags that are very specific to the target piece of equipment although many of the available content tags, such as those addressing standard maintenance procedures, will suit our purposes perfectly.

The DTD team directs its energies to modelling these unique features. The DTD team makes extensive use of the online reference material provided by the SDE. The team finds industry-adopted DTDs for comparable communications equipment and borrows heavily to address our requirements. The team also finds a DND SGML object that embodies content elements that are closely related to those we seek to develop. The team decides to address our requirements by customizing (through augmentation) this SGML object. Once this modelling is complete, we assemble the building blocks into what will become our DTD. We are ready to invoke some of the services of the SDE.

The DTD team electronically submits a request for a specific range of services from the SDE administrators. Firstly, we would like a technical review to be performed on our DTD. This review will test our DTD for validity, using multiple parsers, compatibility with multiple commercial applications used in the Department, and for processability by corporately-shared applications such as publishing services. Simultaneously, we request that the variant of the SGML object that we have created by adding new elements to an existing SGML object be considered for certification as either the new official version of the SGML object or as an approved variant.

The results of the technical review are returned to us electronically after many of the tests have been performed programmatically based on our request. The review includes the observations and recommendations on our content model as made by the SDE administrator and one subject matter specialist (from another project) whose input was solicited by the SDE administrator. One section of the review highlights where the approach that we have taken will pose some difficulties for shared applications. The report specifies what applications are effected and in what way. Many of the recommendations received in fact identify changes in our content model that would resolve the difficulties while still meeting our intended objectives.

As a separate event, we receive a detailed response to our request for certification. The certification response includes input from a variety of stakeholders, all of whom are currently using the SGML object that we are proposing to modify. The certification response indicates that all critical issues raised by the stakeholders or by incompatibilities with corporately-shared applications will have to be resolved if the request is to result in a new version of the SGML object being certified. If, after further analysis, unresolved issues remain related to specific stakeholders but all incompatibilities with corporately-shared applications are resolved, then certification as an approved variant would be forthcoming.

From the perspective of the DTD development team, it is perfectly clear where we stand in terms of the change management process. The apparent responsiveness of that process to our requests has given us confidence that we will be able to address our requirements while also participating in, and benefiting from, corporately-shared SGML applications.

4.5: SDE Performance Metrics

There are two critical features of the Shared Development Environment (SDE) for SGML objects. Firstly, the reusable SGML objects, reference information, and support services must be value-added to the degree that Programs and new SGML initiatives will, by accessing the SDE, automatically reduce the cost and risk of their own SGML implementations. Secondly, the responsiveness of the SDE to requests for information, services or certification must be optimized. Time is one of the most precious commodities in any Program. Unless implementers can determine that the entire SGML SDE and change management process is supporting them and their requirements, and doing so in a timely fashion, then the willing participation of those implementers will not be forthcoming. The process, as a result, will break down. All corporately-shared applications that rely upon some measure of uniformity in SGML implementations within the department will be at risk.

The ability of the SDE to gather performance metrics will be an important feature. The SDE must monitor response times for service requests, the development times for new SGML objects, and the process cycle times for certification and change request review. The SDE will be designed to be continually adapting and improving. The administrators of the SDE must be oriented toward introducing improved automation such as automated workflow to distribute input requests to stakeholders of an impacted SGML objects. Performance metrics will provide the best mechanism to determine the effectiveness of the SDE and the departmental SGML strategy. It is the best way to ensure, through proactive corrections to the process, that the benefits realized today through corporately-shared applications are realized tomorrow.

5: Conclusion

Systems, like life forms, must adapt to survive. This truism underlines the basic approach being taken in DND to managing investments in SGML objects and shared applications. The value to the enterprise of the savings and efficiency gains offered by just the SGML initiatives underway today, makes it imperative that we get the management of departmental SGML objects and applications right. It becomes apparent that the most important of the corporately-shared applications is the change management system itself. A successful change management system will ensure that SGML objects, shared applications, and Program and user requirements evolve in a coordinated manner. To be successful, the change management system must be responsive to new requirements as well as being highly attuned to its own performance. Given the general objective of coordinating SGML projects to maximize corporate benefits, the change management system must be fully "adaptive", adjusting its operations to match its performance to the demands of the environment. It must be granted that establishing a management regime that strives to protect corporate

benefits by effectively, and proactively, supporting local initiatives is both technically and culturally challenging. Unfortunately, it is also the only approach that has any chance of success. To return to our guiding truism, where change and variability are part of the environment, systems, like life forms, must adapt to survive.

5.1: Cultural Issues

As a final note, we should emphasize that there are two major cultural issues that present themselves when we consider this approach. The first issue pertains to Programs. Programs must be encouraged to actively participate in the established corporate processes rather than budgeting and planning for maximum self-sufficiency. Within the typical Program office, the general desire to reduce risk by limiting dependencies on matrix organizations often manifests itself as a genuine belief that their requirements are unique, and therefore cannot be supported by a corporately-shared application. This inclination must be replaced by the desire to reuse what is available and specifically address what is actually unique.

The second issue pertains to the central agencies that are typically called upon to administer standards and shared applications. These organizations have existed for many years and have survived the continuous pressure to reduce overhead by establishing their indispensability as guardians of standards and policies. For many of these organizations it is the protracted dialogue on waivers and change requests that gives them organizational life. In the near future, however, this type of role will no longer be tolerated within streamlined enterprises. What will be tolerated, even demanded, will be proactive coordination services such as those described for the SDE. The cultural shift for these organizations will be a change in how we understand the value of standardization. Effective standardization will no longer be measured by effective enforcement. Effective standardization will be measured by effective usage and by the benefits achieved thereby. It is a very new world for many who are familiar with older operational paradigms. However, to re-use our truism in a slightly different way, life forms, like systems, must adapt to survive.

Epilogue

Looking back on this, from the vantage point of 2016, we can see several noteworthy things in this article. For example, we see how a large enterprise came to view document content in terms of modular content models and element variants. We also see the vital importance of associating these constructs with application behavior without which it is impossible to meaningfully assess or manage those constructs (following the logic of formal functionality-grounded Configuration Management).

It is probably worth noting that armed with these best practices, the DND CALS Office was able to effectively address complex multilateral information challenges across NATO where other markup standards (specifically the Department of Defense’s library of CALS markup standards) had proven unsustainable.

It is also worth pointing out that the markup standard that evolved as a result of this effort, the DND CALS Document Type Definition (DTD) and shared application suite, prefigured many of the core tenets now seen in the Darwin Information Typing Architecture (DITA). This should be taken as a corroboration and validation of DITA as it shows how similar ideas will emerge to address similar problems and how those problems are widely experienced by organizations large and small.

- Joe Gollner (2016)