Automating Planning Environments: Knowledge Integration and Model Scripting

Author(s): Scott C. McIntyre, Benn R. Konsynski and Jay F. Nunamaker Jr.

Source: Journal of Management Information Systems , Spring, 1986, Vol. 2, No. 4
(Spring, 1986), pp. 49-69
Published by: Taylor & Francis, Ltd.

Stable URL: http://www.jstor.com/stable/40397837

REFERENCES
Linked references are available on JSTOR for this article:
http://www.jstor.com/stable/40397837?seq=1&cid=pdf-
reference#references_tab_contents
You may need to log in to JSTOR to access the linked references.

JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide
range of content in a trusted digital archive. We use information technology and tools to increase productivity and
facilitate new forms of scholarship. For more information about JSTOR, please contact support@jstor.org.

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at
https://about.jstor.org/terms

Taylor & Francis, Ltd. is collaborating with JSTOR to digitize, preserve and extend access to
Journal of Management Information Systems

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 Automating Planning Environments:
Knowledge Integration and Model
Scripting

SCOTT C. McINTYRE, BENN R. KONSYNSKI, and

JAY F. NUNAMAKER, JR.

Scott McIntyre joined the faculty of the College of Business at the University of
Colorado, Colorado Springs, in January 1986. He will receive his Ph.D. in Manage-
ment Information Systems (mis) from the University of Arizona in May 1986. The
title of his dissertation is "PLEXPLAN: An Integrated Intelligent Environment for
Information Systems Planning." His research interests include the application of
artificial intelligence techniques to business decision making, software tools for mis
planning, and the relationship of mis and corporate planning.

Benn Konsynski is an Associate Professor of Management Information Systems at

the School of Business and Public Administration at the University of Arizona. He
received his Ph.D. in Computer Science from Purdue University. His major research
focus is computer-aided approaches to information systems design and implementa-
tion. Current research interests include model management, learning paradigms in
decision support systems, business dialogues in distributed office environments, and
design support for local area networks.

J. F. Nunamaker, Jr., is Head of the Department of Management Information

Systems and is a Professor of mis and Computer Science at the University of
Arizona. He received a Ph.D. from Case Institute of Technology in systems engi-
neering and operations research. There he was on the original Information System
Design and Optimization System (isdos) project team responsible for the first
prototype of the Problem Statement Language/Problem Statement Analyzer (psl/
ps a) system. He was an Assistant and Associate Professor of Computer Science and
Industrial Administration at Purdue University. Dr. Nunamaker was hired by the
University of Arizona in 1974 to develop, implement, and administer the mis depart-
ment. Under his direction the program has grown to a position of national and
international leadership in the mis profession and currently involves approximately
1,000 undergraduate students, 150 masters '-degree-in-Mis students, 60 MBA stu-
dents, and 40 Ph.D. students. Author of more than 35 papers on the automation of
software construction, performance evaluation of computer systems, and decision
support systems for systems analysis and design, he has lectured throughout Europe,
Russia, Asia, and South America. Dr. Nunamaker is a reviewer for the National
Science Foundation (NSF) and has received research funds from NSF over the past

An earlier version of this paper was presented at the Nineteenth Annual Hawaii Interna-
tional Conference on System Sciences, University of Hawaii, Honolulu, Hawaii, January
1986, and is published here with permission.
This research was partially funded by a grant from the NCR Corporation.

Journal of Management Information Systems/ /Spring 1986, Vol. II, No. 4

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
50 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

16 years. His research projects at Purdue University and the University of Arizona
have received grant support in excess of $8 million. Dr. Nunamaker has served on
the editorial board for a number of leading publishing houses and professional
journals and is Chairman of the Association for Computing Machinery (ACM)
Curriculum Committee on Information Systems.

abstract: Progress has been limited in understanding the nature of Information

Systems (is) planning and accomplishing its goals. Two problems which contribute
fundamentally are the dynamism of is and the difficulty of integrating multiple
perspectives on is planning. Automated environments which support the is planning
process must address these two issues, dynamism and integration. In this paper,
three perspectives on the is planning process are reviewed. Knowledge-based tech-
niques using Semantic Inheritance Nets are described as useful for view integration
and for providing a flexible, dynamic, automated model of the is planning environ-
ment which is accessible to is tools. The use of scripting in is planning models is
examined as a way to address the issue of is dynamism. Implementation of these
techniques is described in plexplan, a knowledge-based environment for is plan-
ning. Application of knowledge integration and model scripting in an instance of
plexplan use is described.

key words and phrases: Information systems planning, automated planning,

knowledge bases, semantic nets, model scripting.

1 . Perspectives on Information Systems Planning

