"You must first plant the seeds in order to harvest the crop. Unfortunately,
most companies tend to eat the seed and then there is no crop to harvest."
- Bryce's Law
INTRODUCTION
When we introduced the original version of the "PRIDE" methodology in
1971 (which is now referred to as "PRIDE"-ISEM), we were primarily concerned
with developing enterprise-wide systems. Over time, it became clear to us
that we needed to enhance our approach for developing the corporate data
base, hence "PRIDE"-DBEM (Data Base Engineering Methodology) was born. Shortly
thereafter, we introduced "PRIDE"-EEM (Enterprise Engineering Methodology) as
a means to model the business and formulate an enterprise information strategy. When
this was done, the last piece of the puzzle of our philosophy for Information
Resource Management (IRM) fell into place. This was completed by the early 1980's.
At the time, most companies were concerned with only controlling the
data resources pertaining to their Data Base Management Systems. This was
a nice first step, but as it became necessary to share and re-use other
resources such as software, it started to become obvious a more global
perspective on managing information resources was needed, which is where
IRM comes in.
DEFINITION
Information Resource Management is the design, development, implementation,
and control over all of the resources needed to produce information. Its
intent is to share and re-use resources where appropriate. Sharing
represents the interchangeability of resources, thereby promoting the
standardization and integration of parts in products. By doing so,
development time and costs are reduced by simply re-using parts.
To those of you in manufacturing, this will all sound very familiar
as this is the same objective of Materials Resource Planning (MRP) and,
as such, IRM can trace its roots to MRP. The intent of both IRM and MRP
are the same, the only difference is the types of resources being
managed. Whereas MRP is concerned with tangible parts and products,
IRM is concerned with resources that are more intangible. Nonetheless,
both IRM and MRP are concerned with the collection, storage, and delivery
of resources in the most cost effective means possible.
TYPES OF INFORMATION RESOURCES
To understand the resources needed to produce information, we must
first understand the fundamental nature of information itself. We
define it as "the intelligence or insight required to support the
actions and decisions of the business." Further, we provide a
simple formula for it:
Information = Data + Processing
This means there are two equal variables for producing
information: data (representing the facts and events of the business)
and, processing (representing how and when data is to be collected,
stored, and retrieved). If the data is correct, but the processing
is wrong, the information will be wrong. Conversely, if the
data is wrong, but the processing is correct, the information
will also be wrong. From this, we can deduce three classes
of information resources:
DATA RESOURCES - representing the facts and events of the business,
along with how they are stored.
SYSTEM RESOURCES - representing how data is to be processed.
BUSINESS RESOURCES - representing both the consumer of the information
as well as the human and machine resources participating in the
production of information.
DATA RESOURCES
Data Elements - individual facts and events regarding an enterprise
(the basic building block of all data resources). Used to identify,
describe and quantify the objects of the business; includes both
primary and generated values (e.g., Net-Pay, Percent Completed,
etc.).
Records - a collection of one or more data elements. Represents
logical and physical storage areas within a file,
input transactions, print maps and screen panels (incl.
messages), and call arguments between programming modules.
Files - a collection of one or more records. Represents
logical and physical storage, both computer and manual.
Data Base - all of the files either within a single application
or a given enterprise, both logically and physically.
Inputs - a collection of one of more records used to collect
data. Can be implemented by screens, paper, verbal, optical, etc.
Outputs - a collection of one or more records to transmit
information
SYSTEM RESOURCES
Systems - a collection of one or more sub-systems. Systems
can be implemented manually, in part or in full, or with
mechanical support (computers).
Sub-Systems - a collection of one or more procedures within
a system. A sub-system is a business process representing a
flow of work within a specific time-frame.
Procedures - a collection of one or more operational steps
(Administrative) or one or more programs (Computer).
Operational Step - an individual task.
Programs - a set of computer-executable instructions performing
a step within a computer procedure. A program may be subdivided
into modules if so desired.
Modules - compilable program source code consisting of one or
more subroutines written in the same programming language. It
is not executable by itself. Modules can call other modules.
BUSINESS RESOURCES
Enterprises - a defined business entity with a specific mission, whether
profitable or non-profitable in intent. Enterprises take many forms,
such as the conventional commercial venture, whether private or public,
a government agency, etc. Enterprises consist of business functions
and are implemented by Positions.
Functions - a scope of responsibilities for carrying out a specific
portion of the mission of the enterprise, e.g., Marketing, Sales,
Manufacturing, etc. Functions are implemented by Positions.
Positions - a prescribed set of duties and responsibilities; another
name is "job." Positions implement business functions either in part or
in full. Positions are implemented by Human/Machine Resources.
Human/Machine Resources - employees, part-time workers, consultants,
computers, equipment, etc. Such resources possess...
Skills - specific knowledge or talent as developed by education
and/or experience. Proficiency denotes level of skill.
Information Requirements - specific needs for information in order
to perform actions and decisions related to the business of the enterprise
Objectives - a goal for the enterprise to achieve whether strategic,
tactical, or mandatory in nature. An objective can be used to call
for new development, modify or improve an existing condition (mod/imp),
or to maintain or correct something. One or more objectives can be
grouped into a project. An objective may relate to one or more
information requirements.
Projects - a scope of work consisting of one or more phases. A
project is an application of the material and human resources to
a specific objective through the execution of a prescribed sequence
of events. A project implements one or more objectives.
Many of the relationships between the resources
are hierarchical in nature, such as Systems Resources that
subscribe to a "Standard System Structure" as specified
by "PRIDE." Some also have recursive relationships,
such as files-within-files or modules-calling-modules. Yet,
others are represented by a network of relationships (too extensive
to go into here). All of these relationships ultimately represents
a model of the business and provides the ability to perform
an "Impact Analysis" whereby we can study the effect the
change of one resource may have on another. For example,
should we decide to change the length of a data element,
we should be able to determine, with great accuracy, all
of the other resources affected by the change, thereby
providing a "roadmap" for a maintenance project.
The mapping and maintenance of these extensive relationships
between information resources is the forte of an "IRM
Repository" which acts as a "Bill of Materials" processor
(see "Managing Design Complexity" - "PRIDE" Special Subject
Bulletin #10) at:
In order to promote sharing and re-usability, resources should be
uniquely identified by number and name, along with its prescribed
characteristics. Such resource definition ultimately represents the
rules of the business and allows us to differentiate resources. Using
an automated IRM Repository, tests can be performed to check for
redundancy in characteristics and, as such, the use of redundant
resources can be avoided.
Also see "Establishing an IRM Repository" at:
DIFFERENT METHODOLOGIES
The three classes of resources also hints at three different
methodologies for developing them:
Enterprise Engineering Methodology (EEM) - primarily concerned with
developing business resources and is performed by Enterprise Engineers
(Business Analysts)
Information Systems Engineering Methodology (ISEM) - primarily
concerned with system resources (Software Engineering is considered
a subset of ISEM), Such resources are developed by Systems
Engineers and Software Engineers (analysts and programmers).
Data Base Engineering Methodology (DBEM) - primarily
concerned with data resources and is performed by Data Engineers
and Data Base Administrators.
Although the methodologies will define "who" is primarily
responsible for their development, it is quite common for information
resources to cross methodology boundaries. For example, during EEM
systems and "objects" (logical files) are identified which are later
implemented by ISEM and DBEM respectively. During ISEM, application
logical files are identified and detailed later in DBEM. In DBEM,
physical files for a specific application are designed and delivered
to ISEM in Software Engineering. This means resources are initially
identified and then refined in ensuing phases of the various
methodologies. In this regards, an IRM Repository is used as a
"scratchpad" by developers to record the specifications of information
resources.
Project Management and Quality Assurance will also find information
resource definition helpful in their assignments. The phases of
the methodologies dictate which resources must be used and their
degree of definition. For example, in ISEM, the need for
specific data elements must be identified in Phase 1 (to support
an information requirement), either new or established data elements
to be re-used. At this time, for new data elements, only its
logical definition must be supplied. The physical attributes of the
data elements (e.g., length, picture, precision, scale, etc.) do not
have to be defined until Phase 3 (prior to Software Engineering). By
taking this approach to development, Project Management and Quality
Assurance can substantiate completion of the resource definition and
the phase of work (it either has been done or it has not). Such
analysis of the completion of work is commonly referred to as performing
a "status check."
IMPLEMENTATION
As we mentioned in our earlier article, "Managing Design Complexity,"
sharing and re-using resources doesn't happen by accident. It takes a
premeditated effort to do so. This means we have to uniquely identify,
describe, and cross-reference each resource.
Is such definition work endless? Hardly. There is a finite number of
information resources in an organization. For example, there is probably
no more than 500 - 1,000 unique data elements in an enterprise. Once they
are documented, they can be shared and re-used over and over again. This
is the real payoff of IRM, thus expediting development and simplifying
change control.
Year ago there was a problem in India where people were starving
to death. To help out, the United States sent seed grain to India
for the local populace to plant and harvest. This was a viable
long-term strategy to take. Unfortunately, when the sacks of seed
were delivered to the docks, the people opened them and ate the
seed as opposed to planting it. This remedied their immediate
hunger problem, but ruined their long term needs. You cannot
harvest a crop if you do not sew the seeds. The same is true
in IRM and MRP. To harvest the crop, we must first document our
resources. Only then can we realize the benefits of sharing and
re-using them.
For more information on our philosophies of Information Resource
Management (IRM), please see the "Introduction" section of "PRIDE"
at:
