Implementing Information Architecture Using XML: A Business-driven Approach

As the information generated by enterprises increases in quantity and complexity, there is an increasing interest in using XML for content management. While there is a lot written about the technological aspects of XML-based content management solutions, there are a few important considerations that should be made when implementing such a system across an organization. In this article, we will focus on a few of these aspects that are easy to miss in the excitement of trying to implement an XML-based information architecture in an organization. This article does not discuss the specifics of all steps of XML implementation; however a summary of the proposed steps is provided near the end.

is critical. Support from senior management also ensures that the necessary resources needed for the effort are available and that the persons concerned assign priority to the effort.

The idea, then, is to approach the implementation of XML-based information architecture in a way that focuses on the concept of the benefit to business. An analogy can be drawn with the way "six sigma" has come to be associated with quality. Viewed in isolation, it is a way of statistical process management, with all the associated statistical concepts of distribution, variation, and so on. However, its promotion as a tool for improving quality makes it interesting to management, and consequently helps gain their support for its implementation. Similarly, XML based information architecture should be centered on improved information flow, with all the attendant benefits, rather than on buzzwords and technological jargon.

Ensuring Active Involvement of Stakeholders

A stakeholder in the context of this article is anyone who represents a team of people who will be affected by the implementation. For example, the objective of XML implementation might be to create a solution that helps sharing of information across technical writing teams, field engineering teams, training and education services team, and the marketing team--in which case all business heads and managers in these departments can be considered as stakeholders.

The implementation should be introduced and managed in ways that encourage participation of various stakeholders. In many cases, there is too much emphasis on the underlying mechanisms and implementation details of XML rather than on the benefits of an XML-based information architecture strategy. This has the risk of alienating stakeholders whose focus is on challenges related to the management of information in their respective groups, rather than on the specifics of programming and implementation details. For example, the head of a Field Engineers' team could be averse to the idea of her team "having to use a DTD-based structured authoring solution". However, she might be interested in the idea of an easy-to-use system that helps the field engineers create information in a way that can be classified and retrieved easily. She might want to take up this idea further to see how such a system can be used for information sharing between her team members and customers.

Another area to be addressed at the beginning of the implementation process is to identify, as far as possible, the implicit and explicit concerns of the stakeholders. For example, some of them could be averse to the idea of changing their existing authoring systems. Similarly, others could fear that such an implementation will mean that they and their team members have to learn the intricacies of XML. Or, there could be a concern about the conversion of legacy documentation to the new format. Interestingly, some of these concerns might never be expressed directly, for fear of appearing ignorant or not technologically savvy. These concerns should be identified and acknowledged, perhaps even clearly articulated upstream, by the implementation team. A plan must be presented to address these. For example, it should be made very clear that authoring in the new environment will not need knowledge of how to create DTDs. Similarly, a long-term strategy to handle the process of migration can be included in the early stages of implementation. If the concerns are identified and logically addressed, the chances that the focus of the implementation exercise is on the benefits increases greatly.

Ensuring Technology is an Enabler and Not a Driver

It is easy to get excited about the technological details of the implementation and to fall into the trap of a tools-driving-processes approach. Much of the discussion on XML revolves around Schemas and Document Type Definitions (DTDs) and whether one editor is better than another.

However, as in any business project, tools are just that - tools to implement the business process effectively. Any discussion on tools is futile until the business needs have been identified and prioritized first. In the case of XML, until the information needs and the current details of information creation and management have been identified, it does not add value to debate whether one DTD is better than another.

The selection or adaptation of technology must be based on the information processing needs. It is also important to monitor many of the questions and challenges that arise during the development or adaptations of the tools. For example, decisions related to elements and attributes could have a direct bearing on the way information is created or distributed. The developers should be encouraged to understand that the technology-related decisions might have a bearing on the overall information flow. They should be encouraged to work closely with the broader implementation group to take decisions that are consistent with the overall objectives of the implementation needs.

Avoid the creation of just one tool for all approaches, where one "standard" way of creating or processing information is forced on all departments or groups. The flexibility of XML should be fully exploited, and tools should be adapted to the needs of the processes and business groups.

Suggested Methodology

In the context of the discussion so far, here is a broad outline of some of the critical steps in the implementation of an XML-based information architecture solution:

• Create a business case to highlight the need for XML-based information architecture

• Ensure (throughout the process) that the communication and promotion is done in terms of the benefits and not the tools or technological underpinnings

• Get management support and commitment

• Address concerns of the stakeholders upfront and get their active involvement

• Identify the scope of the implementation

• Identify the metadata units across all participating groups

• Create processes to implement the authoring, delivery, and storage of the metadata

• Develop or adapt tools and technologies

• Create a prototype and incorporate feedback

• Implement a pilot project and incorporate feedback

• Rollout the project in phases

• Create and implement a strategy for maintenance and enhancements

Summary

It is important to have an organization's XML-based information architecture implementation driven by the business needs and management perspective, rather than an Information Technology perspective. It is also very important to promote such systems for the benefits they will bring instead of highlighting the technology side of implementation. The stakeholders must be engaged constructively, keeping in mind their business requirements and concerns. The focus of the implementation should be on improved information management rather than on merely changing the tools and processes that everyone works with.

Asit H Pant and Aoyon Choudhary are Technical Publications Consultants with Cadence Design Systems.

STC India | Home | Contact Us

Copyright © 2005 India Chapter STC. All rights reserved.