Implementing the Information Architect Role in the Rational Unified Process

Home/Publications/Best Practices Newsletter/2004 – Best Practices Newsletter/Implementing the Information Architect Role in the Rational Unified Process


October 2004

Implementing the Information Architect Role in the Rational Unified Process

CIDMIconNewsletter Visnja Beg, Michael Priestley, and Amber Swope, IBM Corporation

The IBM® Rational Unified Process® (RUP®) framework is a process framework that is adopted by many software development organizations to guide their endeavors in developing quality software. Information development and delivery has much in common with its software counterpart, so the software development process and best practices described in the RUP framework can be easily mapped to an information-development process.

In software-development organizations that are using the RUP framework, introducing a RUP-based approach to information development is logical and can foster communication and understanding. Because both are using a similar process framework, deliverables between information-development teams and the software-development teams they support are more easily aligned and coordinated. In addition, information-development teams can reuse artifacts from other teams, such as product management and software development.

Introduction to the Rational Unified Process

The RUP framework is a flexible software-development process platform for guiding software-development organizations in developing quality software. The RUP framework is configurable and adaptable, so implementers can select and deploy only the process components they need for each stage of a project. It is designed using an underlying object-oriented model, similar to how software is designed.

The RUP framework has two dimensions: a dynamic horizontal dimension representing time and showing the lifecycle aspects of the process and a static vertical dimension representing the core process disciplines that group activities by their nature. The dynamic aspect of the process is expressed in terms of cycles, phases, iterations, and milestones. The static aspect of the process is described in terms of process components or as activities, disciplines, artifacts, and roles.

There are nine core workflows in the RUP framework: business modeling, requirements, analysis and design, implementation, test, deployment, configuration and change management, project management, and environment. These workflows encompass activities that span and vary in effort throughout the RUP framework phases of inception, elaboration, construction, and transition. Figure 1 illustrates how the activities for the workflows map to the RUP framework phases.


Figure 1. Rational Unified Process Framework Phases and Workflows

The RUP framework identifies roles, disciplines, activities, and artifacts. A role defines the behavior and responsibilities of an individual or a set of individuals working together as a team. It is not limited to a job title. Roles are also grouped into various disciplines, such as tester, manager, or implementer. An activity is the smallest group of work that is relevant. An artifact represents the modeling constructs and documents that activities evolve, maintain, or use as input.

There are six best practices of software development in the RUP framework: develop iteratively, manage requirements, use component-based architectures, visually model, continuously verify quality, and control changes. Although these best practices are identified in the RUP framework for software development, they are transferable to a number of disciplines, including information development.

Incorporating Information Development into the RUP Framework

While the RUP framework has considerable relevance to information development, the mapping is not completely straightforward for two reasons: first, information development has its own roles and responsibilities, such as the information architect role and link management activity, which do not have exact equivalents in software development; second, information development is not an isolated process but an integral part of the software-development process. While it can be usefully modeled on its own, there is much to be gained from considering it in the context of the broader processes that surround it.

Previous papers have considered both the application of the RUP framework to information development as a stand-alone process and the possibilities for integration of information-development processes into the RUP framework. This article examines how the RUP framework could incorporate information development using one particular role and phase as an example, to suggest how both information-development processes and software processes could benefit from a more explicit recognition of information-development proesses in the RUP framework.

For this example, we will assume that information development has been modeled with a fair degree of detail, with a large complement of specific roles, such as

  • information developer
  • information architect
  • page designer
  • information product manager
  • tools specialist
  • editor

We will also limit the scope of this example to the product-level implementation to avoid the complexities inherent in implementing architecture across multiple levels, such as the cross-product and component levels.

We will further limit the example to the information architect role and its activities and artifacts in the elaboration phase. We will see how its responsibilities, activities, and artifacts could be expressed in RUP notation and what leverage might be gained from relationships to other elements in a software-development project following the RUP process.

Information Architect Role: The Elaboration Phase

The information architect role for information development can be seen as corresponding to the software architect role for software development. In our example, the information architect drives technical and organizational information decisions such as linking strategies, interaction with non-product information resources (including training, Web content, and technical support), authoring structure, and cross-product and internal product navigation. These tasks can be broken down into several activities, five of which can be performed in the elaboration phase of the information-development process.

