Strategic Planning for Information Resource Management



The Council of the Malaysian Institute of Accountants has approved this Foreword for publication.

The status of Statements on International Management Accounting Practice is set out in the Council’s statement on Approved Management Accounting Statements.










A New Role for Information Technology



The Force of Packaged Software



Importance of Technology Flexibility



Emergence of New Work Systems









Determine Strategic Information Resource Requirements



Baseline Existing Environment



Define the Information Resource Environment



* Develop Information Models



* Develop Target Architectures



* Maintaining the Target Architecture





Project Selection Mechanism



- Scoring Criteria



- The Scoring Process



Selection Process







Strategic Review



Tactical Review







Chief Information Officer



Information Systems Steering Committee



User Department Management



Management Accountants



Internal Auditors



Information Systems Specialists






Public and private sector organizations alike are reshaping and streamlining their business processes, placing increased emphasis on the customer. Success in this initiative depends on understanding the customer base, its preferences, its behaviours and its needs, as well as the company's ability to respond. In this situation, most organizations have an abundance of information upon which to draw. Unfortunately, if the infrastructure does not provide for the effective creation, use, management, access and delivery of relevant data, the organization will be totally frustrated in its efforts to capitalize on its base of information.

Fragmented automation efforts, unilateral commitment to mainframe-based applications, incompatible proprietary hardware platforms, disparate software, and inaccessible data do not satisfy the need for information systems to be an essential, indispensable and strategic component of service delivery and no longer satisfy the business and service goals of many organizations. A revised approach to planning that recognizes the relationship between business planning and technical infrastructure is needed.

It is critical that this approach address the requirement for:

  • satisfying customer needs;

  • responding to changing organizational structures;

  • taking advantage of open system concepts;

  • adhering to industry standards;

  • providing distributed, coordinated and accessible hardware, software and data resources;

  • supporting redesigned processes;

  • responding to changing requirements;

  • being easy to use; and

  • recognizing the significance of data as a corporate resource.

From a purely technological perspective, most information systems organizations recognize that data need to be managed, but relatively few organizations recognize that the knowledge housed in the organization's databases can provide the means to rapidly propel the organization forward, moving ahead of its competitors in the process. The first organization in an industry to recognize and exploit the value of a particular piece of information, often something that is available to all industry members, gains a competitive advantage.

Information Resource Management (IRM) takes a broad view of the enterprise and does not focus too narrowly on the requirements of a particular group or department. An effective strategic IRM plan describes an organization's information requirements and strategies for satisfying them and can yield the following benefits:

  • development of systems that are targeted to support strategic and operational objectives;

  • increased integration of technologies, which improves the sharing of information across the organization and makes it easier to obtain information for changing decision-making needs;

  • identification and adoption of appropriate information technology standards, minimizing dependence on specific suppliers of hardware or software;

  • identification of opportunities to improve the relevance and adequacy of information provided and activities performed;

  • a technological infrastructure that will support the strategic business plan;

  • minimization of duplicate, and possibly inconsistent, data and processing capabilities within the organization's portfolio of information systems;

  • prioritization of projects to be implemented; and

  • greater cost-justification of system development and maintenance activities.

Information is an invaluable asset - IRM assists an organization in its efforts to move beyond data management to the strategically beneficial ability to leverage its information. This guideline is designed to provide the necessary background for an organization to proceed with planning and implementing a cohesive approach to capitalizing on its information assets.

:: SCOPE ::

1.   The foundation for the IRM strategic planning process is the organization's business strategy, its statement of business goals and objectives and challenges. For the purposes of this Statement, it is assumed that the organization has:

  • defined what business(es) it wants to be in;

  • identified its core business processes;

  • identified and analyzed the factors critical to its future success;

  • defined its markets;

  • studied its industry and competitors; and

  • identified its strengths and weaknesses.

2.   The principles described in this Statement are broad-based, but sound: statements of preferred direction, goals and concepts for guiding the development and use of computers, telecommunications equipment and software in support of an IRM environment. Circumstances may indicate that an organization should pursue a specific direction, e.g., buy vs build software or outsource the information systems function. In these instances, the approach outlined in this Statement will provide a systems approach and an appropriate framework for the decision-making process.

3.   The principles are subject to modification according to the size and type of business and as technology evolves and business requirements change. Adoption of these principles will have a profound impact on the management of technology, the structure and configuration of technical facilities, and the delivery of responsive, value-added services to clients and customers.

4.   Using the strategic business plan of the organization as a starting point, this Statement outlines the process for creating an IRM plan. The IRM plan will be of help in the design and implementation of the information systems necessary to support the business plan.

5.   This Statement provides a discussion of the objectives of IRM, the core concepts involved and the functions and responsibilities associated with IRM. It describes the stages of the IRM planning process:

  • translating the strategic business plan into strategic information requirements;

  • constructing business models based on identified strategic information requirements;

  • constructing target architectures from the business models;

  • creating a strategic implementation plan that specifies how the target architectures are to be implemented; and 

  • conducting a post-implementation review to ensure that IRM is achieving its intended objectives


6.   According to Vita Cassesse, Vice President of Systems and Market Research for the U.S. Pharmaceuticals Group of New York-based Pfizer Inc.: "Technology is just one small component of the continuum. ...You can't effectively manage the information unless you know how it needs to be - and why it needs to be - communicated."1 Equally important is the need to recognize that information technology cannot, by itself, transform data into knowledge. Thomas H. Davenport, Director of the Information Systems Management Program at the University of Texas in Austin, says: "Nobody can say they're not interested in how to make effective use of information ...You can't become a successful executive unless you've mastered that to some degree."2

7.   There is no one in any information technology-related function, business or organization that does not think about information as an asset in today's knowledge-based business environment. The question of whether you are in a technology business or an information business is irrelevant: the real issue is how to assemble a technology infrastructure through which the best and most appropriate content (i.e., information) for your organization's needs can flow. This is a major challenge when the volatile business environment of today is coupled with the dynamics of the contemporary technology environment.

8.   There are many events currently underway that could have a profound effect on how an organization should deal with the coming together of business and technology. In many instances, these events are external and uncontrollable. Nevertheless, it will remain the responsibility of each organization to incorporate these unplanned (and often unsolicited) occurrences into their everyday business activities. In order to provide the insight necessary to keep the advice provided in this guideline in the proper perspective, a few such significant shifts are discussed in the following paragraphs.

A New Role for Information Technology

9.   There are some fundamental shifts now occurring in the application of computers in business, each affecting a different level of business opportunity. Information technology supports the implementation and maintenance of a high performance team structure, allowing the organization to function as integrated businesses despite high business unit autonomy, and to reach out and develop new relationships with external organizations - to become an extended enterprise

10. The virtual corporation, i.e., a radical approach to organizational transformation that results in a flexible, responsive and effective entity designed to satisfy the demands of a volatile marketplace, would not have been possible without today's sophisticated information technology. "Unlike yesterday's producers, the virtual corporation can use technology to overcome the barriers imposed by time and distance. ...By the end of this century, the computing environment will be essentially unrestricted, and technology will be sufficiently portable that it will become part of a person's daily work apparel. ...Today, even basic technology is more than a tool; it is an ubiquitous member of the work team, undertaking tasks that are routine and mundane and gathering information about the process, about the end product or service and about the eventual customer. Over time, consistent exploitation of this information can provide an organization with a competitive advantage, assuming that it is able and willing to take action."3

The Force of Packaged Software

11. Today many software packages are designed specifically for particular applications and for specific vertical industries and are hardware independent, i.e., they can be installed on many different computing platforms and on multiple sizes of computing equipment. Consequently, in many cases it is much more cost effective to acquire such "off the shelf" software than it is to design and develop code from scratch. The best approach in this situation is to aggressively pursue documentation of requirements before proceeding with the selection of a package. Otherwise, it becomes all too easy to select the application software with the most features, regardless of whether or not it matches the organization's processing requirements or can accommodate its information needs. While packaged software can, in most cases, be adapted to suit specific needs, if the required modifications are extensive, little of the original code will remain, resulting in a unique, and often costly, installation that is difficult to maintain. Nevertheless, "buy vs build" is the direction taken by many organizations when new software applications are needed.