The purpose of planning is to identify objectives, goals, and options [13] and
to generate descriptions of specific actions required to accomplish identified goals
[24] . Models of the planning process typically include three distinct phases: problem
formulation, exploration, and solution derivation [28].
Problem formulation is the process of responding to an initial "sense of need,"
first, by identifying relevant problem variables, and second, by determining which
problem variables are in the problem domain and which are outside, in the problem
environment. The exploration phase is concerned with constructing as detailed,
exact, and scientific a model of the problem as possible. By this the planner seeks to
determine the nature of relationships between variables in the problem domain and
relationships between domain and environment variables [16]. Once the model is
clear, different perspectives on the problem may be explored as they relate to the
objects and relationships of the problem environment. Assuming a correct percep-
tion of the problem and an understanding of the problem environment, solution
derivation is undertaken by the generation, evaluation, and selection of alternatives.
In generating alternatives, especially in problem domains like Information Systems
(is) which are complex and ill structured, techniques must insure that as many
perspectives on the problem as possible are considered [16, 25, 28].
There has been difficulty in integrating the many perspectives of is planning.
When one gains predominance, a prejudicial influence is often imposed upon the
planning process. The is planning process [18, 20] was characterized as an amalga-
mation of three perspectives: external, internal, and procedural. These are repre-
sented in Figure 1.

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 51

