memo: a tool supported methodology for analyzing and (re ... · of corporate strategies and...

1

Abstract

The paper presents a conceptual framework as wellas a design environment to develop object-orientedenterprise models. It helps to coordinate the designof a business information system with the modellingof corporate strategies and organizational (re-) de-sign. For this purpose the framework introducesconcepts for illustratively modelling and integratingthree main views on the enterprise. The views focuson corporate strategy, business (process) organizati-on, and information system design. Thereby the me-thodology contributes to overcome the communica-tion barriers that commonly exist between the diffe-rent views. The integration of the various stages ofsystem development is promoted by linking con-cepts of different views. Since business informationsystems are usually not built from scratch the metho-dology provides means for integrating existing soft-ware or data structures. The development environ-ment that is based on the framework allows the userto navigate through the views of an enterprise modelon various levels of detail. It maintains a model’s in-tegrity and allows for simulation and fast prototy-ping.

1 The Need for Models of the Enterprise

Designing, implementing and maintaining businessinformation systems faces a number of challenges.On the software level it is - among others - desirableto support integration on a high level of semantics,to foster integrity and to allow for convenient reuseof existing artifacts. Penetrating a company with

information technology allows for or may requirenew ways to organize the business. During the lastyears different aspects of this problem have beenaddressed by a variety of approaches. They arerelated to notions like “paperless office”, “leanmanagement” or “business (process) re-engineer-ing” ([Hammer 93], [Talwar 93]). Reorganizing afirm or parts of it should be compatible with its longterm goals. On the other hand the range of strategicoptions is more or less influenced by the availableinformation technology - no matter whether youregard it as a “strategic weapon” ([Porter/Millar85], [Wiseman 85]) or as a constraint.

The various approaches to deal with those differentchallenges usually have one characteristic in com-mon: they are based on models - either of the wholeenterprise or of parts of it. It has been well acceptedfor long that conceptual models are crucial fordesigning and implementing integrated informationsystems. While those models used to be data-ori-ented, object-oriented design methodologies arecurrently gaining more and more attention. Method-ologies to support the analyst with business re-engi-neering are usually based on models as well. Theyare mainly focused on business processes ([Daven-port 90], [Dennis 94]). Furthermore there is a widerange of models to help with analyzing and shapinga firm’s strategy. They usually stress a moreabstract view with highly aggregated data (for anoverview see [Hassey 92] and [Scott Morton 86]).[Keen 91] explicitly promotes the use of informa-tion technology to develop corporate strategies. Allthese models have been introduced to reduce thecomplexity of strategic planning in order to help theanalyst to concentrate on the essentials - and tocommunicate them to others who should beinvolved.

It is no surprise that strategic, organizational andinformation system models are usually based on

MEMO: A Tool Supported Methodology for Analyzing and (Re-) Designing Business Information Systems

Ulrich FrankInstitut für Wirtschaftsinformatik, Universität Koblenz

Rheinau 1, 56075 Koblenz, GermanyEmail: [email protected]

Published in: Ege, R.; Singh, M.; Meyer, B. (Eds.): Technology of Object-Oriented Languages ans Sys-tems. Englewood Cliffs 1994, S. 367-380

2

different concepts. However, treating these differ-ent aspects independently bares the risk of redun-dant work and friction - a well known phenomenonfor long. In order to allow for a more synergeticapproach a number of authors ([Zachman 87],[ESPRIT 91], [Katz 90], [Sowa 92], [Peters 93])have suggested enriched modelling frameworks -often named “enterprise modelling” (a term whichis however not used in a unique way). Such method-ologies differentiate between a number of views onthe enterprise and intend to capture the relationshipsbetween these views. Studying them howevershows that they either remain on a rather abstractlevel (for instance: [Sowa 92], [Zachman 87]) orlack sophisticated concepts - both from a manage-rial and a software engineering point of view (theyare usually rather data- than object-oriented).

This paper presents a methodology as well as a setof integrated tools for developing object-orientedenterprise models that cover the main aspects ofanalyzing, designing, implementing and maintain-ing business information systems. It puts specialemphasis on the following aspects:

• Different ways to conceptualize an enterprise inan illustrative way, called perspectives or views,are supported.

• An object-oriented design methodology that isspecially suited for modelling business informa-tion systems.

• Concepts to support the integration of existingcomponents, like applications or data structures,are provided.

• A systematic approach to analyze a firm’s com-petitive position and to generate strategicoptions is included.

• There is support for (re-) designing informationintensive business processes.

• An enterprise model can be very complex. How-ever, for economic reasons there may be theneed to be less ambitious - both in extent anddetail. Therefore the methodology can beadapted to the constraints of a specific project.

• The development environment provides variousways of browsing through an enterprise modeland maintaining its integrity. It also allows forfast prototyping and simulation.

2 Multi Purpose Enterprise Modelling

Inspired by the vision of highly integrated businessinformation systems and additionally motivated by

the various problems with existing systems a groupof researchers at GMD started in 1990 to developscenarios of how to deal with this complex chal-lenge. Very soon it became obvious that it was akey issue to design multi-view models of the enter-prise - mainly inspired by the framework presentedin [Zachman 87]. We decided on three main views.The strategic view was to model the enterprise in away that fits the perception common to senior exec-utives. It should allow for illustratively describing afirm’s competitive position and its strategic options.The organizational view was to be focussed on acompany’s organizational structure and the way itstasks/processes are performed. The information sys-tem view should provide the basic modelling con-structs (in other words: the meta model for model-ling) together with a framework to analyze existingsystems and (re-) design and maintain them.

The methodology that has been developed in thefollowing years - called Multi Purpose EnterpriseModelling (MEMO) - provides the analyst with var-ious concepts to describe each view. The conceptsare presented on different levels of detail and preci-sion: a conceptual framework, guidelines to developscenarios (mainly to describe tasks/processes), heu-ristics that help to identify important aspects, struc-tured questionnaires to guide interviewing, and tem-plates to gather formal aspects.

There are three dimensions to structure each of thethree main views. Stage serves to describe a particu-lar model’s position within the continuum betweenanalysis, design and maintenance. Each view isdescribed in terms of the required resources, theoperations or processes, the results which are pro-duced, and the relevant features of external systems.This dimension is called focus. Usually it is desir-able to model a view on a high level of abstraction.However, for certain types of analysis you mayneed to consider the state of instances. Within thisdimension, called aggregation, MEMO allows theanalyst to use concepts (like classes), particularinstances and so called prototypical instances whichrepresent the average state of a relevant set ofinstances (like the salary of the “average clerk”).

2.1 The Strategic View

A methodology to guide analysis and design of cor-porate strategies should be suited to represent therequired concepts in a way that is familiar to thosewho are commonly dealing with strategic planning -like senior executives. It should be based on gener-alized assumptions and should also allow to be con-

3

figured/specialized to a particular firm’s needs.Among the wide range of methodologies (see [ScottMorton 86]) we found Porter’s value chainapproach to be most appropriate. Due to the com-plexity and contingency of the domain the method-ology does not offer a precise guideline for devel-oping strategies. However, Porter’s approach pro-vides the analyst with familiar concepts which sup-port him to develop a solution of his problem in asystematic way. The value chain concept has gaineda high degree of acceptance with many companiesand consultants.

On the top level Porter models an enterprise as asystem of “activities” which form a “value chain”."The value chain disaggregates a firm into its strate-gically relevant activities in order to understand thebehavior of costs and the existing and potentialsources of differentiation. A firm gains competitiveadvantage by performing these strategically impor-tant activities more cheaply or better than its com-petitors." ([Porter 85], p. 33) Primary activities aredirectly involved in the process to produce the prod-ucts or services that are offered to a firm’s custom-ers. They include inbound logistics, operations, out-bound logistics, marketing and sales and service.Support activities (firm infrastructure, humanresource management, technology development andprocurement) serve to support primary activities.An activity is an abstraction of actual business pro-

cesses. Therefore it does not have to directly corre-spond to a specific process (for a detailed descrip-tion see [Porter 85]).

In order to adapt Porter’s approach to the MEMOframework we applied the three dimensions stage,focus and abstraction to it. There are two outstand-ing stages - with an arbitrary number of intermedi-ate stages: the current competitive position and theposition aimed at with the future strategy.Resources - like various types of capital or humanresource - are used to perform activities. They aredescribed on a high level of aggregation withemphasis on cost and quality issues. The outcomewhich is produced by an activity is modelled on asimilar level - with aggregated figures for qualityand price. Processes are basically described as achain of activities with each activity characterizedby the resources it consumes and its outcome. Thisresults in a value chain being modelled as a graph ofactivities, resources, and outcomes with specialemphasis on the interrelationships.

The relevant external world consists of more or lessdetailed value chains of competitors, suppliers andcustomers. In order to support the shaping of afirm’s value chain the analyst is provided with heu-ristics like “How can the activity be performed dif-ferently or even eliminated?” or “How can a groupof linked value activities be reordered orregrouped?” ([Porter 85], p. 110).

accountantsmanagement clerks programmerssales personal

capital technologyhuman resources

social skillstechnical knowl- goal orientation experiencecost awareness

lowaverage

high

inbound logistics operations outbound logistics

Figure 1. An example for the analysis of resources within the strategic view

4

Additionally Porter offers a top down approach thatsuggests to start with one out of a list of “genericstrategies” and stepwise specialize it into a newvalue chain.

It is obvious that both analyzing and designing avalue chain require special attention to the interrela-tionships, which Porter calls “linkages” ([Porter85], p. 50): "Managing linkages thus is a more com-plex organizational task than managing value activ-ities in themselves." While the methodology cer-tainly does not allow for automatically generating a

firm’s value chain, it can well be mapped to a spe-cialized browser (see 3). The concepts used todescribe the strategic view are represented in anobject-oriented way according to the meta modelcharacterized in 2.3.

2.2 The Organizational View

On the organizational level an enterprise modelcomprises a model of the organizational structureand models of business processes - both for analyz-ing the given state and for designing future states.

Organizational Context

Department, Team, Position

Figure 2. Conceptualization of business processes

Control

Decision rules, Exceptions,Execution Times

States

of Objects, Forms and Files

Information

Objects, Services, Forms,Fields, Files

Communication

Locations, Actors, Channels,Frequency, Duration

State of the virtual

Activity

procedure document

Process Types

5

The organizational structure is represented by orga-nizational units (such as divisions, departments,groups, positions etc.) and their relationships(“reports to”, “is part of” etc.). In addition to model-ling a particular structure MEMO encourages theanalyst to identify general rules for the division oflabor and its coordination. Organizational resourcesare usually modelled as prototypical instances.Examples for resources on this level are people,buildings, furniture, machinery etc. Computer hard-ware may also be considered as resource within theorganizational view. It is described by referring tothe information system view (see below). Featureswhich may be described within prototypicalinstances include various types of cost, availability,capacity etc. The number of resources and the detailof their description is subject to individual configu-ration. The external world is represented by relevantroles (like lawyer, consultant, customer, etc.) andservices.

A business process is modelled as an ordered graphof subprocesses, where a subprocess in itself can bedecomposed into other subprocesses. MEMO’semphasis is on office procedures. Therefore the“material” that is operated on is information. Infor-mation is grouped into three categories: objectswhich reside on the computer based informationsystem, forms, and files. Information that is locatedin the information system is described by referringto the object model that is part of the informationsystem view (see below). Forms have a formalstructure, that is they contain fields, have welldefined states (like ’complete’, ’incomplete’, ’con-sistent’), and a set of constraints defines the permis-sible operations. Their content may be changedwithin a subprocess. The term file is used to sum-marize documented information that is read-only -like office files, letters or journals. The informationa business process operates on is gathered in a “vir-tual procedure document” that extends the tradi-tional notion of a document in two respects: It maycontain references to information that is locatedsomewhere else. Furthermore it can be duplicatedand thereby processed in parallel. Each subprocessis triggered by a certain state of the virtual proce-dure document and produces one or more newstates.

Each process is assigned an organizational contextby referring to the organizational units which areresponsible for its execution. By default the organi-zational context is propagated to the subprocesseswhere it may be overwritten. Furthermore each pro-

cess can be characterized by business rules like:“All subprocesses should be managed by the sameperson.” The subprocesses can be described in avery detailed way - depending on the effort that is tobe spent for analysis. Among the more importantfeatures are: minimum and maximum executiontime, decision rules, required resources (forinstance: copy machine, printer), exceptions, people(roles) needed to communicate with, communica-tion media etc. In order to support the re-design ofbusiness processes MEMO provides the analystwith means to analyze existing processes anddesign heuristics. The model of a business processallows the analyst to detect media frictions (forinstance: information that originally resides in theinformation system and is then being transferred toa form), to identify bottlenecks, or to draw commu-nication nets. By adding statistical data on work-load, capacity and probabilities of the subprocesses’possible outcome the model can be utilized to per-form simulations (see fig. 8).

By focussing on processes the organizational modelserves different purposes: It helps to redesign thebusiness (if necessary), it helps to define the com-munication technology required to improve effi-ciency, and - last but not least - it supports to iden-tify the objects/classes required to perform the rele-vant tasks. As with the strategic view the conceptsof the organizational view are described with theobject-oriented meta model (see below) in mind.Therefore they can be represented as an objectmodel which fosters their mapping on a tool.

2.3 The Information System View

The information system view includes both a modelof the existing system and the system that is to bedesigned. They are separated into an object-orientedconceptual model and a model of information sys-tem resources (like hardware, networks, operatingsystems). An object-oriented conceptual modelincludes an object model and other models toexpress dynamic aspects. Among the still increasingnumber of object-oriented design methodologies (ina survey we did last year we found more than fortyapproaches) we felt most inspired by the ones pro-posed by [Booch 90], [Rumbaugh et al. 90], and[Jacobson et al. 92]. However, none of them wassatisfactory for our purpose. While Rumbaugh etal.’ methodology suffers from being somewhatsuperficial and not consequently object-oriented,Booch’s approach seems to be overloaded bydetails of various programming languages - which,

6

in our opinion, should not be part of a general meth-odology for the design of conceptual models.Jacobson et al. are primarily focussing on analysisand put less emphasis on software engineeringissues occurring during design. (for a comparison ofimportant methodologies see [Frank 93], [Hong93], [Monarchi 92]). Furthermore we were not sat-isfied with the way dynamic aspects are modelledwithin these approaches. State transition diagramsare often suggested to capture dynamic aspects. Atfirst sight such diagrams seem to be appropriate formodelling automated business processes, since theyallow the analyst to describe events and correspond-ing state changes. They are however restricted toevents and state transitions which may occur duringthe lifetime of objects of one class. Within an officeprocedure however one usually needs objects ofmore than one class.

2.3.1 Conceptualizing Object Models

While from a (re-)using programmer´s point ofview it is sufficient to describe an object solely bythe services it provides analysis and design requirea more detailed view. Within an object model onedefines classes and associations between classes orbetween objects respectively. Like in most othermethodologies the outstanding features of a classare attributes and services. An attribute is regardedas an object that is encapsulated within an object.We do not allow attributes - like [Coad 91] - to onlyhold references to external objects that have anexistence of there own in the object space. Anattributes semantics is primarily defined by its class.Furthermore a cardinality (using min-max notation)may be assigned. Assigning a default value allowsfor generating appropriate initialization operations.

Class

Name

Superclass

Comment

Value Set

Attribute

Service

Association

Trigger

Guard

State

Name

Comment

Parameter

Output

Precondition

Postcondition

Exception

Access-Priv.

Label

Name

InverseName

Type

Inverse-Type

Class

Cardinality

Name

Comment

Class

Cardinality

Default-Value

Access-Priv.

History

Label

Name

Invariant

Name

Event-Action

0,1

0,1

0,1

0,*

0,*

0,*

0,*

0,*

1,1

1,1

1,1

0,1

1,1

1,1

0,1

1,1

1,1

0,1

1,1

0,1

0,*

0,1

0,1

0,1

0,*

1,1

0,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

Figure 3. Part of the meta model for conceptualizing object models

Default View0,*

7

Each attribute is also characterized by a history-flag. Setting it to true means that every updateshould be recorded somehow.

In order to allow for generating prototypical user-interfaces it is possible to assign a default-view toeach class. A default view is either a widget or acollection of widgets. One can also define a labelthat is to be presented with the default view. Addi-tionally features like size and font may be specified.This approach is a first attempt to deal with thecomplexity of user interaction. It cannot be com-pletely satisfactory: the way a value of a certainclass is presented to the user often is not unique butvaries with the context of interaction.

In order to specify a service the designer maydescribe a list of input-parameters (which can beempty) where each parameter is characterized by itsclass and its name. If a service returns a result it has

to be exactly one object. So it is sufficient to definethe class of this object. It is important to note thatsuch an object may be a composed object (like anarray, a container etc.) that contains many otherobjects. A precondition in general specifies condi-tions "under which a routine will function properly"([Meyer 88], p. 114). In our model it can be definedby referring to object or parameter states. Forinstance: For a service that requires an object ofclass ’Person’ as a parameter it may be necessarythat the service ’sex’ delivers the state ’male’.

A postcondition has to be fulfilled after the servicehas terminated. Similar to a precondition it can bedefined by referring to an object state or to a state ofthe object that is returned by the service. Each ser-vice can be assigned a set of exceptions (like mediaerrors) which should be named in a unified way fora whole object model. Thereby exception handlingcan be defined for all involved objects in the sameway.

During the life time of an object there may be cer-tain events and rules which go beyond the scope ofa single service. For this purpose we introduce trig-gers and guards. A trigger can be generally definedas a tupel consisting of an event and an action. Theevent is specified by a condition that in turn isdefined by referring to attribute states or states ofobjects which are returned by a service. The actionis defined by the service that has to be executedwhen the event occurs.

ProcedureSupervisor

RiskEvalua-

InsuranceSupervisor

Manager

Employee

Clerk

Object ModelRepository

uses

controls

Figure 4. Integration of object model and office procedure models within an enterprise-wide repository

ProcedureManager

ProcessModels

ClaimsProcessing-

To give an example for a trigger: Whenever anobject of class ’customerAccount’ has a balanceless than x, the object should execute a service thatis suited to notify somebody who is managing theaccount. A guard is a condition that has to be ful-filled during the lifetime of any object of a particu-lar class (similar to what [Meyer 88], p. 124) calls"class invariant"). For instance: The value ofattribute ’retailPrice’ within objects of class ’Prod-uct’ should never be lower than the value ofattribute ’wholesalePrice’.

