Skip to:

Information Resource Management Models Creation and Use

IRM Guideline 2, Version 1: 094-335
Version Date: 12-1-94

This guideline explains how information resource models are created and used for information resource management. State agencies can use this guideline to improve the quality of their information resources and manage the processes used to develop those information resources. Auditors of agency information resources can use this guideline to determine if an agency has documented its information architecture and the appropriate controls for its maintenance.

This guideline is pertinent to all agency efforts to manage and develop information resources.

Information models are to information management what blueprints are to architecture. Both concisely define and diagram the requirements of a specific project such as creating a building or developing information resources. Information models organize and structure information about an organization from the perspective of its information resources. Models also allow organizations to simulate relationships between different information resources for planning and estimating purposes. An example is the relationship between data and the business locations where they are distributed, which provides visibility into the business locations affected by a project.

Information resources generally fall into one of three broad categories: data, applications, or technology. Different types of models are used to collect and represent different aspects of the organization's information resources. Depending on the type of information being captured, the models may take many different forms. Examples include pictorial representations, semantic representations, diagrams of relationships, or matrices.

Information resource modeling in an IRM environment begins with high level information resource models that are typically built during strategic business and strategic information planning. The information resource models describe an organization's business and the information resources that support it. Information resource models are created to describe the aspects of an information environment that must be managed and developed in a coordinated manner. As the business resources and needs changes over time, the models are modified to reflect the changes.

Organizations also create migration plans for sequencing the development of new resources and for migrating old resources or systems into a new base. To accompany the plans, migration models are created to reflect the transition from the old to the new. Implicit in the creation of migration models is a documented "baseline" of existing resources or systems to be migrated. This baseline is a prerequisite to the creation of migration models, thus must be defined and documented as a first step. Migration models are then developed using the baseline, the information resource models and the migration plans. These models show the transition between the baseline and each type of information resource that will be developed and managed in the future.

Project models reflect the subset of agency-wide or migration models that apply to a particular project. However, this does not mean that agency-wide or migration models must be completed prior to doing any projects. Some projects may not require all of the models, and some, such as fixing errors or modifying user reports, may not affect any models. Also, not all projects can wait for the creation of agency-wide or migration models. For appropriate projects, it is desirable to begin with agency-wide and migration models. However, they should not be created solely for use in a particular project if they would not add value to the project or might serve to delay its completion.

Eventually agency-wide models will be used to develop all future information resources. Therefore, they should represent strategic directions for information resources rather than current systems. There is, however, a need for managing existing legacy systems within an IRM environment until such time as the future resources can be built. Therefore modeling efforts should achieve the appropriate balance between the future and the present. In some cases both views may need to be modeled; in other cases the balance may be best achieved with migration models that show both views and the transition between.

Models are important elements in successful information resource development. During the planning phases of a project an organization will document, via models, the critical aspects of information architecture that will be developed. For most new development projects, this effort will build on existing models that were created during strategic business planning. For conversions, migrations, or large maintenance projects, migration models may be used as well. In the case of small projects that enhance or fix problems, the high level models may have little or no effect on the projects.

During project planning and scope development, project requirements are applied to the baseline architecture. This process helps determine which models are appropriate for the project and which portions of the models will be developed. This information is used to establish the project scope. The relevant parts of the agency models are then refined and become inputs to the management framework. If agency models do not already exist, the portions relevant to the project need to be created before the project scope can be finalized and the project can begin.

The management framework manages the progression of projects through the development process, from design through implementation. The refined agency models are used primarily in the design phases, which include conceptual, logical and physical design, but may be referenced and updated throughout the development phases. The architectural control portion of the management framework ensures model integrity, proper use of models, and compliance of information resources to model requirements.

In the conceptual design phase, the project portions of the agency models are refined as more detailed design requirements are identified. The resulting "conceptual models" still reflect the business view of their respective information resources. The conceptual models are then used as inputs to the logical design phase.

"Logical models" convert business views to an information processing point of view. At the logical design level, models are detailed enough to create a physical design, but generic enough to be independent of any specific physical implementation.

