Structuring Modeling Knowledge for Collaborative ... - CiteSeerX

Structuring Modeling Knowledge for Collaborative Environments P. R. Balasubramanian and Melanie L. Lenard Boston University School of Management {bala, mlenard}@bu.edu Abstract We explore how a collection of models and related modeling knowledge could be made available over an organizational Intranet. The objective is to create an environment that will enable sharing and re-use of models and will promote collaborative work on models. Because of their widespread use in organizations, we will focus on spreadsheet models to illustrate our concepts. We begin by discussing the various kinds of knowledge about models that should be stored in this knowledge base and how such knowledge could be captured and stored on a corporate Intranet. Next, we describe how one could use Structured Modeling (SM) as the framework for organizing the knowledge contained in the spreadsheet models per se. We propose capturing the model schema graphically using a generic structure diagram. A spreadsheet consistent with the model schema would be generated automatically. The individual building the spreadsheet model would be asked to supply details (data and functional relationships). He or she would be free to modify the physical appearance of the spreadsheet in any way that did not violate the relationships shown in the diagram. Finally, we describe the architecture of a system that would store, retrieve, and distribute the models and modeling knowledge to users. This description includes a discussion about the distribution of the functionality between the client, the server and the middle layers. We also provide some references to existing tools that could be used to capture the various types of knowledge that we have identified.

1.

Introduction

Models1 have come to be recognized as important organizational resources. Work in the field of model management [3, 9, 12, 23] has tried to find ways to help decision makers make better use of models. However, most of the approaches in the literature deal with capturing just one type of knowledge (we call it content knowledge) about models. Also, it has generally been assumed that these models are stored in one place. The recent growth of client-server applications and the World Wide Web has created a new environment, along with associated technologies, for applying the concepts of model management.

In a previous paper [1], we began our discussion of how a collection of models and related modeling knowledge could be made available over an organizational Intranet. We believe that such a facility would not only promote sharing and re-use of models but would also promote collaborative work. Because of their widespread use in organizations today (30 million users by some estimates[22]), we will focus on spreadsheet models as a vehicle for explaining and eventually demonstrating our concepts. We begin in the next section with some background for this work. In Section 3, we describe the various layers of modeling knowledge that are needed to support re-use. Then, in Section 4, we discuss how the Structured Modeling [9] framework could be applied to organizing one layer of this knowledge. We conclude with a discussion of the architecture for distributing models and modeling knowledge to potential users.

2.

Background

After reviewing the literature on Model Management Systems, Bharadwaj et al [3] have identified three approaches that researchers have taken to model representation and creation: database, graph-based, and knowledge-based. The database approach, envisions models being organized using a particular data model, such as EntityRelationship model or the Relational model, to insulate users from the physical details of the model base organization. Using the graph-based approach, a mathematical model is represented by one or more graphs or digraphs. The use of graphs for knowledge representation provides advantages such as clarity, ease of programming and ease of manipulation. Finally, using the knowledgebased approach, a variety of knowledge representation schemes such as semantic networks, first order predicate calculus, and production rules have been used for model representation and management [3]. The Structured Modeling framework, that we use in this paper, is an example of a graph-based approach and it has many commonalties with the E-R approach.

1

For our purposes, we define models as mathematical abstractions representing essential features of complex systems.

1060-3425/98 $10.00 (c) 1998 IEEE

Model Builder

Decision Maker

Analyst

Abstractions

Data

Model Model Definition Definition

Model Manipulation

Model Model Access Access

Models

Results

Answers

Questions

Figure 2.1: User Views of Model Management