8

Every class may have exactly one superclass.Although there are a number of arguments in favorof multiple inheritance we restricted our model tosingle inheritance. We found that in most cases sin-gle inheritance is satisfactory while multiple inher-itance increases the complexity of an object modeland thereby makes it more difficult to maintain it ina consistent way. On the instance level MEMO dis-tinguishes between two types of associations: inter-action and aggregation. However, for a conceptualobject model to be illustrative it is desirable toallow for a more detailed differentiation. For thisreason each association has to be assigned a domainlevel identifier. Such identifiers do not include anysemantics, they only improve readability of themodel and allow for enhanced retrieval capabilities.

In order to allow for smoothly integrating existingelements - like applications or data structures -MEMO suggests that the modeller regards them asobjects. Application classes are subclasses of theclass “Application” that provides attributes and ser-vices to manage information like installation date,version, cost etc. An application class is usuallymodelled by the set of services it offers to the out-side (which is rather poor for the average legacyapplication) and details about the communicationprotocol (for instance: OS-call, RPC, UDP orCORBA). Existing data structures, such as relationtypes of an RDBMS or a document file of a wordprocessor, are represented as dummy classes: Theydo not encapsulate any attributes, instead they offerservices that allow to access an existing element.For instance: class ‘WordDocument’ representsdocuments produced by a certain word processor. Inorder to integrate them with a more sophisticatedmodel one can use an association with the reservedname “corresponds to”. For instance: “RelTypeCus-tomer corresponds to Customer” or “WordDocu-ment corresponds to CompoundDocument”. Someexisting applications use data that might be sharedwith other objects. Whenever such a potentialsource of redundancy is discovered it can beexpressed in the model using an association withthe reserved name: “should use”. For instance:“AccountingSystem should use Customer”. Toavoid confusion about the implementation state of amodel it is important to assign one of four pre-defined states to each class: “not implemented”,“implemented”, “dummy”, “encapsulated”. Fig. 3gives an overview of the concepts proposed fordesigning object models. For a more comprehensivedocumentation see [Frank 92], [Frank 94].