enterprisel (enterprise I (enterprise (enterprise I enterprise I enterprise I

mission I |objectlues| | enulronment [strategies |poHcies | plans |
I I I I I I
[set IS 1 Iset IS 1
[mission | ^objectiues

(EHTEBNHL UlEl

IS management (management tools

planning ond strategies)

IS resources) J,y P.^^.^CL | IS configuration

planning | I1* KLHNNINb P | planning
(people, schedule, (hardtuare, software,
$$, etc.) OR, telecom., Rl, etc.)

(INTERNRL UlEtll)

IS PLRNNING

--■»" (

planning 1

knoujledge

(pRocEDunm uiËïïT

Figure 1. Three Views of IS Planning

The external view of is planning

planning. This viewpoint addres
corporate strategy, organizational
culture, organizational learning, an
17, 18, 19, 21]. The internal view i
development process internal to th
and is Resources. Much attention h
is planning with the external view
and is involvement in the enterp
planning is a formalized phase of t
has inputs, transforms, and outpu

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
52 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

problem definition, problem boundaries and scope, external and internal objectives
to be met, and resources needed. This knowledge is a necessary antecedent to
defining specific requirements and to analyzing and designing specific systems to
meet the requirements.

2. The PLEXPLAN Framework

Numerous tools and techniques have been developed to address planning

stages and views discussed above. Recognition that no one tool can provide all
planning needs has led to descriptions of frameworks for multiple tool use [15, 24].
While use of multiple tools provides knowledge elicitation from multiple perspec-
tives, problems remain. Integration of planning knowledge into a conceptual model
of the is environment remains a manual task and depends upon the insight and
integrative powers of the planners. This is true even in a situation in which tools
interface with a strategic data base (SDB) since the schema depends upon the
foresight and insight of the SDB developers [5, 7]. Finally, manual models are
difficult to develop and very difficult to change.
An example illustrates. Is planners are seeking to determine the most effective is
configuration for a complex future enterprise. Using Business Systems Planning
(bsp) [4] in the exploration phase, they discover that a Sales Analysis is is planned to
support the Vice-Président (VP) of Marketing. Using Strategic Assumption Surfac-
ing and Testing (sast) [16] in the solution derivation phase, they identify that,
among his other roles in the enterprise, the VP is a "stakeholder" who is impacted
by one of the proposed solutions. This particular solution, planners discover, re-
quires purchase of hardware for new information systems. To assess the VP' s impact
on this solution, the planners are forced to integrate all available information into a
manual model of the current and proposed environment. Also, since bsp did not
consider hardware per se, planners have to go back and try to discover/integrate
hardware use into the model. Typically, the situation described is but a tiny part of
the highly complex planning environment. Valuable knowledge about the VP's
impact may well be lost in the volume of planning information.
An architecture is needed which incorporates existing planning tools, provides
facilities for integration of planning knowledge, and supports dynamic reconstruc-
tion of the is model underlying tool use. An automated environment which addresses
these needs has been constructed at the mis Department of the University of Arizona.
Called PLEXPLAN [20], it is based upon the architecture in Figure 2 and is construct-
ed within the framework of the plexsys system development system [8, 10, 1 1 , 27].
The architecture of the plexplan system is composed of seven major compo-
nents: the Decision Structure and Requirements Language, the Session Generator,
the plexplan Knowledge Base (kb), plexsys Knowledge Base Management Tools,
the Structural Analyzer, the Decision Analyzer, and various Planning Tools. A
system designer or planner constructs a Decision Structure and Requirements Model
(dsrm) using the Decision Structure and Requirements Language (dsrl). The dsrm

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 53

Tieslfloerj i

■ecision

Stricture n...|M
, .
Requireweats , .
Tools Cenerotor
Language

i i i
Knowledge Management Tools

Knowledge Base

Structural Decision
Analgzer Rnalyzer

Reports Beperts
v

F/g«r

is div
infor
availa
proce
and r
Each
and o
edge
know
ally,

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
54 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

Table 1 Structural Analyzer reports

LANGUAGE TERMS REPORT: Lists a definition of information in the Knowledge
Base (kb). All processes and tools are listed with their inputs and outputs.
PROCESS INPUTS REPORT: Lists the names of all processes and process inputs.
Prints an incidence matrix of processes to inputs.
PROCESS OUTPUTS REPORT: Lists the names of all processes and process outputs.
Prints an incidence matrix of processes to outputs.
TOOL INPUTS REPORT: Lists the names of all tools and tool inputs. Prints an inci-
dence matrix of tools to inputs.
TOOL OUTPUTS REPORT: Lists the names of all tools and tool outputs. Prints an in-
cidence matrix of tools to outputs.
PROCESS-OUTPUT-TOOL REPORT: Lists each planning process and its outputs. For
each output, lists the tool or tools which can be run to get that output information.
LANGUAGE LEVEL DATA DICTIONARY: Lists name, term type (having to do with
whether or not case-level terms can be associated with this term), and documentation.

storage. The dsrm configures the plexplan kb for use by planners and information
analyzers, providing a meta-structure for the planning knowledge stored by the user
via planning tools. Furthermore, it allows the plexplan kb to integrate that plan-
ning knowledge in a manner consistent with is planning decision-making needs. The
dsrm can be changed at any time to accommodate specific planning needs or a new
perception of the model underlying is development. Thus the meta-structure of the
planning information in the plexplan Knowledge Base is dynamic and flexible.
The process of dsrm construction is iterative. The system designer uses the dsrl
to construct an initial dsrm. He then invokes the plexplan Structural Analyzer to
determine the completeness and consistency of the dsrm within the plexplan kb.
The Structural Analyzer currently produces the reports listed in Table 1 .
Table 2 is part of a Process Output Tool report for a dsrm associated with a case
where plexplan was used. Changes are made via the dsrl and other plexsys kb
management tools until the system designer is satisfied that the dsrm is properly
constructed.
The user accesses plexplan via the Session Generator. The Session Generator

performs three functions. First, it manages the interface between the planner and the
plexplan kb via the input-output functions of the plexsys kb Manager. Second, it
receives the planning decision requirements from the user and invokes the proper
Planning Tools to provide information needed to support the decision-making pro-
cess. Third, it invokes the Decision Analyzer to provide reports and decisions to the
user. To perform these functions, the Session Generator depends upon an interaction
with the user. In the current plexplan prototype, implementation of the Session
Generator is confined to advising the user which Planning Tools may be run to
achieve the desired results. Future implementation will take up issues of Planning
Tool invocation and the storage of heuristics needed to analyze user decision require-
ments.

The Decision Analyzer analyzes data stored in the kb in accordance with the
structure of planning described by the dsrm. Reports currently produced by the
Decision Analyzer are listed in Table 3.
Table 4 is part of a Planning Process Output Relation Report for a relation of a

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 55

Table 2 PROCESS-OUTPUT-TOOL report

PROCESS analysis_of_impacts
OUTPUT ia

TOOL impact

OUTPUT impactor
TOOL impact

PROCESS enterprise

OUTPUT business

TOOL enterprise

OUTPUT customer
TOOL enterprise

OUTPUT data_set
TOOL enterprise
OUTPUT hardware
TOOL enterprise

OUTPUT information_system
TOOL enterprise

OUTPUT organizational

TOOL enterprise

PROCESS idea_surfacing
OUTPUT planning

TOOL csf, elee

PROCESS issue

OUTPUT issue_priority
TOOL elec_nom__grp
OUTPUT planning

TOOL csf, elee

PROCESS stakeholder

OUTPUT assumption
TOOL stakeholder

OUTPUT bedrock

TOOL stakeholder

OUTPUT investigate

TOOL stakeholder

OUTPUT sa

TOOL stakeholder

PROCESS stakeholder__identification
OUTPUT issue

TOOL stakeholder_id
OUTPUT stakeholder
TOOL stakeholder

recent case. The report generation softwar

form, for example, the matrices of the
TION REPORT. It relies upon information co
structure of the current model of planning
Among tools used in plexplan are Electron
Identification and Stakeholder Analysis based

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
56 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

Table 3 Decision Analyzer reports

CASE LEVEL DATA DICTIONARY: Lists name, language-level type associating data
item with language-level item, and associated documentation.
PROCESS OUTPUT DATA REPORT: For each planning process output which is a sin-
gle word (for example, dataset, informationsystem, planningissue), lists all data associated
with the process output term.
PROCESS OUTPUT DATA-NOT-FOUND REPORT: Reports those language terms
which have no data attached. For each term, reports tools to run which will supply that
data.
PLANNING PROCESS OUTPUT RELATION REPORT: For each planning process
output which is a relationship, produces lists of data associated with each term in the rela-
tion, the values the relation can take, and a matrix demonstrating the relationship. Rela-
tionships may have single attribute values and multiple attribute values.
COMPLETENESS REPORT: For each matrix, shows if all data items in the relation-
ship are related to at least one other data item via the relationship.

and Enterprise Analyzer. Other planning tools are used as needed. Ebs elicits issues
and ideas about a planning question from participants. Stakeholder Identification is
used to identify the people or groups who impact or who are impacted by planning
issues. Impact Analysis is used to form a network of planning environment elements
which impact and are impacted by other planning elements. The Enterprise Analyzer
is a tool constructed via scripting techniques, described below, and is used for
analyzing the planning environment. Via Stakeholder Analysis, stakeholders' re-
quirements or assumptions regarding planning issues are analyzed with regard to all
planning knowledge in the Knowledge Base.

3. Integration in PLEXPLAN
Five requirements are imposed upon a knowledge-based planning system for
integration of the multiple views described above: first, there is need for multiple
role assumption by a given knowledge item; second, knowledge extensibility must
permit dynamic knowledge addition; third, there may be no organization or schema
pre-imposed on the knowledge; fourth, the knowledge base should be directly fed by
appropriate tools; and fifth, tools should exist for dynamically "filling in" whatever
planning knowledge is known to the system users, but not specifically obtained from
is planning tools.

3.1 Multiple Role Assumption

The knowledge representation scheme in the plexplan Knowledge Base is the

semantic inheritance network (si-net)[22] . The major use of inheritance in plexplan
determines the language role of kb terms on one of three meta-language levels. In
[12], Kottemann and Konsynski described these three levels as axiomatic, median,
and instantial.

Figure 3 is a representation of a partial network using plexplan objects on three

meta-levels of language. The axiomatic level describes the most general of concepts;
in plexplan it includes such terms as model, input, output, synonym, statement,
and object. On this level a highest generality of model frames is present: models have

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 57

Table 4 Report on relationship: sa

Data values for relationship: sa

stakeholder

1 administration
2 computer

3 grad

4 instructional

5 research

6 student

7 student

8 undergrad
9 univ

assumption

1 access

2 administration

3 appropriate_workstations
4 can

5 central/integrated

6 communications
7 competitive

8 computer

9 computer

10 computing

11 conferencing
12 consulting
13 cost/affordability
14 course

Relationship value is importance

Matrix for relationship: sa

stakeholder

123456789

al 8 8
s 2 8
s 3 7 5 6
u 4 7
m 5 9
p 6 9 9 9 9 9
t 7 9
i 8 8
o 9 7
n 10 7 4
11 8 5 6 7
12 9 899779
13 6
14 7 6

Completeness report for relationship: sa

stakeholder: Complete
assumption: Complete

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
58 MCINTYRE, KONSYNSKI, AND NÜNAMAKER, JR.

•• (statement) (model}

I : ITT
n '* hes-output fmodel
• ^outputj ;
vu !

; hos-input fmodel^ :
H : [input j I
T ¡ has-transform / ' !
| ; fmodel ^ / ' '
' '' K transform] '' ^ ;
C ; ' / K }/
:

M •^ ^^T^VL ^

Estmt
| median / h
M •^ ^ - | - '

dei / --^^ v nas

D / ^^^^^-^input ' input

o (INFO '¿-^*~ - ( ts-oe ^

[svSTEMj Irelatlon)
N I f

N J J

*. instontiol xx ; j

3 r h'"" def ^^TiT^

3 ^analysis] I to support) Vs
T
R
N

** NOTE:
E

Figure 3. PLE

inputs, outpu
statement is introduced into the kb.

The second level is the median, from which general models of an environment are
formed. Median-level terms describe classes of objects or relationships and are
closer to the environment being modeled than axiomatic terms. Inheritance of
properties from the axiomatic to the median level is accomplished by defining
median terms in relation to axiomatic, again demonstrated in Figure 3. On the
median level a frame representation which describes the model underlying the tool
Enterprise Analyzer is stored in the Knowledge Base. Thus Enterprise Analyzer is a
model; is-oe (representing a relationship between information systems and organi-
zational entities) is a statement, is a model transform, and is a specific transform of
Enterprise Analyzer; information-system, is-oe-relation (representing the various

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 59

values the is-oe relationship can assume), and organizational-entity are model inputs
and specific inputs to Enterprise Analyzer. It should be noted that one necessary
extension to more traditional si-net uses is that certain relations between objects are
conceived of as having values, as in the case of the is-oe-relation. The statement
named is-oe has a median-level statement definition which links the information-

system, is-oe-relation, and the organizational-entity.

The third meta-level is the instant ial, which describes examples or instances of the
median-level terms. In Figure 3, the instantial-level value of the term information-
system is sales-analysis, the is-oe-relation has the value planned-to-support, and vp-
marketing is an organizational-entity. The is-oe statement has an instantial-level
counterpart, representing the fact that the sales-analysis information-system is
planned-to-support the vp-marketing. Multiple instantial-level counterparts of me-
dian-level language terms and multiple median-level counterparts of axiomatic-
level language terms are typically stored on the net. This demonstrates the ability of
the net to assign multiple meta-level language roles to an object. For example, the
organizational-entity is a model input, is an input of Enterprise Analyzer, is part of
the is-oe median statement definition, and has the instantial counterpart organiza-
tional-entity.
Of more importance to the is planning function is the ability for a term like vp-
marketing to assume multiple roles, as demonstrated in Figure 4. Different views of
the vp-marketing' s function within the planning environment have been established
by three model perspectives. From Enterprise Analyzer roles describing the vp-
marketing's relationship to the environment are obtained; from Stakeholder Identifi-
cation his/her stakeholder role is linked to potential strategies; from ebs he/she is
linked to critical issues he/she has identified. With the knowledge query tools in the
PLEXSYS Knowledge Base Management Tools, the multiple roles of the vp-marketing
are available to the planner for on-line Impact Analysis. To return to the original
example, analysis of the "purchase hardware" alternative is simplified by the
explicit knowledge that the vp-marketing stakeholder in this alternative plans to be
supported by and is currently supported by various information systems. For exam-
ple, it is important to know that the information systems that are most important to
him/her have been running in batch mode on a mainframe when one is planning for
purchase of networked micros.

3.2 Knowledge Extensibility

Because of the dynamism and complexity of the is environment, the problem formu-
lation, exploration, and solution derivation process is one of discovery. Many
viewpoints need to be considered. To fine-tune insight, greater depth of knowledge
requires numerous iterations of planning techniques. Knowledge of the planning
environment is constantly growing, requiring constant model extension. To meet
these requirements, the si-net in plexplan is a dynamic structure. Knowledge
represented in Figure 4 can have been integrated into the net at any point in the
planning process as more is discovered about the roles of the vp-marketing.

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
60

09

» h. y
k. « Li y

a N g
« ¡M r^i Œ
s « ¡M s 1
o a) £
- ' v¿y ^
'
X- '5
c o X X-
' ä c o

l O ' >' ^ '

si n l O ' f
g á¿ g ' 5 g g .2 g
ï a. 'IAAJ Kl)

c .t: S 1
ÖD
S
p 2J Z * * c

S ï - - ñ
1 & -S ♦
i
S - li) <u

I
"?

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 61

3.3 No Pre-imposed Knowledge Structure

In all but the most simplistic environments, any attempt by planners to pre-impose a
structure on a model of the is environment tends to constrain planning to the
foreseen. Si-net extensibility renders such pre-imposition unnecessary. On the medi-
an level, the Decision Structure and Requirements Model configures the kb in
accordance with the most current view of the planning environment. As that view
shifts, the DSRM may be dynamically updated to reflect new elements or relationships
in the planning environment. The instantial model forms as discovery is made of the
specific planning environment and instantial level knowledge is stored by planning
tool use.

3.4 Direct Tool-to-KB Linkage

The construction of an integrated model of the is planning environment should be as

transparent as possible to the tool user. In plexplan, tools placed in the environment
are linked directly to the kb, but the tool use is virtually unchanged from the
planner's perspective. Thus the plexplan environment imposes no restrictions on
tool use, and knowledge is fed to the kb in a manner consistent with the knowledge
view of the tool.

3.5 Median- and Instance-Level Language Augmentation

The perspectives on is planning provided to the kb by various tools cannot complete-

ly describe their dynamic and complex target. If planners determine that median- or
instantial-level knowledge augmentation is needed, tools are needed to fill in these
gaps. Tools available to the plexplan user to fulfill these tasks are based upon the
LANGUAGE_EDITOR and INSTANCE_EDITOR tools described in [8]. By
their use, median- and instantial-level terms and expressions may be integrated into
the net.

4. Model Scripting in PLEXPLAN

In an example described above, planners discovered that hardware usage had
become an important factor in generating alternative is implementation strategies.
The version of bsp they had used for is enterprise analysis did not explicitly model
the relation of hardware to users, business divisions, information systems, or data
bases. Other objects and relations in the model were satisfactory, but the "script"
provided for analysis was found to be incomplete. Thus, the next time is-enterprise
analysis was carried out, the planners would like to have the ability to change the
environmental analysis script by adding a new object and set of relations [1].
Two requirements for implementing scripting in models are that stored models

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
62 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

(?) « first leuel help:

documentation
linked to term
on Si-net

EHecutiue tools
peruse KB to
prouide second
leuel help

f model) - (iT)

isa
hos-

/7v ,

(í) /7v

has- / (d) N. no$-

Input / '. input

^ I X (*) '^ ®
finformation-lX
(system^

isa isa ¡$a

fíales- 1 fplanned- ^ ,

fíales- [ana.as.sj 1

(Ä) 0 0

Figure 5. Model Frames an

must drive tool functional

inherent structures, that
ed. These features are inc
planning tools.

4.1 Model Represent

Plexplan models are rep

Enterprise Analyzer has b
frame representation. Fi
frame to portray the exa
object as an input, the too
used to guide input mani

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 63

model output and stored on the net that way. For example, the expression "Enter-
prise Analyzer has-input information-system" is resident in the plexplan kb as a
part of the Decision Structure and Requirements Model. The Enterprise Analyzer
software generates a search for all expressions "enterprise-analyzer has-input."
These inputs are loaded into a menu window from which the user chooses among the
inputs he/she must provide for the tool.
Once all objects (information-systems and organizational-entities in the example)
are entered, the tool accesses all identified transform relationships within the dsrm.
In the Enterprise Analyzer model, these link the objects in accordance with the
median statement definitions defined in the dsrm. Relationships are defined between
numerous groups of model inputs. In Figure 5, the is-oe transform links informa-
tion-system and organizational-entity via the is-oe-relation. In the example, since
sales-analysis is an information-system and vp-marketing is an organizational-enti-
ty, the user may enter a value of the is-oe-relation between sales-analysis and the vp-
marketing. In many instances, there is no relation, but in the example the user
supplies the value ' 'currently-supports. ' ' Once the user instantiates Enterprise Ana-
lyzer objects and relationships, the Decision Analyzer reports may be run to portray
the values of the relationships and check for completeness.

4.2 Model Augmentation

The technique of model augmentation affords the ability to dynamically augment the
modeled objects and relationships in tools like the Enterprise Analyzer. When using
the Enterprise Analyzer, a planner may need to identify new model inputs and
relationships. By reconfiguring the Decision Structure and Requirements Model, the
planner may define new model inputs and relationships. To return to the hardware
example, the planner may include hardware information into the net on a one-time
basis by use of the median- and instantial-level language augmentation tools
LANGED and INSTED. If the user believes this information is likely to be elicited
again, the object "hardware" and relationships between "hardware" and other
objects can be added to Enterprise Analyzer in the dsrm.
This new model is not the original Enterprise Analyzer, but an Enterprise Analy-
zer-prime. If planners desire to have this model available to them in addition to the
original, they may request that the new version be added to the dsrm distinct from
the original Enterprise Analyzer. Thus, when the dsrm is loaded into the plexplan
kb, a new median-level model frame is constructed. Linked to it is all basic Enter-
prise Analyzer information and the new hardware objects and defined relationships.
This concept is portrayed in Figure 6, which is simplified for the sake of illustration.
The Enterprise Analyzer-prime model becomes another model in the model base and
is accessible like all others. Enterprise Analyzer-prime retains the organizational-
entity input of Enterprise Analyzer, and all the others. A new transform has been
added, oe-h, which links organizational-entities (oe) and hardware (h) on the
median level. One instantial-level statement which results from the tool

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
64 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

Enterprise Analyzer requesting the oe-h-relation is that the "is-manager is respon-

sible-to-purchase micro-computers." Documentation is available as before.
If, instead of adding a new model, the Enterprise Analyzer tool model within the
DSRM is changed, the Enterprise Analyzer software has no need of being changed
since it is still looking for all inputs and transform statements as before. The fact that
additions have been made to the script in terms of inputs and relationships makes no
difference to the way the software works.

5. Use of PLEXPLAN: The Computer Center Case

The plexplan environment and methodology were used recently to address
the planning needs of the Computer Center at a large university. The Computer
Center had been in its current state of organization for less than a year at the
inception of the study. Four groups which had heretofore been competing for
resources had been placed under one person who held the rank of vice-president at
the University. The VP became interested in the possibilities of using the plexplan
environment while attending a planning session associated with plexplan use for
another group.
Through discussion it became clear to the VP that there was a need for clarity
regarding the priorities of the Computer Center. Discussion focused around strategic
planning to determine proper strategic goals. After further discussion, questions
identified were the following: "What should be the goals of the Computer Center
with regard to its next five years? ' ' ' 'What will help and hinder the Computer Center
in reaching those goals?" "Who are the beneficiaries of those goals and how will
they benefit?" These questions were agreed upon as the starting point for the
planning process. Once a broad understanding of the strategic position of the Com-
puter Center was obtained, policy and implementation issues could be considered at
a later date.

5.1 DSRM Construction

The Decision Structure and Requirements Model for the Computer Center was
developed through a process of analysis of Computer Center strategic planning
needs. Based upon the target questions described above, appropriate plexplan
processes were included in the dsrm. The Issue Generation and Critical Issues
Identification processes were included to help answer the question, ' * What should be
the goals of the Computer Center with regard to its next five years?" The planned
output of these processes was a prioritized list of planning issues. The techniques
identified to get this information from the VP and his employees were the Nominal
Group Technique and Electronic Brainstorming.
Idea Surfacing and Analysis of Impacts were the processes described to address
the question, "What will help and hinder the Computer Center in reaching those

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 65

1 I-™
I ^® LU
aX ^® I
I? Sì Gii
^4ll¿ ?
i "lëj 1 S- a

Aï £ / '
/ ' V^ v
' V^ v »s.
C-/ e
WeITS e IX
I X X fi.
yJ-v^
£' ' s '&
U e / / 1 N = ^
e / N r

1
lulu= 1GC,
GC,

1
I
"S
e
_o

'S

Sí
g)
tí

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
66 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

goals?" The planned output of these processes was a list of ideas addressing the
question and an impact matrix organizing these ideas by which impacted which.
PLEXPLAN techniques chosen to address these processes were Electronic Brainstorm-
ing and Impact Analysis.
The Stakeholder Identification, Stakeholder Analysis, and Enterprise Analysis
processes were chosen to address the question, "Who are the beneficiaries of those
goals and how will they benefit?" The planned outputs of these processes were a list
of stakeholders, their requirements on the services of the computer Center, a prioriti-
zation of those requirements, and an analysis of the impact of the stakeholders on the
elements of the Computer Center organization. Techniques chosen for these
processes were Stakeholder Identifier, Stakeholder Analyzer, and Enterprise Ana-
lyzer.
Numerous passes were made on the dsrm throughout the planning sessions. The
Structural Analyzer reports were used extensively to determine the suitability and
consistency of the dsrm for the Computer Center. The Language Level Data Dictio-
nary was used to record the definitions of terms introduced for the purpose of the
case. The Process and Model Input and Output reports were used to check the
correctness of the dsrm and to provide further information on its applicability to the
case.

5.2 Enterprise Analyzer Scripting

Use of the Enterprise Analyzer was targeted to provide more in

on the relationships of customers to the Computer Center organization
Decision Structure and Requirements Language, a new model for the
Analyzer was constructed in the plexplan kb. Besides the objects com
uses of the Enterprise Analyzer (Organizational Entities, Business
Information Systems, and Data Sets), the objects Customer and Hardw
added.

Four new relationships were described. The first related Organizational Entities
and Customers ("Organizational Entity has Customer"). The purpose of this rela-
tionship was to establish the relationship between customers and entities within the
Computer Center who were responsible to meet the customers' needs. The second
related Business Subsystems and Customers ("Business Subsystem has Custo-
mer"). This relationship described the business systems with which customers
interact. The third related Customers and Hardware ("Customer interacts with
Hardware"). This statement recognized that one important means by which the
Computer Center meets the needs of its customers was through the hardware the
customers use. Finally, the relationship between the Customers and Information
Systems used to meet their needs was represented ("Information System serves
Customer").

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 67

Table 5 Computer Center Knowledge Base (KB) references to faculty

stakeholder faculty importance

assumption minimal

customer faculty interacts

organizational

customer faculty
impactor faculty impacts impactor high

5.3 Knowledge Integration for St

Case-level information was entered into

targeted for each planning process. One
in Stakeholder Analysis. Among their o
Enterprise Analysis was also represen
analysis of the kb, examination was p
Computer Center personnel, business sy
all other kb objects. For example, the i
with the median terms stakeholder from
pactor Analysis, and customer from Ent
ments in Table 5 are but 5 examples of t
the Decision Analyzer at an early stage

6. Future Research

Plexplan has proved to be a valuable tool for integrating planning information

and for responding to a dynamic planning environment. The purpose of future
research on plexplan is to further explore the basis for knowledge-based strategic
decision making in the Information Systems area. Research will concentrate in the
areas of heuristic reasoning, inferencing, and dynamic rule-based systems. There-
fore, implementation issues include dynamic rule-heuristic elicitation, activation,
use, and storage within the current environment. The eventual aim is to provide the
local manager with the facility for applying "local expertise" to the knowledge
contained within the Knowledge Base.
All plexplan tools are currently operational on a DEC VAX cluster. Certain
plexplan planning tools are currently operational on networked NCR PC4s and
IBM XTs and ATs. A planning laboratory is currently in use for group planning
sessions using plexplan planning tools on these networked micro-computers. Im-
plementation research is progressing for moving the rest of the plexplan environ-
ment from the mini-computer environment to the micro-computer and network
environment.

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
68 MCINTYRE, KONSYNSKI, AND NUNAMAKER, JR.

References

1. Barr, A., and Feigenbaum, E. A. The Handbook of Artificial Intelligence. Vol. 1.

Stanford, California: HeurisTech Press, 1981.
2. Blumenthal, Sherman C. MIS: A Framework for Planning and Development. Engle-
wood Cliffs, New Jersey: Prentice-Hall, 1969.
3. Gibson, Cyrus F., and Nolan, Richard L. Managing the four stages of EDP growth.
Harvard Business Review (January-February 1974), 76-88.
4. IBM. Business Systems Planning, GE 20-0527-1, 1975.
5. King, W. R. Planning for strategic decision support systems. Long Range Planning,
16, 5 (October 1983), 73-78.
6. King, W. R., and Cleland, D. I. A new method for strategic systems planning.
Business Horizons (August 1975).
7. King, W. R., and Cleland, D. I. Information for more effective strategic planning.
Long Range Planning, 10 (February 1977), 59-64.
8. Konsynski, B. R., and Dolk, J. D. Knowledge abstractions in model management.
Transactions on Decision Support Systems, 1982.
9. Konsynski, B. R.; Kottemann, J. E.; Nunamaker, Jr., J. F.; and Stott, J. W. plexsys-
84: An integrated development environment for information systems. Journal of Manage-
ment Information Systems, 1, 3 (Winter 1984-85), 64-104.
10. Konsynski, B. R., and J. F. Nunamaker. plexsys: A system development system. In
Couger, J. D.; Colter, Mel A.; and Knapp, R. W. Advanced System Development/Feasibility
Techniques. New York: John Wiley and Sons, 1982, 399-424.
11. Kottemann, J. E. Formalisms for business information system development. Ph.D.
dissertation, University of Arizona, Department of mis, 1984.
12. Kottemann, J. E. , and Konsynski, B. R. Metasystems in information systems develop-
ment. Proceedings of the Fifth International Conference on Information Systems, Tucson,
Arizona, 1984.
13. Kottemann, J. E., and Konsynski, B. R. Information systems planning and develop-
ment: Strategic postures and methodologies. Journal of Management Information Systems, 1 ,
2 (Fall 1984), 45-63.
14. Kriebel, Charles H. The strategic dimensions of computer systems planning. Long
Range Planning (September 1968).
15. Mason, R. O. Current research issues. In McFarlan, F. Warren, ed. The Information
Systems Research Challenge. Boston, Massachusetts: Harvard Business School Press, 1984,
279-304.
16. Mason, R. O., and Mitroff, I. I. Challenging Strategic Planning Assumptions . New
York: John Wiley and Sons, 1981.
17. McFarlan, F. W. Problems in planning the information system. Harvard Business
Review (May-June 1971).
18. McFarlan, F. W. Current research issues: An alternate perspective. In McFarlan, F.
Warren, ed. The Information Systems Research Challenge. Boston, Massachusetts: Harvard
Business School 'Press, 1984.
19. McFarlan, F. Warren, and McKenney, James L. Corporate Information Systems Man-
agement. Homewood, Illinois: Richard D. Irwin, 1983.
20. Mclntyre, Scott C. PLEXPLAN: An integrated intelligent environment for informa-
tion systems planning. Ph.D. dissertation, University of Arizona, Department of mis,
1986.
21 . McLean, E. R. , and Soden, J. V. Strategic Planning for MIS. New York: John Wiley
and Sons, 1977.
22. Minsky, M., ed. Semantic Information Processing. Cambridge, Massachusetts: MIT
Press, 1968.
23. Rockart, J. F. Chief executives define their own data needs. Harvard Business Review,
57, 2 (1979), 81-93.
24. Rowe, A. J.; Mason, R. O.; and Dickel, K. Strategic Management and Business
Policy. Reading, Massachusetts: Add ison- Wesley, 1982.
25. Shrivastava, Paul. Decision support systems for strategic ill-structured problems.

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms
 AUTOMATING PLANNING ENVIRONMENTS 69

Proceedings of the Third International Conference on Information Systems, Ann Arbor,

Michigan, 1982.
26. Shrivastava, Paul. Strategic planning for MIS. Long Range Planning, 16, 5 (October
1983), 19-28.
27. Stott, J. W. Principles for computer-aided information systems development. Ph.D.
dissertation, University of Arizona, Department of mis, 1984.
28 . Volkema, Roger J . Problem formulation in planning and design. Management Science,
29, 6 (June 1983), 639-652.

This content downloaded from

193.115.221.228 on Mon, 10 Jul 2023 09:00:20 +00:00
All use subject to https://about.jstor.org/terms