Our focus in this paper will be on using the Intranet as a modeling environment. In that context, Bharghava et al [4] have described a system, call DecisionNet, for sharing models and solution algorithms over the Internet. For locating models, they propose two architectures, each built for one of two modeling languages: AMPL [8] and GAMS [5]. Both architectures rely on model suppliers to register their product in a "yellow pages" that would be searched by potential model users. The architecture built for AMPL relies primarily on the user to be knowledgeable about models, methodologies, and languages. In contrast, the architecture built for GAMS expects very little modeling knowledge from the user. Instead, it requires model suppliers to provide more detailed information about the products they register and relies more on the system (in the form of "software agent") to help the user identify and use models. In the area of spreadsheet modeling, Ronen et al [20] provided a structured approach to the design of spreadsheet models. They propose the use of Spreadsheet Flow Diagrams (SFD) as a way to encourage structured, top-down design of spreadsheets. Isakowitz et al [10] propose separating the logical and physical aspects of spreadsheet models in order to support the sharing and reuse of spreadsheet models. They identify the primitives needed to represent spreadsheets in addition to providing a factoring/synthesizing algorithm that will decompose/build spreadsheet models. They suggest that their work would lead to the development of spreadsheet model management systems (SMMS). Plane [18] used ideas from influence diagrams to create a graphical technique called influence “charts” for representing the logical structure of spreadsheet models. Plane highlights two lessons he learned from his experimentation with these charts in a classroom setting. First, he found that the graphical technique was useful for building complex models. He also found out that the technique improved communication within model building teams.

Although the ideas expounded in the above papers are very interesting, we feel that there are two additional requirements for leveraging spreadsheet models on an Intranet. First of all, there is need for a formal, theory based framework to organize the knowledge contained in a spreadsheet model. We believe that such a framework would be very useful, given that fact that spreadsheet modeling is, probably, the most used (and abused!) modeling technique in an organization. In this paper, we describe an approach that is based on the general modeling formalism of Structured Modeling [9]. The second requirement that we have identified is a need for a knowledge base for storing other types knowledge of about models. So far, researchers have focused on capturing just the content layer of knowledge associated with the models. In this paper, we identify and explore other knowledge types that would be useful. In addition, we refer to some techniques that can be used to capture the knowledge. The content knowledge, described extensively in the literature, is useful for one category of user -- the model builder. We believe that there are three roles that can be played by users of models (see figure 2.1), and this leads them to have different views of model management. The first role is that of a model builder. This person is involved in building models by abstracting from some real life phenomenon. After understanding the domain, this person builds and maintains models using a model definition language. Another role is that of an analyst. An analyst obtains results for decision makers by applying models to data. To do this, the analyst has to identify appropriate models, manipulate them to suit the current problem and run these models with different data sets to produce results. If the analyst can't find an appropriate model, he/she interacts with model developers to get one built. Types of Users

Workflow

Decision Maker

Evaluative Operational

Analyst

Content Model builder Process

Figure 3.1: Layers of Modeling Knowledge The last role that we have identified is that of a decision maker. This person is mainly interested in

1060-3425/98 $10.00 (c) 1998 IEEE

getting his/her questions answered. To accomplish that, the decision maker may try to directly access a model using a suitably designed interface, provide it with the requisite data and then run the model. In other instances the decision maker may choose to delegate the task to analysts. Although we have described each role separately, we would also like to note here that a single person can play all three roles. Since the users playing these roles have different objectives, they are likely to need different types of modeling knowledge. In the next section we describe these types of knowledge.

3.

Modeling Knowledge

In order to make any particular model available for reuse, we believe that there are many kinds of modeling knowledge that must be available to the user (model builder, analyst or decision maker). We have classified these into five layers of knowledge. These are pictured in Figure 3.1 and described below. Content Knowledge: This knowledge captures the logical workings of a spreadsheet model. It is valuable when analyst wants to make some minor changes to an existing spreadsheet model or when a model builder wants to reuse one or more existing models to build a new one. For example, while using a profit and loss model, an analyst may want to change the formula for, say, depreciation. This would be difficult if he or she did not understand the existing formulas. In [10], Isakowitz et al use the schema representation language (FRL) as an internal representation for spreadsheet schemas. In this paper, we use SM as a framework to capture content knowledge. Process Knowledge: Under this layer is stored all the knowledge that deals with the process of building spreadsheet models. This knowledge will facilitate the building of models and their maintenance under changing environmental conditions. Model builders are involved in cycles of information gathering and discussions with other participants. Very rarely do model builders get their models "right" the first time. They are constantly changing the structure of the models and its underlying assumptions. While they make the changes to parts that have existed for a long time, they try to figure out the reasons for the current assumptions. To facilitate the ability to modify models under such circumstances, it is necessary to have as much access to the formulation history in as organized a manner as possible [7]. Usually, model builders rely on memory for this purpose, but for large problems the limitations are obvious. This type of knowledge will be valuable primarily to model builders and to a lesser extent to analysts and decision-makers.