2.3.2 Modelling dynamic aspects

A methodology for modelling dynamic behaviorshould allow for conveniently expressing temporaland control (in other words: dynamic) aspects. Itshould also help to avoid inconsistencies, like nonterminating cycles, tasks which cannot be reachedby any chance, deadlocks, etc. Unlike the object-oriented methodologies mentioned above Petersand Schultz [Peters 93] propose a modelling tech-nique that allows for including objects of more thanone class. They use Petri nets where each transitionrepresents a state transition of an object of a particu-lar class. Different transitions within a net may rep-resent objects of different classes. Furthermore theyallow - different from traditional concepts - transi-tions to have an execution time larger than zero.Mapping transitions to operations of an object of acertain class is attractive from a software-engineer-ing point of view since it supports the idea of build-ing procedures by ’glueing’ objects together (as it isproposed in [Nierstrasz 90]). Nevertheless such anapproach has its deficiencies, too. It is important fora model to allow for direct correspondence to famil-iar conceptualizations of the relevant domain. Busi-ness processes are not necessarily structured in away that there is always only one object operated onwithin a subtask.

The approach we have chosen is similar to the onesuggested by Peters and Schultz in that we also usesemantically enriched Petri nets and allow transi-tions to have an execution time larger than zero.Our methodology however allows to explicitlyassign objects of many different classes to one tran-sition. The information system model of a process isvery similar to the model of a business processwithin the organizational level - and in fact may bededucted from it. The main difference: On the infor-mation system level a process is described only byits automated parts. That implies tighter constraintson the specification of the information being pro-cessed: only information that is represented in theobject model can be regarded.