Importance of Technology Flexibility

12.  There are three distinct, but related, technology developments that are key to flexibility and adaptability:

  • Open systems are based on standards that are vendor independent and commonly available. Because of the opportunity for migration to newer, updated technologies based on the organization's own requirements and timetable, adherence to open systems policies results in reduced information technology-related costs and provides value added benefits such as reduced risk of vendor dependence, architectural flexibility, improved interoperability amongst applications, easier migration to newer, innovative technologies and a much better choice of packaged software.

  • "Client/server systems are built from readily available, standardized components that can be expanded as needed and distributed as most appropriate to the needs of the organization."4

  • "Object-oriented systems are built on a similar extensible model - function specific objects are used to build the desired system. Alterations to a system, to accommodate changing business requirements or to incorporate improvements, can easily be made."5

Emergence of New Work Systems

13. The rate of organizational change is almost overwhelming - on a daily basis we face new ways of doing things, new tools to use, new things to be done and different people to do them with. New business themes, each of which demands a new information technology paradigm, are emerging in today's strategic plans as firms re-engineer themselves for the environment, for example:

  • productivity of knowledge and service workers;

  • quality;

  • responsiveness;

  • globalization;

  • outsourcing;

  • partnering; and

  • social and environmental responsibility.

14. Organizations are taking tough actions and making difficult decisions and irreversible changes. Incremental continuous change is part of total quality management programs; periodic radical change is part of business process re-engineering; reduced workforces are part of downsizing; the shift from personal to work group computing is part of the movement toward the work-team approach to employee empowerment. There is no question that survival will be difficult without a major overhaul of organizational structures, job content, human resource policies and practices and, of course, the provision of a technological infrastructure that provides access to information - the key ingredient of contemporary business.

15.  New work systems take advantage of a synergistic relationship among people, process and technology. New technology and new work systems must change the nature of jobs if they are to achieve the objective of improved productivity. The corporate culture, whatever its philosophy, will in turn be affected as the flow of work and employee responsibilities change. Management must assess and respond to employees' reactions to this new environment.

16.  As well as expecting technology to be intuitively obvious to use, we must focus on developing employees who can intuitively deploy technology to full advantage. At issue is what we can reasonably expect of workers. In order to develop the necessary level of "know-how" people will need to be exposed to learning situations. Technical resources cannot typically provide the type of coaching and facilitation we now find ourselves needing. It is extremely important for human resource professionals to be partners in these development programs.


17.  In the past, information was considered only as an internal resource, but, today, an organization's data may be part of a national or international knowledge base. For example, many health-care reform scenarios are expected to call for a national network of local health information systems that speak a common language.6

18.  An organization's strategic plan describes how it will advance into the future. The IRM strategic plan should focus on how information and technology will support the goals and objectives outlined in the corporate strategy. IRM strategies must be creative and flexible to address current needs and potentially expanded future needs. There is a need for the organization's IRM plan to mirror corporate strategy, e.g., if the enterprise's strategy emphasizes customer service then the IRM plan must also.

19.  IRM is an approach to strategic information systems planning that emphasizes the importance of information as a corporate resource. It focuses on designing, implementing and maintaining a balanced, enterprise-wide system of information, processes and technology. In the IRM environment, technology is viewed as a means to assist the business to do things better, faster and cheaper - not as an end in itself.7

20.  It is not unusual for an organization to have a customer information system to manage its customer list, a general ledger accounting system to manage its financial portfolio, personnel and payroll systems to manage its employee information, and inventory control systems to manage its investment in raw materials. All of these house facts about the organization, its customers' buying patterns, its suppliers' pricing fluctuations, currency shifts, etc., information that could be used to advantage. IRM is the term used to describe the function that manages, organizes and coordinates the data resources so that it best supports enterprise activities.8 In this context, information systems are considered to be the backbone of a valuable data resource, providing the means to successfully deliver these activities.

21.  An information system is a set of interacting components, e.g., computers, data, human resources, telecommunications, etc., with multiple interactions and relationships among them. Effective information management systems are the product of a carefully constructed IRM environment.

22.  It is often difficult to tell where an information system ends and where its environment begins. Indeed, for the remainder of the 1990s, it is likely that the environment within which IRM is being planned, designed and developed will have many complex and conflicting priorities - business process re-engineering, total quality management, downsizing, mergers, acquisitions and economic volatility. This fact only serves to increase the need for a systems approach to change, one that will provide a stable framework in which change can occur. IRM provides the principles, parameters and standards that define the environment within which information technology will be deployed and information systems developed.


23.  The fundamental objective of IRM is to ensure that an organization's information systems support its strategic direction and business plans and enhance the quality, applicability, accessibility and value of the information resources of the enterprise. Its success in an organization is dependent on the acceptance of four fundamental principles:

  • Data are valuable resources that require proper management.

  • Most data are highly shareable.

  • The ability to share and use data more effectively is a critical success factor for most businesses.

  • Information systems should incorporate a broad view of the enterprise.

24.  An effective IRM program provides for continuously scanning the environment for opportunities that could drive the direction of an organization's business. Information technology planners must have a strategic view on how information systems can increase the opportunities available to an organization and also how to extend traditional business boundaries to include information resource links with customers and suppliers.

25.  David Norton points out in "Stage by Stage"9 that "Traditional boundaries are meaningless. In the organizations of the future, the basic components will be the same but the boundaries of the system will differ as will the relationships of the internal parts." He continues, citing specific examples " each case, a strategic advantage was gained by redefining the traditional boundaries of the business. American Airlines and American Hospital Supply extended their franchises to include the customers (or their intermediaries) at the time of purchase. IBM, Otis Elevator and General Motors extended their franchises to include their aftermarkets for service. Federal Express restructured its internal operations to permit 100 percent positive tracking of en route packages."

26.  Organizations must emphasize strategic planning for IRM in order to gain a competitive advantage as they move into an era of increased automation and global competition. Information systems can help streamline business functions, improve managerial decision making, create new products and businesses and enhance relationships with suppliers and customers.


27.  The ultimate goal of an effective IRM strategic plan is the design, delivery and maintenance of a seamless, integrated information resource environment that responds successfully to the need for cross-functional flows of information while providing the flexibility and adaptability to respond to incessant business and technological change. The requirement is for a set of data transport capabilities and data management interfaces that are usable by each business function, but unique to and owned exclusively by none of them.10 Without a plan there are no objectives, no measures and, ultimately, no results.

28.  There are three key steps involved in planning for the introduction of IRM practices into an organization:

  1. Determine strategic information resource requirements.

  2. Baseline the existing environment.

  3. Design the IRM.

Exhibit 1

29.  As shown in Exhibit 1, the planning process starts with a definition of the business direction, this is the foundation for all subsequent steps. The strategic business planning process ensures that an organization understands its critical success factors, what it must do well to succeed and how it will measure success. Conversely, the strategic planning process provides an opportunity to identify areas of vulnerability, areas that may need to be monitored more closely and potentially subjected to stringent controls. All of this helps an organization to plot its course for the future. Critical success factors and the measurement criteria will vary from one organization to another, and will also change over time for a particular organization, depending upon the business environment and on the organization's direction. Typical examples of what an organization must do well to succeed in the next decade are customer service, new product development and cost control.

30.  The business strategy drives the process of determining what information the business requires to support its objectives and how well the existing environment (systems, processes, information, organizational structure, etc.) supports, or has the potential to support, the achievement of the business objectives.

31.  Technological issues are addressed in the third step, where a blueprint of the organization's future computing infrastructure is designed. The blueprint takes the form of a set of "target architectures," i.e., systems and resource architecture, application architecture and the technical architecture, each of which describes a particular component of the infrastructure to be constructed. This is a plan, conceptually similar to an architect's blueprint, describing what hardware, software and databases are necessary to satisfy the strategic information requirements previously identified. The target architectures also drive the design of the organizational infrastructure and the systems and resource plan.