Evaluative Knowledge: The evaluative layer contains knowledge about the model’s overall value. It provides answers to analysts and decision-makers asking questions about issues such as, how reliable are the model results, how robust is the model, how useful was the model in helping with decision making. Such knowledge can be obtained by corresponding with or interviewing previous users or the model builder. Operational Knowledge: This layer of knowledge contains information about model pragmatics. Once analysts have identified a model to use, they would like to know what data they will need to run the model, what keystrokes they should perform to get the results, how long does it take for the model to run, etc. Usually, such information is available in user manuals. In addition, this layer may contain information about solution strategies, such as goal seeking, optimization, scenario analysis. Workflow Knowledge: Under this layer, one captures the knowledge that will facilitate workflow management. Workflow is the coordination of the execution of a process that is designed as a sequence of tasks [14]. Workflow management systems aim to define, support and monitor the coordination of tasks in a business process. Currently, there exist several formalisms for capturing workflow knowledge: action workflow diagrams [17], role interaction nets [19], dynamic workflow management [14]. Workflow knowledge would help the system "push" relevant models to the users as and when they need it. To illustrate how the layers of modeling knowledge might be used, consider the following example. Forecasting the earnings for the foreseeable future is a recurrent event in most organizations. In the case of Quantum Consulting, this forecast was presented during their quarterly consultant meetings. Jerry, the president of the company, would present the group with an overview and finish with a status report on performance compared to the goals that were set. He relied on his office assistant, Kathy, to provide him with the revenue projections. Kathy usually called the managers for the various practices to get their revenue estimates. She would use these numbers and other assumptions to make the earnings projections. Recently, Kathy left the company to pursue other interests. Since a quarterly meeting was fast approaching, Jerry quickly moved another employee, Julie, to her position. The first thing that Julie did was to arrange a half day meeting with Jerry to get an understanding of the overall process. In our framework, this knowledge would reside in the workflow knowledge base. After she understood the process, Julie wanted to know if there were any standard forms, or spreadsheet models available to help her in the process. Jerry told her

1060-3425/98 $10.00 (c) 1998 IEEE

that Kathy had developed a spreadsheet model for the forecasting. After talking to the network administrator, Julie located the spreadsheet without much difficulty. However, she had problems in using the spreadsheet. She did not know where the assumptions were stored, or what data she had to supply, or who could provide her with the information, etc. In essence, she was looking for operational knowledge. To solve this problem, Jerry authorized the human resource department to hire Kathy to come in on a weekend to train Julie. For the next quarterly meeting, one major change was causing serious problems for Julie. One of the company’s clients, Mtech, decided to infuse some capital into the company and a guaranteed set of projects in exchange for a 15% discount in the rates charged by Quantum. This meant that the projected sales growth rate had to be changed to reflect the Mtech business. Since Julie did not have to make any changes to these assumptions during the previous quarter forecast, she was at a loss. If she had a knowledge base containing content knowledge, she would have realized that the projected growth rate was 10% for the next three quarters and 20% for the following two. Knowing this, she could confidently add the guaranteed revenues from Mtech to the model and get the new net earnings estimates. 4.

Capturing Content Knowledge

In this section we explain how structured modeling can be used to capture the content knowledge of models. Structured modeling is a framework for representing models based on a set of interrelated definitions of all the elements comprising a model. In effect, this definitional system is a model of models or a meta-model. Structured modeling identifies the basic components of models, the relationships among these components, and conditions under which a model may be termed "structured". All this is accomplished using three basic types of elements: entities, attributes, and functions. For a tutorial on structured modeling, refer to [15]. The basic reference for structured modeling is [9]. For a spreadsheet model to be re-used, new users (model builders and possibly analysts) will need an easy way to learn about its inner workings. This can be difficult because the very freedom allowed by spreadsheets (i.e., any given cell in the spreadsheet may contain either data or a formula or some text) often obscures the logical design of the model (i.e., the model schema). Isakowitz et al [10] propose a method for extracting the logical structure and data elements from a spreadsheet written in the normal way. The first step in their method asks that users outline their spreadsheet; then a factoring algorithm extracts the model schema (along with the data, editorial, and binding properties) for the spreadsheet.