In order to provide the model with prototypingcapabilities it is necessary to enhance it with infor-mation about a suitable user-interface. This infor-mation can be deducted from those servicesassigned to a subtask. The widgets needed to inter-act with the services can be looked up in the objectmodel (see above). Since every suitable class in theobject model should have a default view assigned toit, a prototypical user-interface for an activity canbe generated.

9

level of aggregation level of formalization

Resources Operations Results/ External System

Strategy

Organization

Information System

longterm

competitive

competitors

customers

suppliers

primary/supporthumancapital

technologyedge

profits/losses

peoplemachinery

tasksbusiness

customerssupplierspartners

productivitymotivation

qualitycostprocesses

services

processeshardwarenetworks

OSObjects

standards

customerssuppliers

productivityreliability

maintainabilityintegrity

Figure 5. Selected concepts of different views and foci

Success Factors

activities

Procedure models are integrated with an objectmodel in two ways. First they refer to the objectsthey use, second the management of an office pro-cedure is done by objects that are specified withinthe object model themselves. Fig. 4 shows how anobject model and office procedure models could berepresented within an enterprise-wide repository.

2.4 Integrating the Views

While it might be an intriguing vision to deduct themodel of the information system from the organiza-tional model and the organizational model from thestrategic model, we did not even try to accomplishsuch a level of integration. This is mainly for tworeasons. First: there is hardly general knowledge ofhow to deduct the organizational concept bestsuited to accomplish a strategic goal (which is alsothe case for the relationship between organizationalmodel and information system model). Second:usually a strategy cannot be developed indepen-dently from organizational options which in turn areinfluenced by information technology as well. Forthose reasons MEMO allows one to explicitly linkconcepts on different levels. Direct tight coupling isthe case, if a concept of a certain view directly cor-