32.  This set of target architectures supports the development of the IRM strategic plan, which, in turn, ensures the appropriate enabling technology and information infrastructure. It articulates how the organization will make the most effective use of information, computers, database technology, decision support tools and telecommunications in combination with other resources to achieve its mission. The IRM Plan reflects the organization's business focus, mirroring its emphasis on customer service, becoming the least-cost provider, expansion, decentralization goals and objectives and clearly states how the IRM organization will support the business mission.

33.  The following principles guide the development of an effective IRM strategy:

  • It must be linked to the business strategy.

  • Cross-functional business processes are central to the planning dimension.

  • The technology infrastructure must represent a "model of the business."

34.  Once the IRM environment has been designed, the action plan is developed and, as shown, because it is recursive, it will be followed by a review cycle. Since the economy, markets and the information technology landscape shift every 12 to 18 months, it is important to repeat this exercise at least every two years. The entire IRM planning and implementation process is iterative; the cycles are dependent on business requirements, environment changes and information technology advances. If the IRM environment is to mirror the business, the review cycles must not be neglected and adjustments must be made to the environment as needed.

Determine Strategic Information Resource Requirements

35.  It is important to identify specific initiatives that will help to achieve the business vision. Based on long-term return to the business, this provides the justification for moving forward with IRM implications. Effective IRM requires that information systems be designed to support the critical success factors and core business processes identified in the organization's strategic business plan.

36.  For example, a core business process might be "product marketing" and a critical success factor in an organization's strategic plan might be expanding its customer base. Studying this factor carefully in the context of the organization could reveal that sales promotion and strategies need to be revised. Critical data to support this revision might include information on prospective customers.

37.  The challenge will be to encourage business management to become involved in the information resource planning process and to increase the information technology group's knowledge of the business planning process. Understanding the technology and basic information building blocks is integral to designing something that will facilitate the business.

38.  It is suggested that a planning group, consisting of the information systems executive and senior managers from key functional areas, should set up a series of planning workshops to examine the critical success factors. It is important to allow for refining the process to ensure that the analysis is complete and to determine areas where attention should be focused. This entire process is much simplified in the organizations that have a Chief Information Officer (CIO), who is a member of the senior management group and, as such, is involved in the business planning cycle from the beginning.

39.  In the past, the focus of information systems planning may have been limited to determining how to apply technology to automate a task. Using the IRM approach more relevant questions might be: "How do I apply technology to competitive advantage? How do I get the right information to the decision makers? Where are the best opportunities to add value through information resources?"

40.  The output of this stage of the planning process is a specific list of the processes and data critical to the organization's strategic direction and objectives. They are the strategic requirements to be satisfied in subsequent stages of the information planning and development process.

Baseline Existing Environment

41.  The base point for developing the new IRM plan is a combination of existing plans, budgets, processes and systems. The purpose of baselining is to develop a complete and adequate assessment of the current environment. Information gathered at this time will provide the framework for assessing the risk/benefit of proposed changes, for structuring a transition plan and for changing the management approach. It will also act as an important feedback mechanism for users to provide input on needed improvements or opportunities for improvement.

42.  Ongoing and planned projects should be reviewed and a summary of the project description, its status, planned completion, and estimate of cost prepared. Some projects may be put on a "hold" status if they depend upon technology or direction that could change radically because of the IRM plan.

43.  The review of budgets should focus upon existing costs to determine what relates to sustaining current operations, maintaining existing systems, developing new systems and managing the department. It is also useful at this time to review long-term leases and licensing agreements to determine cancellation costs or upgrade penalties.

44.  The systems review should focus on obtaining information about:

  • System demographics - its age, the language used to develop it, number of programs, file access or database management system used, hardware environment, etc.

  • Maintenance status - date of last major enhancement, planned maintenance, technical quality, currency and quality of existing system documentation.

  • System functionality - user problems, unmet needs, availability and usability of data and outputs, data security and integrity, future and present business relevance of the system.

45.  Core business processes and activities will be defined and described according to:

  • Desired outcome - what are the measurable outputs or outcomes?

  • Beginning point - where does the activity "begin"; how is it triggered?

  • Technology interfaces - within the activity where, why and how does it need to interface with existing technology?

  • Inter- and intra-organizational interfaces - where, why and how does the activity interface with other business units?

  • External interfaces - where, why and how does the activity interface with external agencies, suppliers and customers?

  • Ownership and accountability - who "owns" the activity; who is accountable for achievement of the overall outcome?

  • End point - where and how does the activity end; what measures are applied to its completion, timeframes, volumes, targets?

Exhibit 2

Questions Addressed During Baselining

  • Are our assets being preserved?

  • How do we control information systems without crippling innovation?

  • Is the information systems department appropriately organized?

  • Are the organization and its human resources "ready for change?"

  • Where should we invest?

  • Do our information systems link to our business strategy?

  • Are we getting a return on investment?

  • Are we taking advantage of strategic technologies?

  • Do we have the right mix of skills?

  • Are we committed to a single vendor?

  • Do we have the right architecture of applications, data, networks and computers?

  • Can our customers use our systems?

46.  The baselining activity will, of necessity, be iterative in nature and, answering the questions listed in Exhibit 2 early in the planning process, will assist the planners to develop a much better understanding of:

  • staffing levels and skills inventory and anticipated changes

  • facilities and resources and anticipated changes

  • in-force policies and procedures

  • information technology - current and planned environment

  • information flow

  • linkages with other infrastructure responsibilities and external agencies, including their information systems

  • inputs, deliverables, customers and key performance indicators.

Define the Information Resource Environment

47.  There are many methodologies and approaches available to assist in planning, defining, designing and constructing an IRM environment. What is important is for the organization to select a consistent approach to be used in all IRM initiatives across the organization. The approach employed in this Statement adds activity modeling to the well-established information engineering approach to business modeling, data modeling, process modeling and enterprise modeling. In this way, we ensure that enterprise-wide requirements are considered, information resources are directly linked to business strategy and goals, and the necessary balance between information, technology, process and organization is maintained.

48.  Modeling is the act of developing an accurate description of a system, i.e., a set of interacting components and the relationships amongst them, a description that includes a definition of all of the important components of the system and how they interact. The reason for building a model is to make it possible to answer questions about a system without having to deal with the system itself. A series of models - business models, activity models, data models, process models and enterprise models - needs to be developed in order to fully appreciate what information resources exist, what are needed and where there are gaps.

Develop Information Models

49.  The modeling process is somewhat labor intensive, requiring significant input from the business units. The models build on one another, each providing a view of information that is somewhat different from, but complementary to, its predecessor model. It must be understood that each model represents a "snapshot in time," a view of the situation as it is seen at the time the model is being developed. Although it appears that an organization's processes change much more frequently than the data it uses or the information it needs, the models should be revisited on a regular basis, for example, on an annual basis when the IRM plan is reviewed. It is suggested that development of the following models be undertaken:

  • Business modeling is a technique for defining the information generated and received by departments in a company. This is the first step toward understanding the nature of the information flow within an organization. Business models serve as a bridge between identifying the strategic requirements and defining the technological infrastructure. They describe how the organization will operate once the strategic plans for IRM have been implemented.

  • Activity modeling is a structured technique for defining who or what performs an activity, what tells them how to do it, what triggers the activity, and what the activity produces. Activity modeling can be used to ensure that information/data is directed to those who need it for their work, minimizing the risk of information overload and redundancy. It also uncovers potential overlaps across the organization. This phase of IRM will require the development of a model of current and future business activities. A series of activities combine to make a business process and an organization is comprised of a network of business processes.

  • Data modeling is a systematic way of identifying the data categories or types that comprise the information flows defined in the business and activity models. Data modeling builds a picture of the interrelationships among a company's data. This phase of IRM will require the development of a conceptual data model, representing the high-level view of the business's databases in the form of an entity-relationship model.

  • Process modeling is used to document the way in which data is manipulated within an organization, i.e., it defines those functions of the system that will evolve into computer programs. This phase of IRM will require the development of the following elements:

    • conceptual transaction model, representing a high-level view of the create, retrieve, update and delete operations required to support the business;

    • distribution model, representing a high-level view of how databases and transactions are, or will be, distributed and where they will reside geographically.

  • Enterprise modeling maps business activity to logical and physical descriptions of data, applications and locations, i.e., it is a method for integrating previously defined data, activity and process models into a consolidated whole, which will assist in sharing information across the company. It may take a very long time to complete an enterprise-wide model, but it is important to make every effort to develop the broadest view possible of the organization's information requirements.