They also explore how the model schema, once obtained, can serve as a template to synthesize physical spreadsheets. Taking this idea one step further, we propose that model builders work with a model schema (in effect an outline of the spreadsheet) throughout the modeling process. This model schema would function for a spreadsheet in much the same way as a data model schema functions for a database. The model schema would capture the logical relationships in the model and would serve as the basis for the code creating the physical spreadsheet. We will begin by describing our proposal for a model schema. Then we show an example of the spreadsheet that would be generated from it and discuss how the user would work with it. 4.1.

Model Schema

We propose representing the model schema graphically using a generic structure diagram. This generic structure diagram is based on the genus level graph of SM and is similar to influence charts suggested by Plane [18]. The generic structure diagram would always be available as an alternate representation of the spreadsheet. (Having an alternate view of the spreadsheet is analogous to what is done in Microsoft Project ™ where project activities may be viewed as a PERT chart or a GANTT chart or as a spreadsheet containing activities, precedences, duration, start and finish dates.) As an illustration, consider the spreadsheet model used by Isakowitz et al [10](see Figure 4.1). It is a projection of Profit and Loss over a period of 6 years. The generic structure diagram for this spreadsheet model is depicted in Figure 4.2. In the generic structure diagram, rectangles represent entities, triangles represent attributes, and octagons represent functions. Solid lines show functional dependence. For example, the calculation of COGS (Cost of Goods Sold) depends on Sales and COGS_Rate. Dotted lines indicate "is indexed by" or "is an attribute of". For example, Lease is indexed by Year, meaning that there is a value for the attribute Lease corresponding to each instance of the entity Year. The special entity "Scenario" is used to index the assumed values of attributes such as Growth_Rate. This allows the user to take advantage of the spreadsheet's capability (at least in Microsoft EXCEL™ to generate multiple scenarios from the same spreadsheet model. For each scenario, the user supplies a name (e.g., Base Case) and values for those attributes designated as determining the scenario. This convention also avoids the awkwardness of having attributes that do not belong to any entity.

1060-3425/98 $10.00 (c) 1998 IEEE

A

B C D E F G 1 g ro w t h o v e rh e a d C O G S t a x ra t e 2 a ssu m p t io n s 10% 2 ,5 00 6 0% 48 % 3 4 P& L Fo re c a st (a ll fig u re s in 0 0 0 ’s) 5 --------------------------------------------------------6 7 1992 1 9 93 19 9 4 1 9 95 1 99 6 1997 8 ====== ====== ====== ====== ====== ====== 9 sa le s 6,000 6 ,6 00 7,26 0 7 ,9 8 6 9,14 8 10,280 10 C O G S 3,600 3 ,9 60 4,35 6 4 ,7 9 2 5,48 9 6 ,1 6 8 11 o v e rh e a d 2,500 2 ,5 00 2,50 0 2 ,5 0 0 2,50 0 2 ,5 0 0 12 le a se 100 1 00 50 0 500 50 0 500 13 g ro ss ( 200) 40 (9 6 ) 194 65 9 1,112 14 t a x 0 19 0 93 31 6 534 ----------------- ---------------- ---------------- ---------------- ---------------- --------------15 ( 200) 21 (9 6 ) 101 34 3 578 16 n e t in c o m e 17

Figure 4.1: Sample Spreadsheet

Scenario

Year Growth_Rate Cur_Sales

COGS_Rate

Sales Lease

COGS

Overhead

Tax_Rate

Gross Taxes Net_Inc Figure 4.2: Generic Structure Diagram for P&L Forecast

There are restrictions on what constitutes a valid diagram. For example, there can be no cycles -- that is, if Sales is dependent on Advertising, then Advertising cannot be (even indirectly) dependent on Sales. (This is another

way of saying there must be some sequence for evaluating the spreadsheet.) Also, an attribute can be dependent only on an entity; a function can be dependent only on attributes and other functions. These and other rules can be enforced during the drawing process. Jones [11] has used

1060-3425/98 $10.00 (c) 1998 IEEE