responds to a concept of another view. For instance:The concept “Customer” within the organizationalview corresponds to the class “Customer” withinthe information system view - although the repre-sentations may vary in detail.

The other extreme would be indirect weak coupling.For instance: The goal “customer satisfaction” onthe strategic level could be first linked to a model ofthe firm’s order processing on the organizationallevel. From there one could establish a link toobjects within the information system view thatprovide services compatible with certain EDI-stan-dards.

3 MEMO-Center: The Design Environment

Designing enterprise models according to the pro-posed methodology can hardly be accomplishedwithout appropriate tools: A complex modelrequires support for browsing and searching.Because of multiple integrity constraints mainte-nance that is solely done manually jeopardizes amodel’s consistency to an unacceptable extent.Finally it is impossible to do without tools whenprototyping is to be accomplished. For these rea-sons we developed an environment based on the

10

MEMO framework. It was implemented usingSmalltalk-80 within the Objectworks® 4.0 environ-ment on Sun4-workstations. High productivitycould be achieved by using additional class libraries(see [Frank 92] for more details). The current ver-sion runs under Objectworks® 4.1 and Visual-Works® - on all platforms the appropriate ParcPlace Smalltalk machine is available for.

The environment consists of three main tools: TheValue Chain Designer (VCD) serves to design andanalyze models of a firm’s value chain. The ObjectModel Designer (OMD) supports the specificationof object models. It provides various features tosearch for certain elements of an object model andto browse through the model. The WorkflowDesigner (WFD) allows for conveniently modellingbusiness processes. It provides functions for simula-tion, fast prototyping and organizational analysis.The three tools are tightly integrated. The integra-tion on the conceptual level has already been char-acterized above. System integration is accom-