50. While the modeling process can be completed manually, the use of computer-based tools is recommended. In this way, information that is gathered can be stored in an electronic repository for later use. Since we are in a period of continuous change, a static approach to IRM design is inadequate. Business environments continue to be dynamic, and determining which is the most appropriate mix of technologies, human resources, applications, databases, etc. is complex. Powerful simulation and prototyping tools are available to assist systems architects and designers to develop a living model of the business that can be maintained over time as a point of reference for defining the business and information architectures.

51.  The Appendix to this Statement provides more detail about the modeling process and some of the more common modeling techniques.

Develop Target Architectures

52.  The objective of this task is to prepare a suite of system architectures, based upon the requirements defined through the information models developed in the previous stage of the planning process. Target architectures are developed to provide a shared vision of the information resource environment needed to meet the business needs of the organization. The process of designing the architecture organizes the decision steps from business need to technical solution. The term "architectures" is used because the products of the process are analogous to building blueprints, i.e., they specify what the final product will look like once the plans have been implemented. In other words, target architectures describe the organization's future technological infrastructure.

53.  The specific system architectures to be defined include:

  • application architecture;

  • system software;

  • telecommunications; and

  • hardware.

54.  The business value of the target architecture is considerable. Its purpose is to provide guidance and direction for building and integrating applications, data, technology and network communications. Just as sales forecasts provide a target for production and, in turn, for raw materials procurement and labor planning, the target architectures provide a target for systems development and, in turn, for the acquisition of hardware, software and databases to support systems development. It provides the foundation needed to ensure that the different technological components are compatible and can be integrated with each other.

55.  Exhibit 3 provides a list of some of the architectural considerations that are tremendously important if an appropriate IRM environment is to be developed.11

Exhibit 3

Architecture Considerations

  • Hardware, including peripherals - predefined standards, environmental issues.

  • Distributed versus centralized - existing standards, organizational preference.

  • Network configuration - existing network(s), capacity, requirements.

  • Communications protocols - existing standards, protocols being used today.

  • System software - existing standards, options available on anticipated hardware and communications platforms.

  • Database software - existing standards, what is in use today.

  • Application development tools, CASE for example - tools in use today, tools available for potential platforms, database engine, operating system, communications platform.

  • Development environment - standards in place for users/developers, other platform tools being considered, architectural priorities.

  • Application software, make or buy, package selection, etc. - existing standards, industry-standard products, consistency with potential architecture, available support.

  • Human interface - requirements, user expectations.

56.  System architecture is usually determined by how the individual system designer chooses to use the various data processing technologies to meet user information requirements. The underlying data processing technologies can be divided into five major categories:

  • applications;

  • data;

  • system software;

  • hardware; and

  • network.

57.  There are a number of questions to be answered early in the process of architecture definition in order to ensure that the design proceeds in an appropriate context:12

  • How much can the organization afford?

  • What is the level of skill, computer-literacy and ability of the potential system users?

  • What are the real response time requirements?

  • Is it essential that the system be available 24 hours per day, 7 days per week or will something less suffice?

  • What is the security requirement? What is the potential impact of unauthorized access?

  • How frequently might the application(s) change?

  • What is the existing investment?

  • What systems must the application(s) interface with?

58. It is possible that the target architectures will point toward replacement of old platforms. This can be complex, time-consuming, costly, disruptive and generally fraught with risk. The advantages of planning such a migration based on an architectural approach are many, but perhaps the most important is that it provides the blueprint necessary to plan for an orderly transition, weighing risks vs benefits at every stage.

59. Applications and Data Architectures - The objective of the data architecture is to package data into databases. The objective of the applications architecture is to package processes and the data associated with them into applications systems. These architectures are designed using a worksheet in matrix form. An example of such a matrix, based on previously developed business and data models, is shown in Exhibit 4.

60. There should only be one process responsible for creating any particular data attribute. This reduces redundancy and increases data integrity. The matrix therefore provides information about the correct sequence for constructing applications. An application that needs to retrieve a particular piece of data should be developed after the application that is responsible for creating that piece of data.

61. In addition, this matching of data and processes in a matrix provides information about the data and processing requirements of various levels and functional areas within an organization. It highlights which requirements are common to several areas or levels and which are different. This makes it easier to package applications so they best reflect the structure of the organization.

Exhibit 4

Each column in the matrix corresponds to an entity in a data model (or to a grouping of entities), and each row corresponds to a process in a process model. The entries in the cell indicate whether or not each process relates to the data and, if so, how. A process might:

  • add data - for example, the process Maintain Customer Account is responsible for adding a customer to the database

  • access data - for example, Plan/Monitor Sales might retrieve information about customers, products and suppliers

  • update data - for example, Ship Products might update data about customer orders

  • delete data - for example, Receive Orders might delete customer orders once they have been filled

62.  Technology Architecture - The technology architecture, comprised of systems software, hardware and networks, is developed after the data and applications architectures. This represents a high-level specification of the processors, storage devices, network hardware and software, and local and remote operating systems required to support and implement the other architectures.

63.  In order to develop a technology architecture, planners need to know the service requirements of each application and database. Service requirements for applications include response time, turnaround time, hours of availability, volume of traffic, accessibility and backups. Service requirements for databases are the degree of security and data integrity required. Exhibit 5 shows the service requirements for some of the data used in previous examples.

Exhibit 5

64.  For any given set of data and applications architecture there are likely to be a number of alternative technology architectures that will satisfy service requirements. Prior to embarking on the actual development of the architectures, it is helpful if a series of "architectural principles" is developed to ensure that the overall objectives of the IRM program are consistently satisfied. Exhibit 6 is one example of a Statement of General Architectural Principles.

Exhibit 6

General Architectural Principles13

Stakeholders. The architecture will be designed to serve private citizens, corporate citizens, private business partners, public employees, county and municipal governments, federal agencies and other public service organizations.

A.   Citizen focus. All architectural decisions should support the delivery of citizen-oriented systems that are responsive to citizen demands, adaptable to changing business/program requirements, promote high quality service, and are easy to use.

B.   Consistency. Common business and technical requirements should be treated in a consistent way.

C.   Sharing. Architecture components will be sharable.

D.   Openness. Architecture components and associated specifications will use industry standards with preference for vendor-neutral implementations.

E.   Modularity. The architecture will be based on modular components with standardized interfaces.

F.   Buy versus make. Purchasable and integratable components are preferred over custom built or extensively modified products.

G.   Cost of compliance. Compliance with architectural standards may incur higher initial cost.

H.   Measurement. Measuring the use and performance of the architectural components will be performed continuously as normal practice.

I.     Operations. The preferred method of conducting business transactions (both internal and external) is through electronic means, e.g., Electronic Data Interchange (EDI), Electronic Funds Transfer (EFT), Electronic Mail (E-Mail), etc.

J.    Location. Geographic location must not be a constraint to accessing services or be used as the basis for charging for services.

K.   Flexibility for growth/change. The technical architecture needs to be designed for accommodating continuous change and must take into consideration possible future capabilities, as well as meeting maximum current requirements.

65.  Consideration must also be given to trends in information systems technology, adherence to or establishment of corporate standards, e.g., system network architecture (SNA), open systems interface (OSI), etc., and to what elements of the current systems can be modified for inclusion in the architecture. Since it may take an organization several years to reach the desired IRM environment, the potential for including emerging technologies should also be considered in the technology architecture design. Information systems planners need to evaluate emerging technologies and their potential impact on the organization on a continuing basis. This consists of developing an outline of each kind of technology, assessing where it might be used within the organization and estimating a timeframe within which it could be used. The Information Systems Steering Committee should receive an evaluation of any emerging technologies that are likely to have significant potential impact on the business.