graph grammars as the basis for a syntax-directed editor for graphical representations of structured models. Also, for each of the functions shown on the diagram, the user will be asked to specify a generic formula using the names of attributes or other functions. This formula might be hidden from view or shown on the diagram For example, for "Gross" the user might write the formula: Gross = Sales - COGS - Lease - Overhead We find this graphical representation to be intuitively appealing, and we have some

anecdotal evidence (see Plane, [18]) that it is helpful to model builders. However, it may become unwieldy for larger, more complex models. For this and other reasons, we may wish to have a text version of the model schema as well. Figure 4.3 is an illustration of what this might look like for this example. The syntax used for specifying the generic components of the model and their dependencies follow Geoffrion’s [9] original proposal. The name of each component is in bold face type. Entity, attribute, and function components are indicated by the notation /e/, /a/, and /f/, respectively. Functional dependencies are enclosed in parentheses; indexing dependencies are enclosed in braces.

Scenario /e/ Year /e/ Growth Rate /a/ {Year, Scenario} Cur_Sales /a/ {Scenario} COGS_Rate /a/{Year, Scenario} Overhead /a/ {Scenario} Tax_Rate /a/ {Year, Scenario} Lease /a/ {Year, Scenario} Sales (Growth_Rate, Cur_Sales) /f/ {Year} COGS (Sales, COGS_Rate) /f/ {Year} Gross (Sales, COGS, Lease, Overhead) /f/ {Year} Taxes (Gross, Tax_Rate) /f/ {Year} Net_Inc (Gross, Taxes) /f/ {Year}

Figure 4.3. Model Schema (text form)

1060-3425/98 $10.00 (c) 1998 IEEE

Instructions

Data and Formula Entry

Formulas for

COGS

=Sales*COGS_Rate

generic functions

Gross

=Sales - COGS - Lease Overhead

Taxes

=IF ((Gross > 0), Tax_Rate*Gross,0)

Net_Inc

=Gross - Taxes

Enter name for Scenario

SCENARIO Base Case

Enter values for each Scenario attribute

Cur_Sales 6000

Enter labels (text only) for each entity.

YEAR

Growth_Rate Enter values for corresponding attributes Lease

Enter formulas for individual functions

Sales

Overhead

COGS_Rate 60%

2,500

1992

1993

1994

1995

Tax_Rate 48%

1996

1997

0% 100

10% 100

10% 500

10% 500

20% 500

20% 500

6,000

6,600

7,260

7,986

9,148

10,280

P&L Forecast YEAR 1992 1993 1994 1995 1996 1997 ======== ======== ======== ======== ======== ======== ======== Sales 6,000 6,600 7,260 7,986 9,148 10,280 COGS 3,600 3,960 4,356 4,792 5,489 6,168 Lease 100 100 500 500 500 500 Overhead 2,500 2,500 2,500 2,500 2,500 2,500 Gross (200) 40 (96) 194 659 1,112 Tax 0 19 0 93 316 534 ---------------- --------------------- ------------------- ----------------- ---------------- ---------------- --------------------------------------Net_Inc (200) 21 (96) 101 343 578

Figure 4.4: Generated Spreadsheet

1060-3425/98 $10.00 (c) 1998 IEEE

4.2.

Working with the Spreadsheet

Based on the information shown in the diagram in Figure 4.2, the spreadsheet shown in Figure 4.4 would be generated. Note that the generic formulas are repeated at the top of the spreadsheet for easy reference. Also, some areas of the spreadsheet have been shaded to indicate where the user would enter details for data or formulas. (We would expect to have a "wizard" to guide the user through the steps of supplying the detail.) First, the user would enter names or labels for the instances of the entities, such as "Year". (These could be the actual years (1992, 1993, etc.) or just an identifying number (1, 2, etc.). However, the data entered would be restricted to text (not numeric) form so that it could be used to create names for cells.) Once this was completed, areas of the spreadsheet would be allocated for all of the attributes and functions. Each such area will be given a corresponding name.

Named Area