"Physical models" can be created from the logical models to reflect the requirements of a specific physical implementation. For example, performance concerns related to a specific data base manager or communications network are taken into consideration during physical design. In model-based development, the design is completed "on the drawing board" before construction of information resources begins. Examples of design deliverables that can be produced "on the drawing board" include updated information resource models and actual working prototypes. The focus on completeness and quality design is a change from traditional systems development, when it was common to start construction before creating the design. It was also common to build systems without information resource models. Models, if built at all, often represented only part of the business or only one of the design phase views (i.e., usually only the logical or the physical views).

The creation of design models does not need to slow down projects or prevent the use of new or automated development techniques. Although traditional approaches sometimes bypassed portions of design, it is important to note that RAD (Rapid Application Development) and prototyping techniques do not. Instead of doing different things, they do things differently to simulate designs or create iterative cycles of design improvement. In fully automated development environments, models are used to generate prototypes using CASE (Computer Aided Software Engineering) tools. These tools can generate computer code directly from information resource models. Design iterations can be produced by changing the models and generating new prototypes. Depending on the actual production environment, the prototypes may or may not be eventually used as the base of the "real" -- construction phase -- products.

Techniques such as RAD and prototyping were actually invented to speed up development by improving the quality of design information that drives construction. They have accomplished this by organizing and sequencing the design activities differently, providing different mechanisms for generating and validating designs, and providing means for involving business users in the design review process.

Regardless of the development techniques used, the design phase needs a completion point at which time all of its activities have been performed and deliverables produced. Among the deliverables are the business requirements that are captured in the models. These requirements are developed and/or validated during the design phase as part of developing quality information resources. Models are used to improve the accuracy of these requirements by providing a concise means for capturing and documenting them.

The traditional short-cut approach to building information resources loses some of the important benefits that can be realized from the use of models. From a requirements point of view, models capture information concisely at each design or development phase. Other methods, such as narrative documentation, often lack the clarity needed later, or can result in requirements with ambiguous meanings.

Additionally during each level of design -- conceptual, logical and physical -- models add benefits not realized with other approaches that do not use them. Conceptual models provide visibility of how information needs address public policy requirements and business needs, or how business changes will affect information resources. Logical models provide a "road map" that can facilitate future development in a different (or an additional) physical environment. This is accomplished by retaining the logical model, which shows the original intent before technology constraints were applied. Physical models reflect an actual implementation based on specific technology. Therefore future technology changes can be compared to models of physical implementations to assess the impact of new technologies. Also implementation compromises made for a previous implementation can be reevaluated when new technology is introduced.

Without physical models, an actual implementation cannot be examined outside of the live system. It can be difficult, if not impossible, to determine if optimum performance was achieved. Additionally the absence of physical models might suggest the system was built by trial and error, therefore may not have achieved the best result.

One of the most important benefits of having three levels of design models is ensuring future capabilities. The visibility at each level improves the ability to react rapidly and flexibly to future changes and to recognize opportunities for improvements. The "map" between the levels allows simulated re-mapping to new technologies or to evaluate possible reengineering opportunities. Since requirements are captured within the models, future needs can be evaluated without having to reinvent previous thinking. Also models can be more easily changed than systems that have already been built, so the cost and time required to make changes can be reduced with the model-based approach.

The clarity of meaning, conciseness of requirement definitions and the future flexibility / changeability add value to the development process and to the quality of information resources.

Information models help information resource managers concisely define and represent complex details about information resources. Models exist to support a business or analysis effort rather than as an end in themselves. Modeling methods tend to evolve with technology changes. When new technologies for organizing, managing and communicating information are developed, they are usually followed with new ways of defining and representing information. As a result, several types of models exist, with variations that have evolved to represent different perspectives or types of details. Each has its purpose. Each is good at representing some things, and not as good at others. It is important to understand the utility of each type of model, and to select those most appropriate to particular business or analysis objectives.

Although modeling techniques change over time, the type of business information they represent remains fairly constant. For example, organizations have always performed functions, used data, and developed business rules. Information about these functions, data and rules has always been essential to the conducting of business. These basics have endured over time even though technology has drastically changed how the business, and its information, is perceived, organized and managed. While the type of information that should be represented in models tends to remain constant over time, the actual information content and how it is modeled and organized may change.

It is therefore important to have a good modeling strategy in place that addresses the constancy of the basics as well as the dynamic nature of the technology and modeling methods. The strategy also needs to establish the degree of standardization necessary to ensure good communication and consistent interpretation of the models between individuals and organizations.