66.  Other issues to be considered during architecture design are:

  • Current technology assets - hardware, software and applications portfolios.

  • Distribution of databases and transactions - in the distributed computing approach, databases and transactions are often located at the point where business activities are performed; this can have significant implications for the technology architecture.

  • Best technology - in preference to one common standard, select the best type of technology for the work to be done.

  • Interchangeability - technology components selected on the basis of easy substitution without service disruption.

  • Workstation orientation - desktop devices that are intelligent multi-functional workstations.

  • Networked environment - all workstations networked, either locally or through wide area networks.

67.  The system software architecture is determined by a number of technical products that are used to facilitate the operation of, and user interaction with, application programs. Major components of system software are:

  • operating system(s);

  • telecommunications monitor;

  • network software;

  • file access method;

  • database management system;

  • fourth-generation language; and

  • programming languages.

68.  System software architecture and hardware architecture must be evaluated together, since the choice of system software may be influenced by the hardware choice and vice versa. The hardware architecture in most computer configurations consists of:

  • central processing unit;

  • disk drives;

  • tape drives;

  • terminals/workstations;

  • printers; and

  • controllers.

69. The network architecture involves the definition of both local area networks and remote telecommunications lines and controllers to support distributed terminals and printers and to link remote central processing units.

70.  As the proclivity for client/server computing increases, so does the potential for multiple hardware and software components from multiple vendors as well as many related interfaces and interconnections. The potential for complexity is enormous; there are many issues to be resolved: communications, data management, security, maintenance, backup and recovery. In the IRM environment, the system architecture defines all technology components throughout the organization. This is particularly valuable in a distributed computing or client/server environment because it helps to:

  • identify duplication and redundancy in existing technologies;

  • pinpoint dependence on specific vendors or technologies;

  • identify pockets of under-utilized or improperly applied technology; and

  • highlight inconsistencies and incompatibilities amongst technologies.

Maintaining the Target Architecture

71.  Target architectures describe what the information resources in the organization will look like in the future (usually within a period of two to five years), not what they look like presently. As information needs and the information landscape change, target architectures must be revisited and updated just as sales forecasts are modified to reflect changing business conditions. An organization therefore needs a policy for maintaining its target architectures. Responsibility for this lies with the Information Systems Planning function.

72.  The target architectures specify what the technological infrastructure will look like, but not how it is to be constructed. The final stage of the planning process, therefore, is creating the strategic implementation plan, which specifies how these architectures are to be constructed. It maps the organization's transition from its current portfolio through the implementation of particular systems development projects.


73.  The first stage in developing the IRM implementation plan is to define each project and assign priorities. Essentially, organizing priorities is based on these key factors: management need, benefit/cost, and risk. The development of project priorities and the definition of project interdependencies should result in the production of a project schedule that describes the sequence in which projects will be completed.

Project Selection Mechanism

74.  The project selection mechanism should have three characteristics:

  • It should rank projects according to how well they match the strategic business plan of the organization.

  • It should be a formal mechanism, to ensure that planning is systematic and rigorous.

  • It should take unquantifiable costs and benefits into account.

75.  Traditional cost-benefit analyses using economic calculations such as return on investment, internal rate of return and net present value exhibit the first two characteristics, but not the third. Such analyses compare the expected investment required for a project with the benefits expected to result if it is implemented. Since they consider only financial benefits, any other kinds of benefits expected to result from the project must be either converted to financial terms (often arbitrarily) or considered independently from the formal analysis.

76.  Neither of these solutions is satisfactory when it comes to information systems, since unquantifiable benefits are often significant. A better solution is to use a new formal project selection process that explicitly takes unquantifiable costs and benefits into account, such as the one outlined below.14 This description highlights the general principles involved; specific features (such as specific scoring criteria) may be modified for different organizations.

Scoring Criteria

77.  The formal project selection process described here uses nine criteria to prioritize projects for selection. It extends the concept of a "benefit" to include a wide range of factors that affect a system's business value. Likewise, it extends the concept of "cost" to include an evaluation of risk.

78.  The criteria are divided into two groups: business criteria and technological criteria. All are used to rate every project.

79.  Business Criteria - The business criteria are:

  • Economic impact - the traditional economic criteria used to rank projects, such as internal rate of return and net present value, as described above.

  • Strategic alignment - the extent to which the project will achieve the strategic goals of the organization.

  • Competitive advantage - the extent to which the project will give the organization an advantage over its competition.

  • Improved management information - the extent to which the project will improve management information for the core activities of the business.

  • Competitive risk - the extent to which postponement of the project will result in a net loss in the organization's competitive position.

  • Organizational risk - the extent to which the organization will be disrupted by the project or will need to adapt if it is implemented.

80.  Technological Criteria - The technological criteria are:

  • Strategic architecture - the extent to which the project is an integral part of the target architecture and is necessary for the implementation of subsequent projects.

  • Definitional uncertainty - the extent to which the requirements and specifications of the project are defined, have been approved, and are unlikely to change.

  • Infrastructure risk - the extent to which the existing information systems environment must be modified to accommodate the project in terms of existing hardware, software, staff, skills and delivery of services. It may, for example, be necessary to implement a formal education and training program to ensure that the organization always has the technical expertise needed to plan and introduce carefully constructed technology infrastructures, particularly when complex technologies are involved.

The Scoring Process

81.  Selecting projects is a joint process undertaken by users and information systems staff. Proposal ranking emphasizes high business impact (relationship of system to business objectives), tangible benefits (expected financial return to the level of investment required), intangible benefits (benefits derived as a result of implementing the system), low implementation risk (likelihood the system will fail to achieve the intended objectives), and quality of existing systems (ability of existing system to perform function efficiently and effectively).

82.  A variety of people should participate in the scoring process, depending on their responsibilities and expertise. Project sponsors from the user community are responsible for the business implications, i.e., business value and business risk, of the projects they sponsor and understand these implications the most, so they score the business criteria. Information systems specialists are most responsible for and knowledgeable about the technological implications, i.e., technical value and technical risk, of the projects, so they score the technological criteria.

83.  The Information Systems Steering Committee is also a participant in the scoring process since it is responsible for the strategic direction of IRM. Periodically, the Committee assigns a weighted value to each of the project selection criteria. The value of the assigned weight depends on the overall contribution or element of risk each individual criterion is expected to introduce to the organization. For example, in Exhibit 7, avoidance of net loss in competitive position (competitive risk) and achieving the strategic goals of the organization (strategic alignment) are both considered to be major contributors to the organization's success and are therefore given a high weighted value. Conversely, disruption to the organization (organizational risk) and the fact that the requirements and specifications of the project have not yet been completed (definitional uncertainty) are considered to pose a threat. Because of the risk factor they are given a negative weighted value. These assigned weights are the same for all projects in any one time period, if they are updated the revisions are applied consistently to all outstanding projects.

84.  Exhibit 7 shows an example of a scored project.

Exhibit 7

Example of a Scored Project 




Total Score

Business Criteria








Economic impact




Strategic alignment




Competitive advantage




Management information




Competitive risk




Organizational risk








Technological Criteria








Strategic architecture




Definitional uncertainty




Infrastructure risk








Total Project Score









1.    Weights are set by the Information Systems Steering Committee and are the same for all the projects to be ranked in a given time period. 

2.    Scores on the business criteria are determined by project sponsors for each project individually.  A score can have a value form 0 to 5.

3.    Scores on the technological criteria are determined by information systems specialists for each project individually.  A score can have a value of 0 to 5.

4.    The total score for each criteria is the weight of the criteria multiplied by the score assigned to that criteria.

5.    The total project score is the sum of the total scores for each criteria.

85.  Unfortunately, the appropriate assignment of weights is complex and the scoring procedure for the nine selection criteria is subjective. Although the process is structured and will be completed by professionals, it is still subject to manipulation and affected by personal preferences and biases, albeit unintentional.