Next, the user would enter values for the attributes. Note that since the attributes "Lease" and "Growth_Rate" depend on "Year" in Figure 4.2, the spreadsheet in Figure 4.4 allows space for entering a value for each of these attributes for each year specified. Note that Sales has a self-referential arrow in Figure 4.2. This indicates that the formula for Sales in some years is dependent on Sales in other years. In such a case, the user would be obliged to enter these formulas individually in the usual way. An area in the spreadsheet is set aside for supplying this detail. For the model in shown in Figure 4.4, Sales in 1992 is set equal to the attribute Cur_Sales. For the years 1993-1995, sales are forecasted to grow linearly. In subsequent years, the growth rate is applied to the average of the preceding two years. Although the generic structure graph does not capture these details, the auditing tool (see Figure 4.5) supplied with EXCEL can be used to get a graphical representation of this relationship.

Array Formula

Figure 4.5: Modeling Aids in EXCEL

1060-3425/98 $10.00 (c) 1998 IEEE

Auditing Tool

Finally, the generic formulas for the functions will be translated into array formulas in the spreadsheet. As an illustration, Figure 4.5 shows the EXCEL window with the menu bar and the formula bar along with the spreadsheet. The cells for the function "Gross" are selected, causing the name of the highlighted area ("Gross") and the array formula defining the value of "Gross" to appear on the formula bar. The spreadsheet does not permit altering an individual cell in any area defined by an array formula. If a user wishes to enter elements of a function individually, he/she would be required to return to the generic structure diagram and add a self-referential arrow. Of course, the user can change the array formula shown at the top of the spreadsheet -- this would cause the corresponding formula in the diagram to be changed also. The spreadsheet user is free to modify the physical appearance of the spreadsheet in any way that does not violate the relationships shown in the generic structure diagram. For example, the user might choose to move a section of the spreadsheet to a different place on the same sheet (or to a different sheet) or the user might choose to transpose the rows and columns of a given area. (In the terminology of Isakowitz et al, these would be changes in the binding properties of the spreadsheet. It should be noted, however, that the user would be prevented from moving part of any area (e.g., Net_Inc) defined by an array formula.) Also, the user could format entries or add labels, shading, lines, notes, etc. in the usual way. (In the terminology of Isakowitz et al [10], these would be changes in the editorial properties of the spreadsheet.) To understand the usefulness of storing content knowledge using SM, let us go back to the example described at the end of section 3. From that description, it is clear that Julie did not have a good understanding of the spreadsheet model that she discovered with the network administrator’s help. If the model schema were captured using a generic structure diagram, Julie can get some help when she tries to make changes to the spreadsheet model. For example, let us assume that when she learns about the infusion of capital from Mtech, she tries to change the sales estimates in the spreadsheet. Based on the generic structure diagram, we can generate an error message indicating that the sales estimates are dependent on sales in other years. Thus the content knowledge can help her understand the spreadsheet model and reduce errors made in modifying it. 5.

Architecture

For identifying the basic components of an architecture to support collaborative modeling environments, we look to the DSS design literature [21, 23]. Researchers in that field describe three major DSS components: a dialogue management system to facilitate the dialogue between the user and the system, a data manager to manage the data and a model manager to manage models. Historically, decision support systems have been based on a centralized model. These systems placed the model manager, data and interface manager in a single computer. With the advent of local area networks, models were often duplicated and changes made to them were not controlled in a systematic way. This results in multiple versions and inconsistent results. The next generation of computing, client/server, brings additional opportunities and challenges for maintaining model integrity while sharing models and related information. A key issue for designers building decision support systems, using the client/server model, is how to partition the functionality between the clients and servers. A simple approach would be to store the model manager (in our case, all the code providing the collaborative model management system functionality) and dialogue manager in the client. The model base with the spreadsheet models and the associated data is stored in the server. This approach would result in a tight coupling between the model base and the client. This means that if we make a change to the application logic, the model base has to be modified to accommodate the change. Another approach -- a three-tiered one -would be to make the client responsible only for presentation and user interface logic. This allows the server to specialize in maintaining the model base and the database. The middle tier stores the logic for constructing or revising models and the strategy for accessing the information that will facilitate this change. This allows loose coupling between the client and the server, thereby allowing many unrelated clients to use the same server. The architectures described above are good for supporting generic client/server computing. They are not designed to support collaborative work. The model management environment described in this paper has many layers of knowledge whose content is generated by using a collaborative process. Hence, there is a need for a new architecture and supporting tools. We have chosen an Intranet as an environment for enabling the development of our system for the following reasons. An Intranet is a