Figure 2 illustrates the activities that the information architect might perform in the elaboration phase and artifacts that the information architect might produce.swope 225

Figure 2. Information Architect Activities in the Elaboration Phase

Table 1 lists the information architect activities with their corresponding input artifacts and output artifacts. Italicized input artifacts are artifacts that can also be provided by other teams, such as product management or software development.

Table 1. Information Architect Activities, Input Artifacts, and Output Artifacts


Input artifact

Output artifact

Identify information types

Existing information types

Information types

Identify content classes and delivery media required by audience

Audience analysis*

Content class definitions

Information requirements

Content classes

Define information navigation and linking (taskflow and supporting information, as well as linking)

Use case model*

User scenarios*

Audience analysis*

Task analysis*

Linking guidelines


Linking model

Names of topics

Develop welcome experience structure

Audience analysis*

Task analysis*

Information requirements

Welcome experience file structure

Define metadata guidelines/standards

Existing standards

Information requirements

Metadata guidelines/standards

*Artifacts from other roles in current RUP process

Identify information types
An information type represents the form or structure of information. For example, concept topics have a prescribed structure in that they contain only conceptual information. They do not contain steps or procedural information. Instead, task topics contain the information for completing a task, such as prerequisites, steps, and results. Information developers combine topics of different types into content classes or sets of documentation that meet specific user needs. For example, installation information may contain concept, task, and reference topics. By identifying a well-defined set of information types, you can promote consistency among topics and help information developers more easily write task-based information.

Identify content classes and delivery media
To identify the content classes that will best meet the needs of users, the information architect must know who the product users are.

This information might come from an audience analysis for the product performed in the inception phase.

This activity would build on activities in the inception phase, when the information architect identifies the available content. The information architect can now identify which content classes best provide the information the users need, evaluate the product information requirements-such as accessibility, translation, and product requirements-and determine which delivery medium is most appropriate for each content class.

Define navigation and linking
The navigation is how users will access information for each information deliverable. For online Help systems, the navigation includes a task-oriented table of contents (TOC), an index, and a search capability. In addition, it can include various paths through the Help system, with links to topics within the Help system as well as links to external content such as samples, tutorials, and Web sites. For softcopy and hardcopy deliverables, the navigation includes the TOC and index.

To develop the proper navigation for each deliverable, there might be several information sources within the RUP framework: the use-case model and user scenarios from the software-development team, which explain what use cases the product will support and the expected user scenarios; task analysis that identifies the tasks users will perform when working through their scenarios; and audience analysis that identifies the goals, skills, and requirements for the product users. Once the information architect has this source material, it can be used to identify what information the user needs, the order in which the information should appear in the TOC, and the best access paths for the information, including links from user tasks to supporting information. For online deliverables, these access paths might include a Help menu, contextual Help hooks, one or more TOCs, search, an index, and links from one topic to another.

Develop welcome experience structure
The welcome experience is the initial, out-of-the-box experience that users will have with the product. To provide a useful first experience, the information architect needs to know who will be using the product and what they are going to do with it. Once again, there may be an opportunity to get information from existing activities in the RUP framework’s inception phase, specifically audience and task analysis. The information architect would also consider the product information requirements, including environmental constraints such as the operating system, whether it supports playing videos, and so on.

Define metadata standards
The product information requirements and existing metadata standards will help the information architect define the metadata that information developers need to specify and how they will use the metadata to produce deliverables. For example, index keywords might be needed to support an online index.


There are many known benefits from following a formalized development process, such as the RUP framework, for software development. If the team is producing information for an application and can integrate the information-development process with the development process the software team is using, then the information-development team can realize even more benefits.

Some of the benefits of following a similar process for information development are

  • reuse of development artifacts such as use case models, user scenarios, and audience analysis
  • synchronization of the software and information-development schedules to follow similar milestones and phases
  • improved communication with other members of the software-development team by using a consistent development vocabulary
  • framework for defining an information-development process that can help in defining a more complete process
  • validation of information development as an integral part of the application- development process

To achieve these benefits, analyze the application-development process used by the software-development team and determine what portions can apply to the information-development process. This means that the information-development team must define the roles, activities, and artifacts it needs to successfully produce high-quality, consistent, usable user information. This article can provide a starting point for this analysis and a partial view of how this integrated process might look. CIDMIconNewsletter

About the Authors

October04a4 October0426