86.  Many efforts have been made to eliminate the level of subjective influence, including the use of "economic" appraisal of projects as opposed to "financial" appraisal, which precludes direct attribution of large benefits and costs that cannot be quantified. Assigning weights and scores requires managerial judgment and subjective assessment; but when conducted according to a structured and consistent formula it is possible to strive for maximum objectivity.

87.  Regardless of the mechanism used, the following topics need to be discussed within the context of assessing each project's level of benefit and risk:

  • Are we addressing the appropriate business needs? - Alignment with business objectives and market opportunities; balance between short- and long-term perspectives; investment across multiple business opportunities; sensitivity to organizational development issues; reaching beyond traditional views and business habits.

  • Are we containing the overall risk of our projects? - Assessing risks of both action and inaction; looking at risks of projects both individually and collectively; technology, project and organization risks; focusing on ways to reduce risk; analyzing contingencies; managing adverse consequences.

  • Are the projects providing the optimum economic return? - Capital appropriation; NPV, IRR, payback, SVA, ROI; using appropriate discounting factors; determining what is measurable; management confidence in analysis; consistency in cost and benefit estimation; considering all costs not only systems costs.

  • Are we deploying our scarce resources in the most effective manner? - Up-front opportunities for systems integration; re-assessing existing resource commitments; focusing on allocation of critical resources where most appropriate; costing scarce resources at a true opportunity cost.

Selection Process

88. In its most objective state, the selection process requires each sponsor of a project to submit a project description to the Committee, with the project scored against each of the business criteria. Each project submitted is then scored on the basis of the technological criteria and projects are ranked according to the total project scores. Based on these rankings, projects are selected for implementation.

89. In the real world, however, there are other factors that contribute to and influence the decision-making process. For example, if there are budget constraints, the cost of a project can have a significant effect on its ranking or if a competitor is known to have taken steps that could have a negative impact on an organization's well-being this can cause a shift in direction. The objective is to select the best mix of projects, taking all relevant factors into consideration, recognizing that on occasion it will be necessary to invoke "emergency" measures in order to ensure the best "fit" with the organization's strategy and culture.

90. Project selection will take place on a regular basis, such as annually or quarterly. The timing of the process should correspond to the time periods used by the organization in making other budgeting decisions. More frequent selections have the advantage of being more responsive to changing business needs.

91. In addition to the ranked projects, the budget must accommodate changes for hardware, software, telecommunications and human resources, based on the project schedule and resource requirements identified in the project descriptions used as the basis for prioritization. If the personnel requirements exceed current staffing, then the recruitment and training of additional staff or the use of consultants should be anticipated. The budget must recognize the need to continue maintenance and minor enhancement of ongoing existing systems. It must also make accommodation for unforeseen "emergency" projects.


92. Approval for the IRM plan must be obtained from the Information Systems Steering Committee (as representatives of the senior and middle management group). A walk through meeting should be held and each of the plan's major components reviewed. Following approval, the plan is "frozen" and final project schedules and budgets are prepared.

93.  It is inevitable that new needs will continue to emerge and that priorities will need to be re-assigned. The plan must be flexible enough to accommodate these unforeseen circumstances. The Information Systems Steering Committee is responsible for adjusting project priorities, and possibly resources.

94. Projects are implemented according to the organization's systems development practices. The Information Systems Steering Committee and, in particular, the information systems planning representative, serves as a liaison with the different development groups to ensure that systems development conforms to the target architectures.

95. It is extremely important to consider the organizational impact of change when preparing the implementation plan. Did the baselining process indicate that the organization was "ready for change?" Are the sponsoring managers willing and able to champion the change process? Managing the human and organizational factors is extremely important to the overall success of the IRM initiative. To ensure a smooth roll out of the program, with minimal disruption resulting from lack of employee commitment and "buy-in," a formal, structured change management program must form part of the implementation strategy.


Strategic Review

96. Since the economy, markets and information technology landscape are prone to radical shifts, the IRM plan should be reviewed at a strategic level at least once every two years, or more often if the corporate strategy is on a shorter review schedule. This review should assess whether the IRM strategy continues to support the business direction of the organization. If the organization has entered new businesses or new markets, then the IRM plan needs to be reviewed immediately; it should not wait until the scheduled biennial review.

97.  Also at a strategic level, one of the key benefits of an IRM environment is that, as it matures, the organization will be able to capitalize on the increased level of knowledge, improved technology and collections of corporate data, enhanced interoperability of the systems, etc., in previously unthought of ways. It is important to organize a method of capturing this learning so that it can be used on a continuing basis to improve the overall IRM environment.

98. The framework for capturing this intellectual asset could be as simple as scheduled "information exchange" meetings with an attending scribe to document the lessons learned, or it could be something much more sophisticated, for example, installed on groupware such as Lotus Notes. In this latter case the "discussion" can be ongoing; it is time and geography independent and the information is captured electronically for future use.

Tactical Review

99. At a more tactical level, the impact of the IRM strategy on the organization should be assessed at regular (3-6 month) intervals. The following are indications of a successful and effective IRM implementation:

  • The Information Systems Steering Committee continues to be active and involved.

  • Management throughout the organization is enthusiastic about the new applications developed.

  • The new applications are supporting strategic and operational business plans.

  • Customers are being well served by the organization's information resources.

  • Information systems can now be modified easily to accommodate changing decision-making and reporting requirements.

  • The organization's hardware, databases, systems software and applications systems are compatible with each other and can be integrated as needed.

  • Functional areas across the organization can access shared data and processing capabilities.

  • The internal auditors have made positive assessments of the controls, safeguards and standards that relate to information resources.

100.  Ultimately, the success of the IRM function is judged on the basis of its ability to move the organization effectively in the desired direction at an acceptable cost.


101.   Policies represent the basic ground rules of IRM. High-level, formal, written policies, standards and procedures must be established and disseminated throughout the company, adopted formally and enforced like any other business policy.15

102.   The IRM operating principles/policies might include the following points:

  • There must be full and active participation by user departments to ensure that systems meet the organization's mission-related information needs.

  • Useful, timely, accurate, consistent and accessible data and information will be provided.

  • Compatible and integrated information and data systems will be provided through the use of Data Base Management System (DBMS) technology.

  • A capacity management program will be developed and implemented to manage equipment capacity and plan for upgrades.

  • An ongoing assessment of ways new technology can be used to realize cost savings or other benefits.

  • A combination of traditional and new concepts will be used to manage information resources, e.g., an integrated planning, budgeting and project tracking process; ongoing systems security reviews and follow-up audits; application systems inventory, etc.

103.   The adoption of common industry standards is vitally important to the success of IRM because it is this that facilitates the ready exchange of information and supports the interoperability of systems. In order to effectively control and facilitate interoperability and data sharing among platforms, both generic and platform-specific standards need to be identified to support distributed processing/databases in a networked environment. Some of the standards that will be needed are identified in the following list:

  • Security will become an increasingly important issue as an organization implements enterprise-wide networks to support distributed access to physically distributed data. Policies must be developed to address confidentiality, integrity and availability of data, hardware and software.

  • A standard, structured systems development methodology is important; it would provide:

    • a standard approach to all aspects of development for systems staff

    • a consistent process for users to participate in systems development/ enhancements

    • overall improved productivity

    • a more stable end product

    • a reduction in specification errors

    • improvements in the ability to integrate systems

  • To support the ability for porting applications and data on a variety of vendor platforms, generic and platform-specific standards for each hardware platform will be required. A minimum level of standards will be required for the purpose of rating packaged software.

  • Documentation is a critical requirement for the operation and maintenance of applications. Standards for both generic and specific documentation for all software/hardware platforms will need to be established.