plished by locating the tools within one Smalltalkimage. The concepts managed by the tools can beannotated by using an integrated hypertext system.

The VCD provides a browser through the differentelements of a value chain. The description of proto-typical instances (like “human resource”) is sup-ported by predefined value sets (like “high”, “aver-age”, “low”) which can be modified interactively.This is the case, too, for relationships betweenactivities. They can be characterized using an exten-sible list of identifiers (like “supports”, “supportedby”, “contains”, etc.). In addition to a textual repre-sentation relationships can be visualized in a graph-ical way. Items managed within the VCD can beassociated to related items within the other tools.For instance: ”activity uses business process”. TheVCD controls referential integrity of a value chain.Furthermore it provides dialogs to guide with ana-lyzing and re-designing a value chain.

Figure 6. User-interface of the Object Model Designer

11

According to the meta model described above theOMD offers a number of different levels of abstrac-tion. On the highest level class names are groupedinto categories. On the next level a class can beassigned a list of attribute names, service names,guard names, and trigger names. Selecting anattribute, service, etc. causes the correspondingwindow to pop to the front. It allows for a moredetailed description. Fig. 6 shows the window thatcontains the template for specifying an attribute -’dateOfBirth’ in the given example. Its class is’Date’. The services which are provided by thisclass are shown in a listbox. If one of these servicesis needed for the class that is currently selected(which is ’InsuredPerson’ in our example) it can bepasted to the services-listbox of this class - a conve-nient way to accomplish reusability. The OMD willthen establish a reference to this service.

In order to foster system integrity it is not possibleto type in a class name directly to characterize anattribute, a superclass, or a parameter. Instead it isrequired that the dictionary that contains all classnames is updated first. Then the name can be pastedto the corresponding field. The OMD controls anumber of integrity constraints. It prevents the user

from deleting elements which are referenced byother elements, from assigning superclasses orclasses of attributes in an inconsistent way, etc. Thegraphical representation of the class hierarchy canbe used as an additional browser. The icons aremouse sensitive and cause the focus to shift to theselected class.

The main focus of the WFD is on business pro-cesses - both for analysis (that is mainly the organi-zational view) and design (organizational and infor-mation system view). On the highest level ofabstraction the user can draw a business processpicking from predefined icons within a specializededitor. When the procedure is described on thislevel (see fig. 7), the user can ’zoom’ into it byselecting an icon - either a subtask or a documentstate. Within the example shown in fig. 7 the sub-task ’Verification of substantial matter’ is selected.Within the window titled ’Activity’ it can be char-acterized by assigning execution times, an organiza-tional unit, an organizational position, and possibleexceptions. Furthermore the classes (like ’Insured-Person’, ’Policy’, etc.), forms, and files which areneeded as well as the involved roles can be listed inthis window.

Figure 7. User-interface of the Workflow Designer

12

Selecting an item causes a window with an appro-priate template to pop to the front. Within the exam-ple shown in fig. 7 this is the window in top rightposition. It allows to pick the required services fromthe selected class. For each service - or the object itdelivers respectively - it can be specified what it isneeded for: either for a form or for communicatingwith an involved person. The example shows thatthe service ’profession’ is needed for the ’Applica-tionForm’ as well as for communicating with the’InsuredPerson’ and the ’Expert’.

Other templates exist to specify the relevant infor-mation within forms (fields together with an infor-mal description of their purpose) or files (physicallocation, subject of interest within the file) and aswell as the communication with involved persons(channel, subject). These specifications are used togenerate a protocol which is shown in the right bot-tom corner of the ’Activity’ window in fig. 7.Another text-widget within this window presents atemplate that can be filled to describe decision rulesrelevant for the focussed activity. A selected docu-ment state is specified in a similar way. First theclasses, forms, and files which are involved in thisstate are assigned to it. Then these items have to becharacterized in a more detailed way. The state ofan object (which is represented by the name of itsclass) has to be defined by naming a boolean ser-vice that checks this state. That requires one to

enhance the class with this service by switching tothe OMD. For instance: An object of class ’Policy’is required to be in state ’valid’. That requires a ser-vice like ’isValid’ to be specified for this class. Forevery form it has to be defined which fields have tobe filled in. A file is characterized by its physicallocation and optionally the means of transportationto get it to the clerk. In order to support the user andto avoid inconsistencies the classes, forms and filesassigned to a document state are pasted to the sub-task that is triggered by this state. The WFD cangenerate a prototypical user-interface for everyactivity - provided the default views have beenassigned to the corresponding classes in the objectmodel (see above). The widgets placed within suchan interface may be rearranged interactively. Inorder to use the simulation features built into theWFD it is necessary to first assign probabilities(using percentage values) to the states produced byevery subtask. Furthermore it is required to type inthe workload as number of procedures in a timeperiod. After that the simulation can be started. Ani-mation is accomplished by dynamically markingthe subtasks which are active. If the simulationreveals any chances to improve the organization ofthe procedure the net can be rearranged interac-tively. Fig. 8 shows a snapshot of a simulationwhere the subtask ’Verification of substantial mat-ter’ has been expanded since it was found to be abottleneck.