1060-3425/98 $10.00 (c) 1998 IEEE

simple client/server architecture with client programs (browsers) implemented for all popular platforms; it supports widely-dispersed, crossorganizational work groups; there are several systems in the market today, that have been built around the Intranet technology, to support collaborative processes. For all these reasons, the Intranet is a sound technology for developing and deploying collaborative model management systems. Even so, we have to make decisions about partitioning the functionality between the client

(browser) and server, just as in the case of the traditional client/server model. Figure 5.1, which is based on the architecture described in [2], shows a preliminary architecture for a decision support environment that will support the functionality described in section 3. This environment has a server that hosts a web server, a request handler, an operations handler, a data base and a layered knowledge base.

Layered knowledge base

User/ Browser/ Applets/ Plug-ins

HTTP request

Web Server Interfaces CGI, NSAPI, ISAPI

Web Server

Request Handling

Operation Handling

HTTP response

Database

Figure 5.1: Architecture for a Collaborative Modeling Environment When using this architecture, the user interacts with the system by submitting queries through HTML forms or using applets. These applets can be used to locally handle user navigation, manage layouts and displays, perform computations, and compose the user query. The users’ query, which varies based on the type of user -- model builder, analyst or decision maker -- is then passed to a request handler that translated between the users’ vocabulary and the system’s internal modeling and access vocabulary. Finally, the query is sent to the operations handler which determines the query processing strategy. The operations handler implements the requested

functionality by interacting with the database and the knowledge base. For example, if a particular model has to be retrieved, the operations handler constructs the query to get the model, run it, and create reports. In other instances, users may send a request for information stored in the layered knowledge base. Again, a request is sent to the operations handler. Just as in the case of the request for models, the operations handler converts these requests into queries that can be sent to the knowledge base. What we have described above is a preliminary architecture for a collaborative model management system. Earlier, in section 4, we described how SM

1060-3425/98 $10.00 (c) 1998 IEEE

can be used to capture content knowledge. As for the other layers of knowledge, we still have to provide support for the processes that create them and describe structures to store them. In the table below, we refer to the tools that could potentially be used to do that.

systems that have to in place to encourage decision makers, modelers and analysts to share their experiences and models. In addition, new processes have to be put in place to facilitate the use of the collaborative environment.

Bibliography Type of Knowledge

Tools for support

Workflow Knowledge

RIN [15], ActionWorkflow [13], DWM [10] Caucus2, Webshare3, Newsgroups Caucus, Webshare, User Manuals Structured Modeling [6], FRL [7], Influence Charts [14], E-R Modeling gIBIS [4]

Evaluative Knowledge Operational Knowledge Content Knowledge

Process Knowledge

6.

1.

2.

3.

4.

Future Work

As a first step, we plan to evaluate the effectiveness of SM as a modeling technique to capture content knowledge. To perform this assessment we will run some experiments asking students in the School of Management to build and modify models aided by generic structure diagrams. Next we will consider ways such as the one described in [16] to structure the model base and knowledge base. We will then test our layers of knowledge for usefulness and completeness. Also, we will explore the ability of SM to capture the other layers of knowledge. Later, we will develop the collaborative environment described in the paper and implement it in an organization where spreadsheet modeling is common. This will allow us to evaluate the framework and architecture and make the necessary changes to deliver the functionality. Finally, once we have an implementation in place, we would like to explore how this system is being used to deliver the model management as a capability. A capability calls for more than an implementation [13] of a technology; it requires also organization structure changes and new management processes. For example, in the case of the collaborative environment that we describe, organizations have to think about the incentives

5.

6.

7.

8.

9.

10.

11.

12.

13. 2 3

URL: http://www.caucus.com URL: http://www.radnet.com