104.   The 1990s have produced a dramatic change in the information systems organizational structure and in associated accountabilities. Because the convergence of business strategy and information systems strategy is still evolving, many roles are in transition. Individuals with a thorough grounding in the business of the organization are increasingly required to understand how best to deploy technology. Similarly, individuals with extensive technical knowledge are increasingly being asked to interpret and apply business strategies. However, it is important that the roles and responsibilities associated with IRM be understood and that there be a common agreement on the allocation of accountabilities. The architects, developers, user department managers, etc., must work as a team with other stakeholders to manage the opportunity from its inception through to the realization of the business benefits.

Chief Information Officer

105.  The evolution of tightly linked corporate and information systems strategies has been driven by the need to support the Chief Executive Officer (CEO) in his or her effort to maintain a watch on the company and its progress. The position of CIO has been established to provide this link between the senior management group and the information systems group. The CIO is the senior manager in charge of information systems, a peer of the CFO (Chief Financial Officer) and the COO (Chief Operating Officer). The difference between the CIO and the traditional MIS director is the scope of the CIO's influence.16

106.   The CIO is a business person first and a technical expert second. He or she is a full member of the management team and is a peer of other chief executives who report directly to the Board of Directors or to the CEO. The CIO's mandate is to develop and promote IRM, linking information systems to the strategic plan of the business.

107.   The CIO position is relatively new and has met with some resistance; however, as the opportunities for exploiting technology increase and the linkage between business strategy and information systems becomes more important, it is expected that a similar role will be needed in every major organization. In smaller organizations, the Information Systems Director will need to fulfill the strategic role as well as having the responsibility for day-to-day management of the Information Systems Department.

Information Systems Steering Committee

108.  Executive level leadership is important - executive level involvement in IRM is achieved through the Information Systems Steering Committee.17 The Committee's role is essential for first developing the strategic plans and, second, prioritizing the projects for the tactical plans. The Committee's main role is to keep the IRM strategy consistent with the organization's overall business strategy. The Committee is composed of the senior executive in each functional area.

109.  The Committee resolves business issues and is responsible for mediating the information resource requirements of various areas of the organization. The Committee is also responsible for the review, approval and adoption of IRM policy and standards and for the review, approval and commitment of funding for IRM.

110.   In small and medium-sized companies, the resources may not be available to support an Information Systems Steering Committee and in this instance the Committee's responsibilities could be undertaken by a sub-committee of the Management or Executive Committee. Regardless of the organization's size, it is absolutely essential that a representative group of senior managers be formed to direct the IRM program.

111.  A multidisciplinary, multifunctional team is essential. Problems that cross traditional functional lines cannot be resolved unless each function and discipline is involved in developing the solution.

User Department Management

112.   Involvement on the part of user department management (and staff) is important. They are key to identifying opportunities for the application of technology and ultimately for sponsoring IRM initiatives. The objective is to bring user departments into full partnership in managing information resources, providing strategic direction to the IRM architects. Information resources require significant capital investment, are built for the long term and have a relatively long life. They need to be managed in a fashion that allows the using communities to influence their construction and operation so that they add value to the community as a whole, which is much more effective than individual systems acquired by individual communities of interest, i.e., departments.

113.   Managers are responsible for effective operations and strategic planning in their areas. This is equally as pertinent to information resources as it is to any other resource.18 Managers should identify opportunities for streamlining and automating operations in their areas, sponsoring projects which they deem appropriate. They should participate in the formulation of systems requirements, manage each system's implementation, and ensure that the organization's portfolio of information systems and projects is consistent with its strategic plans.

114.   In terms of day-to-day operations, managers are responsible for participating in planning for computer use in their areas, for hiring and training people who will use computers, for encouraging the development of end-user capabilities and for the cost-effectiveness of computer use.

115.  Eventually, the user departments will "own" the results of the IRM planning process. This implies the evaluation and coordination of many changes, including redesigned business processes, changes in roles and responsibilities, new systems, etc. Their involvement, commitment and "buy in" are essential elements of success.

Management Accountants

116.   The management accountant's role in the strategic planning process depends on whether the management accountant is an executive who is a member of the Information Systems Steering Committee, a project sponsor from the management community or an information systems specialist. A management accountant in any of these three roles can provide valuable insights about information and decision making throughout the organization and thus, through IRM, help improve decision making and realize the organization's strategic business plan.

117.  In strategic planning for IRM, the management accountant should ensure that databases, information systems and related computerized decision support systems are designed to help:

  • quantify and interpret the effects of economic events related to the organization;

  • evaluate data for trends and relationships that help assess the implication of events;

  • assure the integrity and accuracy of information concerning an organization's activities and resources;

  • monitor and measure performance and induce corrective action where necessary;

  • implement a reporting system that provides people throughout the organization with timely information relevant to their responsibilities; and

  • prepare financial statements and reports.

Internal Auditors

118.    Internal auditors are responsible for the following:

  • assessing information system controls, starting at the analysis and design stages of a project and continuing throughout the life of each system;

  • determining whether information resources are adequately safeguarded; and

  • monitoring information system activity to ensure that it takes place according to specified standards and procedures.

Information Systems Specialists

119.    Information systems specialists are responsible for the following:

  • working with the management team to identify opportunities to gain strategic business advantage through the use of automated systems;

  • understanding the business impact of current and emerging technologies, and facilitating their introduction into the organization where appropriate;

  • planning for systems development, which includes developing standards, managing data, creating a blueprint for the information systems infrastructure (hardware, software, databases and communications) that the organization intends to put in place and developing a specific plan for achieving this infrastructure;

  • developing and maintaining the information systems infrastructure so that it supports current requirements and facilitates the support of new requirements;

  • developing individual information systems, which includes analyzing, designing, programming and testing new applications;

  • ensuring that various systems development projects are consistent with each other and avoiding unnecessary duplication in data and processing;

  • working with the end users when planning for systems development to ensure that the system is utilized effectively; and

  • understanding the business objectives and functional responsibilities of the organizations serviced by the application systems, e.g. finance, marketing, etc.


Modeling Techniques

Business Models

Business models serve as a bridge between identifying the strategic requirements (stage 1) and defining the technological infrastructure (stage 3). They describe how the organization will operate once the strategic plans for IRM have been implemented.

There are three basic objectives in constructing business models:

  • to add relevant detail to the critical processes and data already identified;

  • to specify how critical processes and data are related to each other, since up until this stage they have been examined individually; and

  • to describe existing operations, so that newly identified requirements can be integrated with current business functions and requirements.

In the example in paragraph 36, sales and promotion strategies and information about prospective customers were identified as strategic requirements. Before the technological implications of these requirements can be specified, they must be examined in further detail through the construction of business models. Business models describe how these processes are carried out currently and how they might be made more effective in the future. The model specifies who would develop the strategies, and what activities and decisions are involved in developing them. Similarly, the models would specify what information is currently gathered, what information should be gathered, and how this information would be used to expand knowledge about prospective customers. The rigorous process of constructing business models can also identify non-value-added activities that are currently performed.

Characteristics of Business Models

Business models have characteristics that make them especially effective descriptive tools:

  • They are independent of specific hardware and software technologies, so they do not need to be changed if the organization adopts new technologies.

  • They are independent of current organizational structure, and therefore highlight areas where the structure might be effectively modified.

  • They separate business processes from the automated systems used to process data, which facilitates the development of systems servicing various areas of the organization.

  • They are constructed in a hierarchical top-down manner, which limits the amount of detail that has to be gathered and absorbed at any one time.

  • They provide a common language for discussing business data and process, which facilitates communication among participants in the planning and development processes.

  • They provide the documentation in diagram form that can be understood by people without technical expertise. Thus, they enhance communication between managers and information systems specialists.

Business models are based on information collected throughout the organization. Sources of data may include:

  • planning documents;

  • interviews with management and staff;

  • examination of existing forms, files and records;

  • examination of operating procedure manuals; and

  • small group discussions with key employees.

There are a variety of specific techniques for producing business models, although they all share the characteristics outlined above. Many organizations and consulting companies have set up their own standards for business model construction and there are also automated computer packages, called Computer-Aided Software Engineering (CASE) tools, that analyze the integrity and consistency of the business models and produce the required documentation.

An organization constructs two types of business models: process models and data models.

Safeguarding the Business Model Data