Figure 8. Snapshot of an animated simulation

13

VCD

WFD

VCD

OMD

Analysis of competitive position and design of corporate strategy

WFD OMD

WFD OMD

WFD OMD

Tool Stage

WFD OMD

Figure 9. The usage of MEMO Center during important development stages (this is a simplified model!) and selected feedbacks between stages.

Identification and modelling of business processes

Identification and modelling of objects used withinthe business processes

Design of an object model - including the integration of existing components

Analysis and re-design of business processes.Eventually refinement of strategy and object model

Providing prototypes, feedback from experts/users

The WFD also allows for generating a report ondetected media frictions and to graphically visualizecommunication relationships. Fig. 9 shows whichtools are primarily used in the various stages ofenterprise modelling.

4 Conclusions

Different from most other methodologies forobject-oriented analysis and design MEMO notonly focuses on the information system in itself butalso on relevant strategic and organizational issues.Thereby it fosters a smooth integration of an infor-mation system with business processes and corpo-rate strategies. Our experience with modellingoffice domains within insurance companies indi-cates that the proposed representations offer illus-trative abstractions of an enterprise. This is espe-cially the case for the representation of businessprocesses. Both system analysts and domain expertsintuitively understood the graphical notation.

Thereby it proved to be a valuable medium for start-ing knowledge acquisition or object modellingrespectively. We found that asking about strategiesand processes is not only a prerequisite for organi-zational change. It furthermore helps to identifyobjects and specify their semantics. MEMO does -of course - not guarantee to optimize the organiza-tion of work. It can help however to reduce com-plexity by providing an illustrative representation ofimportant aspects, by detecting certain types oforganizational misconception, and - last but notleast - promoting a sophisticated object-orientedarchitecture of a company’s information system.

In the current version MEMO Center is restricted toone Smalltalk image. Therefore the prototypicalworkflow systems only simulate distribution. Theobjects used within the prototypes are either imple-mented directly in Smalltalk or refer to C-functionswhich are linked with the virtual machine. Cur-rently we are working on extensions that will allow

14

for partial generation of distributed workflow man-agement systems. For this purpose we use HP’s“Distributed Smalltalk”. It includes a CORBAimplementation according to the OMG guidelines.MEMO Center will then allow for integrating anyexisting component that offers an IDL-interface. Inorder to allow for an automatic transformation of anobject model designed according to MEMO into theOMG object model MEMO Center will beenhanced with means to distinguish between inher-itance and subtyping. A text book with a compre-hensive documentation of the methodology and theenvironment will be published by the end of 1994.

References

Booch, G.: Object-oriented design with applica-tions. Redwood 1990Coad, P.; Yourdon, E.: Object Oriented Design. En-glewood Cliffs, NJ 1991Davenport, T.; Short, J.E.: The New Industrial En-gineering: Information Technology and BusinessProcess Redesign. In: Sloan Management Review,Summer 1990, pp. 11-27Dennis, A.R.; Hayes, G.S.; Daniels, R.M.: Re-Engi-neering Business Process Modeling. In: Nunamaker,J.F.; Sprague, R.H. (Ed.): Proceedings of the 27thHawaii International Conference on System Scienc-es, Vol. IV. Los Alamitos, Ca. 1994, pp. 245-253ESPRIT Consortium AMICE: CIM-OSA AD 1.0Architecture Description. Brussels 1991Frank, U.; Klein, S.: Three integrated tools for de-signing and prototyping object-oriented enterprisemodels. GMD Research Report No. 689, Sankt Au-gustin 1992Frank, U.: A Comparison of two Outstanding Meth-odologies for Object-Oriented Design. GMD Re-search Report No. 779, Sankt Augustin 1993Frank, U.: An Object-Oriented Methodology forAnalyzing, Designing and Prototyping Office Pro-cedures. In: Nunamaker, J.F.; Sprague, R.H. (Ed.):Proceedings of the 27th Hawaii International Con-ference on System Sciences, Vol. IV. Los Alamitos,Ca. 1994, pp. 663-672Hammer, M.; Champy, J.: Reengineering the Cor-poration. New York 1993Hassey, D.E.: Glossary of Management Tech-niques. In: International Review of Strategic Man-agement. Vol. 3, 1992, pp. 47-75Hong, S.; Goor, G.: A Formal Approach to theComparison of Object-Oriented Analysis and De-