Balasubramanian, P. and Melanie L. Lenard, Collaborative Environments for Leveraging Modeling Knowledge, Proceedings, AIS Americas Conference, August 1997. Bentley, R., Horstmann, T., and Trevor, J., The World Wide Web as enabling technology for CSCW: The case of BSCW, Computer-Supported Cooperative Work: Special issue on CSCW and the Web, Vol. 6 (1997), Kluwer Academic Press. Bharadwaj, A., Choobineh, J., Lo, A. and Shetty, B. "Model Management Systems: A Survey," Annals of Operations Research, Vol 38, 1992. Bhargava, H., Krishnan, R., Roehrig, S., Casey, M., Kaplan, D., and Müller, R., Model Management in Electronic Markets for Decision Technologies: A Software Agent Approach, Proceedings, 30th Hawaii International Conference on System Sciences, IEEE Computer Society Press, January 1997. Bischop, J. and Meeraus A., On the Development of a General Algebraic Modeling System in Strategic Planning Environment, Mathematical Programming Study, Vol. 20, pp. 1-29. Conklin, J, and Begeman, M., gIBIS: A Hypertext Tool for Exploratory Policy Discussion, ACM Transactions on Office Information Systems, Vol. 6, No. 4, pp. 303-331, October 1988. Dhar, V., Jarke, M., Conceptual Modeling and Change Propagation, in Information Systems and Decision Process, Stohr, E., and Konsynski, B., eds., IEEE Computer Society Press, Los Alamitos, CA, 1992, pp. 217-230. Fourer, R., A Mathematical Programming Language, Management Science, Vol. 36, No. 5, pp. 519-554. Geoffrion, A.M., An Introduction to Structured Modeling, Management Science, Vol. 33, No. 5, pp. 547-588, May 1987. Isakowitz, T., Shocken, S., and Lucas, H., Toward a Logical/Physical Theory of Spreadsheet Modeling. ACM Transactions on Office Information Systems, Vol. 13, No. 1, pp. 1-37, January 1995. Jones, C., Attributed Graphs, Graph-Grammars, and Structured Modeling, Annals of Operations Research, Vol. 38, pp. 281-324, 1992. Krishnan, R., Model Management: Survey, Future Directions and a Bibliography, ORSA CSTS Newsletter, Vol. 14, No. 1, pp. 7-16, Spring 1993. Kulatilaka, N., Balasubramanian, P., and Storck, J,. Managing Information Technology Investments: A Capability-based Real Options

1060-3425/98 $10.00 (c) 1998 IEEE

14.

15.

16.

17.

Approach, Boston University, Working Paper #96-35, June 1996. Kwan, M., and P Balasubramanian. Dynamic Workflow Management: A Framework for Modeling Workflows, Proceedings, 30th Hawaii International Conference on System Sciences, IEEE Computer Society Press, Vol. 4, pp. 367376, January 1997. Lenard, M., Fundamentals of Structured Modeling, in G. Mitra (ed.), Mathematical Models for Decision Support, Springer-Verlag, Berlin, pp. 695-713, 1988. Mannino, M., Greenberg, B., and Sa Neung Hong, Model Libraries: Knowledge Representation and Reasoning, ORSA Journal on Computing, Vol. 2, No. 3, pp. 287-301, Summer 1990. Medina-Mora, R., Winograd, T., Flores, R., and Flores, F., . The action workflow approach to workflow management technology. Proceedings,

18. 19.

20.

21.

22.

23.

4th Conference on CSCW. ACM, New York, pp. 281-297, 1992. Plane, R., How to Build Spreadsheet Models, OR/MS Today, February 1997, pp. 50-54. Singh, B. and G.L. Rein. Role Interaction Nets: a process description formalism. MCC Tech. Report CT-083-92. 1992. Ronen, B., Palley, M.A., and Lucas, H.C., Spreadsheet Analysis and Design, Communications of the ACM, Vol. 32, No. 1, pp. 84-93. Sprague, R.H. and Carlson, E.D., Building Effective Decision Support Systems. Chapter 2, Prentice-Hall, Englewood Cliffs, NJ, 1982. Savage, S., Weighing the PROS and CONS of Decision Technology in Spreadsheets. OR/MS Today, pp. 42-45, February 1997. Stohr, E.A and Konsynski, B.R., Information Systems and Decision Processes. Chapter 2, IEEE Computer Press, CA, 1992.

1060-3425/98 $10.00 (c) 1998 IEEE