set of tightly interlocked estimates which lead, through
successive steps, to plans for the acquisition and utilization of manpower and hardware and to projections for the
operational planning period of costs by kind of expense,
service and group served. While most of the steps in this
process are relatively mechanical, the details of the process are such as to impose a disciplined coordination on the
planning of all MIS activities, insuring that the acquisition
and deployment of hardware and software resources are
closely related to the strategic plans to the company's
businesses. Exhibit 3 shows the flow of data through this
process.
From a procedural point of view, one key problem remains: the allocation of MIS resources among the competing business groups when there are not enough manpower
or hardware resources to serve the high-priority needs of
all. In this company, this contention among business
groups is resolved through review mechanisms which force
such allocation decisions to the business group executive
level and, where necessary, to the chief operating officer.
In this way, "the best interests of the enterprise" are
defined by the managers who have corporate responsibility
for the results of that decision.
When we examine the implications for productivity of this
process and others like it, we find a set of interlocking
impacts ranging from the clearly definable and positive to
those which suggest that we still know too little about the
interactions of management and information to be sure
what the impact is.
The first and most obvious impact is the focus on "doing
the right things" and the insistence that the business unit
managers responsible for the financial results of the enterprise have both the right and the responsibility to say what
those "right things" are. But doing the right things implies
that we know and understand the link between information
and successful management action in a business environment and that we have reasonably accurate measures of
cost and benefits or, to put it another way, that we can
estimate both the productivity (efficiency) of our MIS
resources and the productivity (effectiveness) of the users
of these resources.
Without good measures of MIS development and production productivity, the cost side of the cost/benefits
calculation becomes distorted. Without accurate measures of the opportunity for user improvement through the
use of MIS and of the probable impact of a chosen
technical alternative on that opportunity, the benefits side
of the calculation may be distorted. In either case, the
process designed to insure that we do the right things
cannot, by itself, do that at all. Accurate measures of the
productivity of both suppliers and users are needed--more
accurate measures, we believe, than now exist.
A second and less tangible impact of the planning
process lies in its effect on the productivity of the MIS staff.
Although difficult, if not impossible, to quantify, there is a
discernible impact on the staff directly related to its indentification with the objectives and goals of the people it
serves and the sense that its own activities are governed by
a coherent plan of action.
The third and equally intangible result of the planning
process appears to be the impact of users of MIS activities.
Typically, there is a reduction of friction between MIS and
user personnel, a greater sense of user control over any
MIS-dependent operations and, thereby, a subtle improvement in user productivity.
Finally (and we suspect that this may be the most fruitful
consequence of the implementation of planning processes
like this one), the planning process establishes an atmosphere in which longer-term technical strategies can be
addressed by the company on their strategic and operational merits, uncomplicated by the politics of line/staff or
division/corporate conflicts. Specifically, decisions such
as the centralization or decentralization of development
resources and the selection and distribution of hardware
capacity become more rational. In short, it becomes more
possible to plan for the best possible use of technology, in
the interests of the enterprise, which, in the long run, is
what leads to real increases in productivity.
THE INFORMATION SYSTEMS MANAGEMENT
SYSTEM: A FRAMEWORK FOR PLANNING
By John A. Z a c h m a n
Considering the fundamental economic changes that are
taking place in our nation, in which we find ourselves in
transition from resource "fat" to resource " l e a n " conditions, it is not surprising that there should be a rekindled
interest in planning and control techniques that will enable
us to preclude suboptimization, or dissipation of our resources.
Additionally, when we begin to see that an organization's
ability to plan for and control resources has a dependency
upon the consistency of the data, we shouldn't wonder
why there is a surging interest in planning and controlling
the data resource itself. This greater demand for information system (I/S) planning is forcing those of us who are
involved with the subject to become more definitive in our
approaches, converting some of the art into science,
improving our probability for success.
There are a number of factors that contribute to the
success of a strategic I/S planning effort, but fundamental
is our ability to perceive the I/S Management System
The author is a marketing representative for IBM Corporation in Los Angeles.
DATA BASE Winter 1978
8
which the Strategic I/S Plan is to support. Without an
understanding of this management system, an I/S planning effort seems to be a one-time, stand-alone analysis
that has no continuing impact on the organization and its
ability to manage its resources more effectively.
Therefore, information systems planning must begin
with an understanding of the basic components of the I/S
Management System and their relationships which then
serves as a framework within which the planning effort can
take place. Those basic components appear to be several
and are described below.
Actually, the business itself is not a component of the I/S
Management System, but is the environment in which the
I/S Management System resides. This environment belongs in the I/S Management System picture because it is
the reason for which the I/S Management System exists.
Because it is the environment and not actually a component of the system, it is represented in the figures by a
broken line. (Figure 1).
The business is comprised of a number of entities, some
of which are people (organization) doing things (processes) to some end; that is, they are taking in some
resources and converting them to some products or services. There are a number of other entities that make up a
business, but these four (organization, processes, resources and products) are particularly interesting, at least
for initial analysis.
There are relationships between these entities. That is,
there are relationships between the organization and the
processes. There are relationships between the organization units and other organization units, between processes
and other processes, between resources and organization
units, between resources and processes and so on.
From the foregoing, there are two implications:
1. There is a set of entities and their relationships which
- describe or "characterize" the business, and they are
definable. That is, if you can identify the entities which
are of interest to you, you can identify the relationships between them. It merely requires some analysis.
Therefore, we are not dealing with an amorphous
mass, but a definable structure, which can be identified and which describes the business.
2. Secondly, everywhere there is a relationship between
two entities, there is an implied (if not explicit) flow of
information. This is an important observation to make
if your objective is to develop an Information Systems
plan to support the information flows of the business.
r
I
I SYSTEMS I
DATA
INFORMATION
SYSTEMS
ARCHITECTURE
F i g u r e 2:
Information systems architecture is a term that is rapidly
losing its meaning because it is being used to describe
many different things by many different people. However, in
the sense it is being used here, it represents the sum total
of all information-related flows, structures, function and so
on, both manual and automated, which are in place a n d / o r
required to support the relationships between the entities
that make up "The Business." The I/S Architecture is
depicted in Figure 2.
A portion of the I/S architecture is likely to be automated
and that is represented in Figu're 2 as the "box within the
box." These are two aspects to the architecture, the
systems or functional aspect and the data aspect.
The systems aspect of the architecture is that part of the
architecture which one sees when one wants to use it. For
example, it is the programs which are running on a machine that deliver reports or answers or function to someone. It is the means (automated or not) by which the data
resource is made available to management in control of the
other resources of the business. The number of systems
that may operate in the architecture are infinite in nature;
that is, the functions one might want to perform or the
combinations of data elements one might want to see are
limited only by one's imagination (and, very practically, by
one's willingness to pay for them).
The data aspect of the architecture is the informational
representation of the relationships between the entities of
the business. Looked at in the purest conceptual sense,
the data has a tendency to be finite in nature. What is
infinite is the use of the data, or the combinations of
various pieces of data for various purposes or the functions to be satisfied or the flows of the data and so on. All of
this is related to the systems or functional aspect of the
architecture. In any case, there appears to be some definable set of data elements whose structure represents the
relationship between the entities of the business and which
constitutes the basic building blocks for any viewpoint or
use of data that is required.
The third component of the I/S Management System
picture is projects. The projects are current investment of
operating resources in development activities designed to
address specific problems identified within the business.
These projects are usually directed toward cost reduction
through automation, improved profitability through better
control, restoration of information flow breakdowns, improved decision making and so on. The projects, as they
are translated from their development state to their operational state, become "system" pieces of the I/S Architecture (Figure 3).
The projects can either be automation projects or nonautomation projects. Also, there can be multiple projects
going on at any one time, depending upon the number of
1
THE BUSINESS
I
I
Z
o_
i
i
z
<
(..9
E£
o
PRODUCTS
~
SERVICES
OR
RESOURCES ~1
B
I
I
LU
o
o
~
13.
j
I
I
mm
v
I
I
--I
F i g u r e 1:
Information Systems Architecture
The Business
9
DATA BASE Winter 1978
,, y
Architecture are put in place, it tends to change the
perception of the relationships in the business. This, in
turn, forces a reevaluation of the entity relationships, which
results in a refinement of the I/S Architecture, which
changes the projects that are required and the priority of
those projects. As new projects are developed and become
systems pieces of the I/S Architecture, they change the
perception of the business which forces a reevaluation of
the r e l a t i o n s h i p s . . , and so on. In other words, we have a
continuous system of several components--all interdependent and reacting with each other.
I PROJECTS
SYSTEMSIL
DATA
INFORMATION
SYSTEMS
ARCHITECTURE
Figure 3:
Projects and the I n f o r m a t i o n
Architecture
Systems
A problem exists which is not apparent by looking at the
picture. This is that when management of the business
looks at data processing, it sees only part of the picture,
the p r o j e c t s . . , or their operational m a n i f e s t a t i o n . . , the
systems. (Figure 5)
Because the projects are line items on current budget,
theyare highly visible. Likewise, the systems or operational
manifestation of the projects also appear as a line item on
the budget, the data processing operation. Management
either sees the cost (budget) or the benefit or anticipated
benefits which accrue to the projects or systems.
Because of this extremely high visibility, data processing
management has a tendency to focus primarily on managing these two components of the I/S Management System.
We get very professional at managing development projects, usir~g phased approaches with contract-like review
points to insure delivering results to specification, on time,
within budget and so on.
Additionally, we focus on operating the systems effectively and.efficiently by maintaining high availability, high
reliability, delivering reports on schedule, maximizing hard-
problems to be solved and the amount of resources available to solve them. The next piece in the picture is the
Strategic t/S Plan. (Figure 4)
This Strategic Plan implies that someone must be selecting the entities in the business which are of interest from an
information flow standpoint and beginning to define the
relationships between them. That is, a structured description or characterization of the business must be prepared
to design the I/S Architecture. While characterizing the
business and describing the flows of information through
it, the information flow breakdowns through it, the information flow breakdowns (and other information related problems) become visible, which suggest the initiation of some
project or projects to address the business (information)
problems.
As these projects are translated from their developmental state to operational state, becoming systems, the I/S
Architecture begins to be constructed. As pieces of the I/S
]
THE BUSINESS
I
VISIBILITY
I
I
I
7
I PRODUCTS
Z
I
I
I
W
RESOURCES
~
N
--
~
W
~
Z
rO
<
O
I
SERVICES
I
I
O
+
®
1
,'
®
DATA
©
INFORMATION
SYSTEMS
ARCHITECTURE
DATA BASE Winter 1978
J]
I PROJECTS
I SYSTEMS
IL
Figure 4:
I
I
The Strategic Information Systems Plan
10
i_j_l
THE BUSINESS
VISIBILITY
PRODUCTS
N~
RESOURCES I .
-,
OR
~
SERVICES
I
-=
I
I
I
o
[
, 1
I
I
I
I
"
'
INFORMATION
SYSTEMS
ARCHITECTURE
Figure 5:
High Visibility of Projects and Systems
but on a stand-alone basis.
The problem of the systems standing alone begins to
manifest itself in management's frustration with data processing. These kinds of things begin to be heard:
"1 know the data is down there, but I can't get at itr'
"1 don't get the numbers until the 15th working day
and then there is a 600 percent variance in them! If t
wait six weeks, the variance is at tolerable levels, but
by that time I don't want the numbers any more!"
"It costs us a fortune to reconcile the differences
between the numbers!"
"We can't confirm that we are building what we are
designing!"
"1 am spending an arm and a leg on data processing,
and it is not solving my problemsF'
ware and software resources, controlling costs through
cost allocations and so on.
Because of the high visibility and coincident focus on
the projects and the systems, it is easy to relegate the other
components of the I/S Management System to an inferior
status or even to overlook the fact that they exist. The result
is that the Information Systems Management System is not
a continuous system. It is, in fact, discontinuous. That is, if
you have not recognized that there is a structure to the
business, then you have not defined the I/S Architecture
that is required to maintain and protect the flow of data
through that structure. If the I/S Architecture has not been
defined, then when the projects are translated into an
operational status, they do not build anything. They merely
exist on a stand-alone basis.
They do not relate to each other. They do not relate to the
flow of information within the business. They do not relate
to the relationships between the structural entities of the
business. They relate only to an isolated problem identified
within the business, and their value is only the value of
solving that specific problem. Typically, today's I/S Management System is missing some components and appears as illustrated in Figure 6. (The missing components
are indicated by the dotted lines.)
Some mechanism (illustrated by the funnel in Figure 6) is
in place to gather or accept requests which are ordered in
some usually arbitrary fashion and the DP resource plan is
prepared on this basis. This DP resource plan is illustrated
by line " B " in Figure 6, which represents the allocation of
the DP resources across the various projects as well as the
various systems which are the operational state of the
projects. The " A " lines in Figure 6 represent the project
plans which are established to control the development of
the projects as well as the operation of the systems after
installation. The systems are built and begin functioning,
Conclusion
An alternative to today's typical I/S Management System
is to perceive the I/S Management System as a continuous
system, having several interdependent components as
described above, namely: the I/S Architecture (both systems and data aspects), the projects, the Strategic I/S Plan
along with the pl~mning process all in support of the
information flows within the business. The sequence of
events in evolving this continuous I/S Management System appears to be as follows:
t. Recognize the need for an I/S Architecture which
reflects and protects the information flows within the
business unit to insure consistency of the data so its
value for controlling the business resources is preserved.
2. Begin to analyze the business unit to define its
structure and its information flows from which the
data architecture can be described and ultimately
designed. Additionally, provide for some means to
11
DATA BASE Winter 1978
I
THE BUSINESS
I
PRODUCTS
OR
SERVICES
I
RESOURCES h !
r I
N
I
I
o
I
I
I
I
_1
1
I_._
I
I...~
i'~-J
I
r----X.-*
PROJECTS
I
_J
I
I
SYSTEM 1
SYSTEM 3 I
SYSTEM
Figure 6:
3.
4.
5.
6.
Today's I / S M a n a g e m e n t System
maintain this "characterization" of the business in
view of the changing environment. At the same time,
identify information flow breakdown problems which
can be addressed by constructing functional pieces
of the I/S Architecture.
Begin to put in place facilities required to manage the
business' data in such a way that the development
projects are forced to conform to the data architecture based upon the information flow analysis of the
business. To preserve the value of the data for management control purposes, no project (automated or
nonautomated) should be allowed to create or maintain data inconsistent with the architecture. The facilities that are required are likely to i n c l u d e some
method of coding and classifying that data, mapping
it to the business processes, organization, systems,
objectives and so on. Additionally, the procedure for
identifying and enforcing policies relating to definition, priorities, ownership, security and so on are
required in the management of the data.
Figure out how to migrate from the current systems
and data files to the I/S Architecture supporting the
information flow.
Examine the existing Project Management apparatus
to insure that it is functioning satisfactorily in delivering projects to specification, on schedule, within
budget and so on. Additionally, examine and institute
program development techniques which lend themselves to programming within a "data-managed" environment.
Examine the existing data p r o c e s s i n g o p e r a t i o n s
DATA BASE Winter 1978
management apparatus to insure it is functioning
effectively in scheduling and operating the hardware
and software to maintain the required reliability, availability, service and so on. Additionally, identify the
hardware/software architecture required to support
the "data-managed" environment and begin to construct it.
7. Document the Strategic I/S Plan and begin to put in
place the planning processes that link all the components of the I/S Management System together and
insure their continuous, "integrated" operation.
The Planning Process
The existence of a Strategic I/S Plan implies the existence of a hierarchy of plans, which is to be expected in
view of the levels of planning and control: strategic planning, management control and operational control.* Realistically, the evolution of planning in information systems is
much the same as in the business unit itself, from the
bottom up.
First the requirement for operational planning becomes
apparent, and computer operations planning and scheduling is established, as well as some project planning activities. This planning process is indicated by line " A " on
Figure 7, which represents the projects being transformed
into systems as well as the systems being operated. (Also
see the " A " lines in Figure 6, which is how the Operational
Control activities actually function until later stages in the
;','Planning and Control Systems: A Framework for Analysis.
Robert N. Anthony, Harvard Press, 1965.
12
r THE BUSINESS
I
I
RESOURCES
N
PRODUCTS
OR
SERVICES
L_]
o
I
,y
I
I PROJECTS
I
I SYSTEMS
i.5_
DATA
INFORMATION
SYSTEMS
ARCHITECTURE
Figure 7:
T h e P l a n n i n g Process and the I n f o r m a t i o n Systems
Management System
evolution take place and the I/S Management System in its
entirety can be perceived.)
Next, the requirement for management control, or the
activities relating to the allocation of resources, become
apparent. At this stage in the evolution, hardware/software
plans, manpower plans and facilities plans begin to appear
along with some activity which accumulates demands for
services and priorities for the projects. The management
control activities are indicated by the " B " lines in Figure 7.
The first " B " line connects the strategic plan and the
projects, representing the allocation of resources to the
projects. The second " B " line connects the strategic plan
and the I/S Architecture, r~presenting the translation of
the I/S Plan to the I/S Architecture. (Also, see the " B " line
in Figure 6, which represents the management control
activities at that stage of evolution.)
Last, the requirement for strategic planning appears;
that is, the need to establish the I/S objectives, strategies
and resources based upon the structure and information
flows within the business as well as the business' direction
and strategies. It is at this point when the requirement for
the I/S Architecture becomes apparent and the requirement for managing the data to preserve its value for
management's control of the business. The strategic planning activities are indicated by the " C " lines in Figure 7.
The first " C " line connects the Business with the Strategic
I/S Plan, representing the identification of information
flows within the business and the determination of the I/S
Strategy to support them. The second " C " line connects
the I/S Architecture with the Business, representing the
comparison of the actual I/S Architecture with the information flows. The third " C " line connects the Data with the
Projects, representing the control of the Projects' conformance to the I/S Architecture through the management of
the b u s i n e s s ' data. (Note: There are no " C " lines in the
typical I/S Management System that exists today. Figure
6.)
Any of these planning processes can be very informal or
highly formalized. The degree of formality seems to decrease as you progress from lower to higher levels of
planning and control. The formality of any one level of
planning and control seems to increase as the size of the
business unit increases. Apparently, the bigger the business, the more widely delegated are the resource management responsibilities, the bigger the management control
problems and the higher the awareness and formalization
of the planning and control facilities.
Another interesting factor to notice is that different levels
and kinds of management are involved with planning at
different levels of planning and control. That is, the responsibility for Operational I/S Planning falls directly on firstline, data processing management. The responsibility for
I/S Management Control resides with high-level data processing management. The responsibility for Strategic I/S
Planning seems better placed at very high levels of business management.
The increasing demand that data processing support
management in the control of the resources of the business is satisfied through management of the data of the
business. This highlights the requirement for an I/S Architecture that is directly derived from the structure and
information flows within the business unit. Additionally,
some means must be established to manage the business'
data and control the development projects (manual and
automated) to conform to the I/S Architecture. To be
successful, any Strategic I/S Planning effort must recognize these (as well as the other) components of the I/S
Management System and put in place the management
mechanisms and planning processes (however formal or
informal) to insure their continuing effectiveness over time.
13
DATA BASE Winter 1978