sign Methodologies. In: Nunamaker, J.F.; Sprague,R.H. (Ed.): Proceedings of the 26th InternationalHawaii International Conferenc on System Scienc-es, Vol. III., Los Alamitos 1993, pp. 689-698Jacobson, I.; Christerson, M; Jonsson, P; Overgaard,G.: Object-Oriented Engineering. A Use CaseDriven Approach. Reading, Mass. 1992Katz, R.L.: Business/enterprise modelling. In: IBMSystems Journal, Vol. 29, No. 4, 1990, pp. 509-525Keen, P.G.W.: Shaping the Future: Business Designthrough Information Technology. Cambridge 1991Meyer, B.: Object-Oriented Software Construction.Prentice Hall 1988Monarchi, D.E.; Puhr, G.: A Research Typology forObject-Oriented Analysis and Design. In: Commu-nications of the ACM, Vol. 35, No. 9, 1992, pp. 35-47Nierstrasz, O.; Dami, L.; De Mey, V.; Stadelmann,M.; Tsichritzis, D.; Vitek, J.: Visual Scripting: To-wards Interactive Construction of Object-Oriented.In: Tsichritzis, D. C. (Hg.): Object Management.Geneva 1990, pp. 315-331Peters, L.; Schultz, R.: The Application of Petri-Netsin Object-Oriented Enterprise Simulations. In: Nu-namaker, J.F.; Sprague, R.H. (Ed.): Proceedings ofthe 26th International Hawaii International Confer-enc on System Sciences. Vol. III, Los Alamitos1993, pp. 390-398Porter, M.E.: Competitive Advantage. New York1985Porter, M.E.; Millar, V.E.: How Information GivesYou Competitive Advantage. In: Harvard BusinessReview, July/August 1985, pp. 149-160Rumbaugh et.al.: Object-Oriented Modelling andDesign. Hemel-Hempstead 1990Scott Morton, M.S.: Strategy formulation methodol-ogies. Cambridge, Mass. 1986Sowa, J.F.; Zachman, J.A.: Extending and formaliz-ing the framework for information systems architec-ture. In: IBM Systems Journal, Vol. 31, No. 3, 1992,pp. 590-616Talwar, R.: Business Re-engineering - a Strategy-driven approach. In: Long Range Planning, Vol. 26,No. 6, 1993, pp. 22-40Wiseman, C.: Strategy and Computers: InformationSystems as Competitive Weapons. Homewood, Ill.1985Zachman, J.A.: A framework for information sys-tems architecture. In: IBM Systems Journal, Vol. 26,No. 3, 1987, pp. 277-293

1

Abstract











2

















3









lowaverage

high



4









Control


States


Information


Communication



Activity

procedure document

Process Types

5








6




Class

Name

Superclass

Comment

Value Set

Attribute

Service

Association

Trigger

Guard

State

Name

Comment

Parameter

Output

Precondition

Postcondition

Exception

Access-Priv.

Label

Name

InverseName

Type

Inverse-Type

Class

Cardinality

Name

Comment

Class

Cardinality

Default-Value

Access-Priv.

History

Label

Name

Invariant

Name

Event-Action

0,1

0,1

0,1

0,*

0,*

0,*

0,*

0,*

1,1

1,1

1,1

0,1

1,1

1,1

0,1

1,1

1,1

0,1

1,1

0,1

0,*

0,1

0,1

0,1

0,*

1,1

0,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1


Default View0,*

7







ProcedureSupervisor

RiskEvalua-

InsuranceSupervisor

Manager

Employee

Clerk


uses

controls


ProcedureManager

ProcessModels

ClaimsProcessing-


8







9



Strategy

Organization

Information System

longterm

competitive

competitors

customers

suppliers


technologyedge

profits/losses

peoplemachinery

tasksbusiness




services


OSObjects

standards

customerssuppliers




Success Factors

activities








10






11






12





13

VCD

WFD

VCD

OMD


WFD OMD

WFD OMD

WFD OMD

Tool Stage

WFD OMD








4 Conclusions




14


References



1

Abstract











2

















3









lowaverage

high



4









Control


States


Information


Communication



Activity

procedure document

Process Types

5








6




Class

Name

Superclass

Comment

Value Set

Attribute

Service

Association

Trigger

Guard

State

Name

Comment

Parameter

Output

Precondition

Postcondition

Exception

Access-Priv.

Label

Name

InverseName

Type

Inverse-Type

Class

Cardinality

Name

Comment

Class

Cardinality

Default-Value

Access-Priv.

History

Label

Name

Invariant

Name

Event-Action

0,1

0,1

0,1

0,*

0,*

0,*

0,*

0,*

1,1

1,1

1,1

0,1

1,1

1,1

0,1

1,1

1,1

0,1

1,1

0,1

0,*

0,1

0,1

0,1

0,*

1,1

0,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1

1,1


Default View0,*

7







ProcedureSupervisor

RiskEvalua-

InsuranceSupervisor

Manager

Employee

Clerk


uses

controls


ProcedureManager

ProcessModels

ClaimsProcessing-


8







9



Strategy

Organization

Information System

longterm

competitive

competitors

customers

suppliers


technologyedge

profits/losses

peoplemachinery

tasksbusiness




services


OSObjects

standards

customerssuppliers




Success Factors

activities








10






11






12





13

VCD

WFD

VCD

OMD


WFD OMD

WFD OMD

WFD OMD

Tool Stage

WFD OMD








4 Conclusions




14


References



memo: a tool supported methodology for analyzing and (re ... · of corporate strategies and...

Documents