Because the development of business models involves a large quantity of data collected by different individuals over a period of time, it is necessary to manage and safeguard the information collected. The primary tool for doing this is a data dictionary. Information systems specialists are responsible for maintaining the data dictionary and for developing policies as standards for its control.

A data dictionary is a central repository of information about each element in the business model (processes, data flows, external and internal sources of data, entities, relationships and attributes).

For example, the data flow Purchase Order could be defined as:19

Purchase Order = Purchase Order Number + Vendor Name + Vendor Address + POI Date + Ship to Address + {Item Number + Item + Description + Quantity + Price + Amount} + Total + Authorization

where {} indicates that these components are repeated multiple times. There would be data dictionary entries for each component of this definition. For example, Quantity might be defined as an integer greater than zero.

The data dictionary ensures that:

  • each element is named and defined uniquely and consistently;

  • elements are used consistently throughout the collection of business models constructed; and

  • it is possible to determine the effects of a change in one element on the rest of the system.

A data dictionary can be maintained either manually, using file cards or loose-leaf pages in a binder, or automatically, using a commercial data dictionary system. The CASE tools for business model construction come with their own data dictionary facilities.

Process Models

Process models describe activities performed by the organization. If we think of an organization as a system of interdependent parts, the objective in developing a process model (or data flow diagram) is to specify how the system operates.

A process model consists of four components:

  1. processes or activities (shown as circles)

  2. data flows, which represent the flow of information into, out of or between processes (shown as arrows)

  3. sources of information outside the system being examined (shown as rectangles)

  4. sources of information within the system being examined (shown between parallel lines)

The following diagram is an example of a process model. It is a simplified diagram of the relationships between four major activities of a distributing firm, which are labeled as follows: Manage Sales, Manage Financial Resources, Manage Products and Manage Suppliers.

Note that three important sources of information external to the organization are shown: industry sources, customers and suppliers. Three important internal sources of information are the Customer File, the Supplier File and the Product File.

Note also that each activity consists of subactivities. For example, the activity Manage Products in this diagram includes the subactivities Maintain Product Information, Receive Products and Ship Products. Each subactivity will have its own process model; a model of the subactivity Maintain Product Information, for example, might include the following subactivities: Create New Product, Update Inventory Levels and Cost Product.

Defining the subactivities in a process model is called decomposition. It limits the amount of detail that has to be gathered and absorbed at any one time, because detail about a subactivity is specified in a separate process model for that activity.

Example of a Data Flow Diagram (Process Model)

Data Models

Data models are used to describe the pieces of information that must be gathered by an organization and how these pieces interrelate. A data model (or entity-relationship diagram) consists of three components:

  • entities, which are the concepts of primary interest to the organization (shown as boxes)

  • relationships, which link the various entities (shown as box lines)

  • attributes, which are characteristics of entities (written inside the box of the entity they describe)

Example of an Entity-Relationship Diagram (Data Model)

A simplified example of a data model is shown in the data model diagram. It describes a portion of the information relevant to the distributor represented in the process model diagram. Note that for each entity, one attribute (or sometimes more) has been shown in bold type; this is its primary key, the characteristic that uniquely identifies it. For example, customers are uniquely identified by a Customer Account; for deliveries, the primary key includes a PO Number, Product Number and Delivery Date.

The relationships among entities describe the business rules of the organization, which are represented by arrows on the lines. Note that some arrows are double and others are single; for example, the relationship "places" between a customer and a customer order shows a single arrowhead on the top and a double one on the bottom. This is to show that each order is associated with only one customer, while a customer can be associated with more than one order.



An element of a data model. Attributes are used to specify characteristics of entities.

CASE tools

Computer-Aided Software Engineering tools. Software packages that aid in the design and development of computer systems. They allow documentation (such as data model diagrams, process model diagrams and data dictionaries) to be created and stored by computer.

Data dictionary

A central repository of information about elements in data and process models. It contains the definition of each element.

Data flow

An element of a process model. A data flow represents information entering into or exiting from a process.

Data model

A diagram that describes the organization's data and how different pieces of data are interrelated. A variety of techniques are available to produce data models. The specific kind of data model in this guideline is an Entity-Relationship Model.


Dividing a particular process in a process model into subprocesses so that further detail about the subprocesses can be defined.


An element of a data model. An entity is a category of object that is of interest to the organization and about which data will be maintained, such as a customer and an employee.

Information centre

An organizational unit that helps end-users develop computer applications.

Network architecture

Involves the definition of both local area networks and remote telecommunications lines and controllers to support distributed terminals and printers and to link remote central processing units.

Primary key

An attribute of an entity in a data model that serves to identify the entity uniquely, such as an employee number.


An element of a process model. A process represents an activity in the organization.

Process model

A diagram that describes the organization's activities and how different activities are interrelated. A variety of techniques are available to produce process models. The specific kind of process model shown in this guideline is a Data Flow Diagram.


An element of a data model. A relationship is an association between or among entities.

System software architecture

It is determined by a number of technical products that are used to facilitate the operation of, and user interaction with, application programs.

Target architecture

A blueprint of the organization's technologies, showing what they will look like once implementation has been completed. There is a target architecture for data, applications systems and hardware, and communications technology.

Technology architecture

It is the specifications for systems software, hardware and networks. It is developed after the data and application architectures.


Footnote :

[1]Dragoon, Alice. Knowledge Management – Rx for Success. CIO (July 1995), 48-56

[2] Buchanan, Leigh. The CIO Role – The Medium and the Message. CIO (July 1995), 68-76.

[3] The Society of Management Accountants of Canada.  Virtual Corporations – How Real? (Hamilton, ON: The Society of Management Accountants of Canada, 1993), 27

[4] Duffy, Jan and Ken Matheson.  The Need for Flexible Technologies.  CMA Magazine (October 1994), 9-12

[5] ibid

[6] Health Care Financing Administration’s Strategic IRM Plan (FY 1996-2000).  This is the primary Federal Agency responsible for administering the Medicare program in the United States.

[7] Custer, Jeffrey A.  The Role of IRM in a Client/Server Environment.  Data Base Newsletter (March/April 1995)

[8] van den Hoven, John.  Data Base Management, IRM: An Enterprise View of Data.  Information Systems Management (Summer 1995),  69-72

[9] Norton, David P. Whatever Happened to the Systems Approach.  Nolan, Norton & Co., Stage by Stage. (1989), 1-12

[10] McKay, David T., and Douglas W. Brockway. Building I/T Infrastructure for the 1990s. (Nolan, Norton & Co., Stage by Stage, 9,3).

[11] ibid

[12] Smith, Patrick.  Client/Server Computing.  (Sams Publishing, 1992), 165-166

[13] General Architectural Principles was published by the state of North Carolina in early 1994.

[14] The project selection process described here is based on concepts presented in Parker, M.M., and R.J. Benson.  Information Economics: Linking Business Performance to Information Technology.  (Englewood Cliff, NJ: Prentice Hall, 1988).

[15] Custer, Jeffrey A. Six Ingredients of a Successful IRM Environment.  Data Base Newsletter (March/April 1995).

[16] Kerr, James M.  Strategies for Managing Information Resources.  In The IRM Imperative.  (Toronto, ON: John Wiley & Sons, Inc., 1991), 1-7.

[17] This concept is discussed further in Porter, G.L.  The Rise of the CIO.  Financial Executive (August 1985), 41-44.

[18] This point is discussed further in Rockart, J.F.  The Line Takes the Leadership – IS Management in a Wired Society.  Sloan Management Review (Summer 1988), 57-64.

[19] This example has been taken from Armitage.  H.M. Linking Management Accounting Systems With Computer Technology.  (Hamilton, ON: The Society of Management Accountants of Canada, 1985).


AMAS | IMAP 1 | IMAP 2 | IMAP 3 | IMAP 4 | IMAP 5 | IMAP 6 | IMAP 7 | IMAP Preface

Last edited : Wednesday, 06 May 2009 02:59 AM
© 2005 Malaysian Institute of Accountants. All rights reserved.