A Concept for an Internet-based Process-Oriented Knowledge Management Environment

Improving the efficiency of business processes results in a reduction of time needed to perform the task and of costs. This business objective leads to approaches as lean management and business process reengineering & optimization. In order to fulfill these objectives, workflow management approaches often are introduced in the enterprise (Georgakopolous, and Hornick, 1995). The workflow management coalition defines workflow management as:

„The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules." (Workflow Management Coalition, 1996).

Today, workflow management approaches are basically only used to support repetitive administrative tasks whereas knowledge-intensive tasks are not supported. There are several reasons for this:

• The knowledge needed for executing the process is not explicitly described in the workflow model.
• Current workflow approaches are not flexible enough to adapt on the fly to changing processes. Our work in the past years has been addressing this problem.

Although there were tremendous improvements in software engineering over the last decades, basic problems remain:

• software development is expensive and time consuming,
• software projects often run out of time and over budget,
• time and cost estimations are error prune.

• how to coordinate and manage the distributed work of the software engineers,
• how to provide access to a project’s knowledge,
• how to manage the experience gathered during past projects and make them usable for the new ones.

Understanding commonalties and differences between process types is a key factor for better process support. Process support includes improved communication, guiding people when performing processes, improving both processes and their results, and automating process steps (Rombach, and Verlage, 1995).

Software process modeling and enactment is one of the main areas in software engineering research. Several frameworks have been developed (e.g. procedural (Sutton, Osterweil, and Heimbigner, 1995], rule-based (Kaiser, Feiler, and Popovich, 1988; Tong, Kaiser, and Popovich, 1994; Peuschel, Schäfer, and Wolf, 1992], Petri net based (Bandinelli, Fuggetta, and Grigolli, 1993a], object-oriented (Conradi, Hagaseth, Larsen, Nguyen, Munch, Westby, Zhu, 1994)).

Process-sensitive software engineering environments which support evolution of executed process models (Conradi, Fernström, Fuggetta, 1993) are a focal point of current research, but the results are still immature (Madhavji, and Penedo, 1993). Several approaches to support the evolution and flexibility of software processes were developed (Bandinelli, Fuggetta, and Ghezzi, 1993b; Ben-Shaul, and Kaiser, 1993; Cugola, Di Nitto, Ghezzi, and Mantione, 1995; Pérez, Emam, and Madhavji, 1995). None of these approaches is supporting globally distributed software processes and their evolution (although work in this direction is starting (Kaiser, 1997; Conradi, 1997)).

Published approaches on process evolution mainly deal with changing the enacted process model so that it reflects the changed real world process. Automatically sending notifications about the changed process/products over the Internet to the appropriate members of the global team is not supported. To determine them, the system needs a kind of understanding of the causal dependencies between processes and products. Software change impact analysis [Bohner, and Arnhold, 1996) deals with causal relation between and in products.

Managing software process knowledge is also the goal of the experience factory approach (Basili, 1989; Basili, Gianluigi, Caldiera, and Rombach, 1994). They distinguish between the organizational structure to manage the software knowledge (the experience factory department) and the activities that have to be carried out to build an experience factory.

In this paper, we give a process-oriented view on knowledge-intensiv tasks in software development. In section 3, we define requirements on process-oriented knowledge management systems. Section 4 discusses our process modeling language MILOS and explains how knowledge is linked to generic business processes. The next section shows how this knowledge can be incorporated into concrete projects. A concept for the architecture of a process-oriented knowledge management system is described in Section 6. Section 7 gives an overview on the state of implementation. In Section 8 we discuss related work. The last section gives a summary of the paper.

Globally distributed work processes have to deal with many problems arising from

• different languages & ontologies,
• cultural differences,
• different time zones,
• different work ethics,
• different legal systems, and
• different hard- and software requirements.

Requirement 1: Synchronous work support

Around the clock development requires that - at the end of the working day - the results of the day have to be efficiently communicated to the co-worker in the next time zone who just starts to work. This poses the requirement on modeling approaches, that models have to be easily understood and that an overview on the changes since the last day has to be provided. Nevertheless, synchronous communication between the team members will help in communicating the current state of the work. Audio and video conferencing capabilities can be used as well as shared workspaces and distributed meeting rooms. The technology for that is available but the costs for a wide spread use are still too high.

Requirement 2: Asynchronous work support

In globally distributed software development processes, people work asynchronously in different locations and at different times. Therefore, a support system shall facilitate the coordination and the management of the process. Process enactment support techniques - or, in a broader sense, workflow management techniques - try to provide the right information to the right people at the right time with the right tools. They have to be extended to support work over wide area networks.

Requirement 3: Ubiquitous communication infrastructure

To reduce the problems in setting up a global team, a ubiquitous infrastructure has to be used. Each team member has to be able to connect to the development process without effort.

Requirement 4: Transparent & fast access to process knowledge

For a smooth development process, every team member needs easy access to all relevant project data (e.g. to-do lists, source code, requirement specifications, defect reports etc.) as well as generic knowledge (e.g. coding & documentation standards, effort estimation guidelines etc.). This knowledge can be represented for human use or for use by KBS interpreters. Project data has to be defined in a product model (which imposes a requirement on modeling tools to be open for external access). Using web techniques, the access to data is transparent to the user: It does not matter where the data is stored. Clearly, due to current bandwidth limitations, this is not the naked truth: Accessing the data on a foreign server often needs much more (sometimes prohibitive) time than accessing local information.

Requirement 5: Distributed configuration management

Configuration management systems are used to maintain several versions of a system and all the information related to it. They are a basis for an orderly development process. Consequently, they have to be extended for the virtual environment of globally distributed teams.

Requirement 6: Repository for ontologies

To overcome problems with different ontologies, a project repository has to be provided that defines commonly used terms. Using the Web as the medium, the repository should be organized and maintained at several locations. The repository should be extended to provide an experience base for software development storing generic process and product models as well as metrics gathered in past projects. These could then be used to improve cost and time estimations for new projects.

Requirement 7: Flexibility of development processes

Most software process support environments require a complete, fine-grained process model before the execution starts. For large-scale software projects, that is not realistic: The project plan needs to be refined and extended while the development is already in progress. In addition, there will be no central project plan in globally distributed projects but there will be plans at every location which have to be coordinated. Using and extending knowledge-based techniques, project planning and execution can be interlinked giving a greater flexibility to the people involved in the project. Agent-oriented approaches may help to coordinate the plans of different locations.

Requirement 8: Proactive change notifications

The coordination of globally distributed processes will be improved if part of the task is done automatically. Coordination problems often result from changes introduced into the process because of new external requirements and/or erroneous assumptions. Explicit causal relations between process information generate traceability and can be used by a system to proactively send notifications to team members whose work is influenced by the change (e.g. a task may become obsolete, interfaces of imported modules are changed and users of the interface get notifications). To use change notification mechanisms in worldwide distributed projects; „real" push mechanisms have to be developed. A process enactment engine has to generate events and allow clients to create event listeners.

MILOS allows to represent knowledge about work processes explicitly, especially software development processes. The core notion of MILOS is the PROCESS. Any other information is grouped around this notion: Products are inputs or outputs for processes. Factual knowledge is linked to processes. In this sense, MILOS supports a process-centered structuring of knowledge.

Knowledge needed to plan and execute includes

With MILOS product & resource models can be developed and integrated into process models. For a new project, these kinds of models are the basis for the definition of project plans.

Based on a given product model, products that contain general and specific project knowledge of a company can be specified. The underlying product model defines the structure and the type of that knowledge. A main mechanism for associating knowledge to entities in the process model is using external references to the knowledge. This is further explained in the Section 6.1.

A process is defined by a description of the process goal, a set of conditions, process attributes, the products needed to plan and to execute the process, a set of alternative methods to reach the process goal, the products to be produced, and resource allocations.

Methods are either complex or atomic. Complex methods refine a process into one ore more subprocesses whereas the application of an atomic method results in the production of products that are the outputs of the process.

Inputs of a process may either be products, that are produced by other processes during project enactment, or predefined products taken from generic process models.

Every process is associated with a set of roles and qualifications which are needed to perform the task (e.g. the process „Implement Class" is associated with the qualifications „Java knowledge available" and the role „Programmer").

Process models are generic descriptions of the general way of the course of projects. The models have to be specialized and customized within the projects.

In Table 1 you can find a summary of the basic language concepts of MILOS.

Customizing process models to project plans is part of project planning. Using generic process models, even inexperienced project managers are able to come up with a plan according to the company’s quality standards and procedures. In general, the project starts using an initial plan that defines the general course of action and the first project steps. Customizing extends over the project start. On base of the results of early project activities (for example information gathering activities) parts of the plan are further customized during project execution.

We developed techniques to support (a) plan refinement (b) plan adaptation and (c) error correction during project execution. Methods define possible plan refinements. Selecting a method during execution results in a refined plan. Plan adaptation takes place when the definition of the plan is changed, for example when requirements change or within optimization tasks. Plan adaptation allows, for example, to add new processes to the plan, change the process decomposition, change the order of process execution, and change task delegations.

Finally, planning errors may be detected and have to be corrected if the project is already in execution. Changing the plan may affect project execution, if the changed parts of the plan have already been executed and work has been done. For this, our system supports project execution by

• identifying affected processes, results (products) and resources,
• informing affected developers and manager about the change,
• informing them about further consequences of the change,
• tracing the reasons for the change, and
• (automatically) returning to a consistent project state.

Changes and adaptations may be located within (local) project plan as well as in the process and product models. This causes two problems:

• When should the change in a process model result in the change of derived project plans? (Bogia, and Kaplan, 1995) propose in their work a solution of the problem for a reduced set of modeling concepts.
• How to identify the parts of a derived project plan, that are affected from the change, especially if the project plan widely differs from the original process model.

• reusable process models,
• knowledge needed for a specific project, and
• knowledge & data created during project execution.

Generic Process Models: The first tier handles generic and reusable process models and associates generic knowledge to the entities of the process model. Knowledge may be stored in several forms:

• Concrete knowledge chunks for human use are stored URL references pointing to HTML pages or other files containing information in specific document formats. Access to this can be guaranteed using standard web mechanisms of binding file types to specific applications. Portability and cross-platform access is supported as long as the mapping of file types to applications are valid and the application software is available on the client platform.
• Formalized knowledge bases can be accessed and incorporated into the project execution in two ways. Firstly, by downloading the KBS as a file and starting it on the client side. This requires the KBS interpreter on the client side and the association of the file type with the KBS interpreter application. Secondly, running KBS interpreter on the server side is an alternative. This requires the KBS to have a web interface. A communication infrastructure between the KBS and the project enactment engine would even allow for transferring results from the KBS to the project execution. So, process-oriented knowledge structuring is a natural way for integrating KBS approaches into business processes.
• Predefined queries are used when the knowledge chunk can not be defined explicitly. The query describes the knowledge needed intentionally. We can at least distinguish between several kinds of queries:
• Database queries: To access knowledge stored in a relational database, the process model associates predefined SQL queries as input to a task. When a user carries out a task, he will be able to click on the query. Then the system will connect to the database, query it and present the results to the user.
• Information retrieval requests: Unstructured information can be accessed using information retrieval technology. The request may be posted to a special IR server or to one of the public web search engines.
• CBR requests: Case-based reasoning technology integrates structured and unstructured queries. It allows for similarity-based queries on structured data whereas relational databases mainly support Boolean queries and IR systems work with unstructured data.

Project Specific Process Models (Project Plans): The second tier contains project specific process descriptions. Using the single representation trick (known from machine learning), the mapping of generic process models to project specific process descriptions is easy: We use the same representation for both tiers and are able to copy generic models to a project. Then the generic descriptions are customized to be used in the specific project.

Copying models from the first tier to the second tier is easy. Open problems surely exist:

• which parts of a process model shall be copied (selection),
• how to determine that a generic model can be reused in a given situation, and
• how to support the customization and adaptation process.

Project plans contain the knowledge about the tasks to be done and the knowledge related to them. They are a basis for project enactment and coordination. Using a process enactment engine in a project, a project plan is the basis for actively guiding human users in their work.

Dynamic Project Data: The third tier handles dynamic knowledge which is the core of a flexible workflow/process engine: The state of the work process and its tasks, do-do lists for its users, the products created during process enactment, causal relationships between process entities, etc.

The knowledge stored in this tier is created during process execution: it is the output of the work processes. In software development processes this includes e.g. requirements specifications, design documents, design rationales, traceability matrixes, source code etc.

The third tier provides - beside a product-oriented view - also a process-oriented view on the data created during task enactment. User are able to access information based on the processes carried out and they can follow the information flow in the project (thereby tracing where and by whom a specific information was used).

Figure 2 shows the graphical interface for describing the information flow within a process model. The editors for defining the process decomposition, and for editing product and resource models are omitted.

The interface for defining project plans will look similar. In addition, the user will have access to the model library from where he can copy suited models.

For project execution, the system provides workspaces for managers, developers, and planners. The workspaces are very powerful, because they provide the user with relevant project data, guide them through their tasks, and automatically start required tools.

Figure 3 shows the workspace of Mr. Holz, who is actually executing an atomic method. His task is to develop an interface component in Java based on an OMT specification. The left window (A) displays him the documents he can access and he has to produce in order to finish the task. Clicking on the document symbols, customized editors to edit the products are automatically opened. In this example, a postscript viewer on the OMT specification (B) and an editor to edit the component (C) have been opened. After finishing the work, the task window and dependent tools will be closed by the system.

For coordination tasks each workspace provides a window that displays incoming notifications relevant for the work of the workspace owner (see Figure 4). If he wants to know more about the context of the notification, he can start the information assistant. This web based component navigates the user trough the project plan and provides background information about the project state, decisions and their rationales, and the developed products. Figure 5 shows a screenshot of the information assistant.

 

6.3 Technical Perspective

In this section, we describe how a process-centered knowledge management system can be designed which fulfills the requirements stated in Section 3. We also discuss design alternatives for building the system and explain why we use a specific technology. The whole system is being built using state of the art information technology that is in industrial use.

To fulfil Requirement 3 (Ubiquitous communication infrastructure), Internet technology is clearly the way to go. The Internet - and, in the future, the Internet II - will provide this infrastructure to lesser costs than point to point (satellite) lines. In fact, the wide spread use of Internet-based communication as well as the increasing speed of its introduction to a „standard" working environment make it the obvious and cost-effective choice for global teams. Internet-based virtual private networks create a secure environment for work groups based on encryption techniques. Current problems, e.g. bandwidth, latency, quality of service guarantees, will be overcome with the broad introduction of Internet II and the new protocols. Internet access is more or less available in every workplace - or will be in the next couple of years. To be able to access process and/or project information, the only widely available cross-platform environment is the web. Other environments are either restricted to one platform or use proprietary communication protocols that are not supported in every company. To be able to build up virtual corporations, we decided for a common denominator: TCP/IP and web browsers.

Ubiquitous access to process information also means that every entity needs to have an unique identity and that by using this identity a user is able to access the information (we omit a discussion of security issues here). URLs are the means of the Web allowing to access distributed information. Using URLs an object may be located on an arbitrary computer in the Internet. In addition, Web browsers are able to associate file types with application programs and start them automatically when a document of that type is loaded from an URL. Therefore we decided to use URLs as the unique identifiers of the objects handled by our system and are implementing Java based user interfaces for manipulating the objects that are not stored in files. One possible extension would be to use URL addresses for every object stored in the configuration management and use http as the protocol to access versions of an object stored on arbitrary configuration management servers.

Storing information persistently, several technologies can be used: File systems, relational databases and object-oriented databases. File systems are restricted concerning version management, transaction support, and replication support. On the other hand they are easily accessible by (commercial) web servers. Databases support transactions and - often - replication of data. Relational databases only support table-oriented structures. More complex data structures are supported by object-oriented databases. Therefore, they are the means of choice for software process support (which is our main application area). Using OODBMS technology, we are implementing a configuration management system that allows to store arbitrary versions of products. We will extend this to support distributed configuration management using the built-in capabilities of the OODBMS GemStone (Requirement 5).

Resulting from the remarks above, we can define a first architecture for process support environments (Figure 6). The Internet is the backbone for the distributed system. Client computers access process data using web browsers. Process models, project plans and dynamic project data are stored in a central object-oriented database with additional information stored in files. The database server supports project execution by implementing a process engine that handles to-do lists for team members and by providing access to all project data.

 

The problem with this architecture is that – due to the low bandwidth available on some Internet links – it does not always fulfil Requirement 4 (fast access to process knowledge) and Requirement 5 (distributed configuration management). These problems can be overcome by using proxies, caches and replication techniques that bring the information nearer to the end user. The process support system is then responsible for providing transparency by caching or replicating process data at different locations. Figure 7 shows an appropriate system architecture.

The next question to be answered is how to implement this distributed architecture. Several frameworks for distributed system implementation were developed in the last couple of years. The main competitors in the market are now:

• OSF Distributed Computing Environment (DCE),
• DCOM from Microsoft,
• OMG Common Object Request Broker Architecture (CORBA), and
• Java Remote Method Invocation (Java RMI).

We use Java applets to reduce the problem of distributing (project specific) software tools to team members whereas CORBA allows object-based communication between tools.

Requirements 2 (asynchronous work support) will be fulfilled using our published workflow management approach (Dellen, Maurer, and Pews, 1997; Maurer, 1997). Our approach focuses on methods and techniques that increase the flexibility of workflow management by alternating project planning and project execution steps (Requirement 7). In addition, we developed an approach that supports project coordination by automatically sending change notifications to appropriate team members. This functionality is based on traceability relations that are generated automatically using knowledge contained in process models (Maurer, and Paulokat, 1994; Dellen, Kohler, and Maurer, 1996). Our current approach to traceability is somehow limited: It only generates causal relationships between process data based on generic process notions (processes, process decomposition, and information flow). One of our students, Quan Li, currently develops a framework that allows to define domain-specific traceability relations using event-condition-action rules (ACT-NET Consortium, 1996). The extended framework fulfils Requirement 8 as soon as the notifications - which currently are only distributed in a local area network - are distributed over the Internet.

Product models specify the structure and relationships of (software development) products. In that sense, they describe the ontology of the domain - although they are not formally specified using logical representations (e.g. Ontolingua, KIF, or terminological logic). Using the restricted expressiveness of object-orientation, our system is neither able to automatically classify instances nor can it build up inheritance hierarchies automatically. On the other side, object-oriented approaches support the definition of arbitrary methods for objects. In our opinion, this is an advantage - from a system implementation point of view - compared to the use of terminological languages.

Requirement 1 (Synchronous work support) is not in the focus of our research. Therefore, we decided to use available technology for incorporating this functionality into our environment. Microsoft’s NetMeeting and Netscape’s Conference tools allow for audio and/or video conferencing over the Internet as well as shared whiteboards and/or shared applications (although this functionality currently is restricted to Windows PCs).

CoMo-Kit was developed using the OODBMS GemStone/S and VisualWave for Smalltalk as the programming environment. GemStone/S data definition language and data manipulation language is a Smalltalk dialect. Therefore, we are able to prototype systems in the Visualwave environment and than transfer part of the implementation into the GemStone database (gaining distribution over local area networks and transaction management).

The implemented prototype supports process modeling and process enactment. It contains a traceability component that generates causal relations based on process models and uses these to send change notifications to appropriate users.

We currently are in the process of re-designing and re-implementing the whole system in Java. An initial prototype of the user interface that allows to model the information flow in processes will be available in February 1998. The re-implemented user interfaces are Internet-enabled and support the access to a centralized database that stores all project information.

In addition, a complete re-implementation of a MILOS-based process modeling and process enactment environment is undertaken as a joint effort of the groups of Dr. Richter and Dr. Rombach (both University of Kaiserslautern, Germany) and Dr. Maurer (University of Calgary, Canada).

Work in knowledge management is influenced from several perspectives. There is the organizational perspective that discusses how companies can organize their knowledge management (van Heijst, van der Spek, and Kruizinga, 1996). Often these approaches concentrate on human resource aspects (Sierhuis, and Clancey, 1996).

(Simon, 1996; Dieng, Giboin, Amergé, Corby, Després, Alpay, Labidi, and Lapalut, 1996) discuss the problem of acquiring the knowledge for knowledge management systems.

Knowledge management for distributed enterprises is discussed in (Gaines, Norrie, Lapsley, and Shaw, 1996). The authors show how the web can be utilized for knowledge management. Their approach does not explicitly model the work process.

Several authors developed tools for managing different aspects and representation formalisms over the web (Gaines, and Shaw, 1996; Farquhar, Fikes, and Rice, 1996; Kremer, 1996). None of these is explicitly representing work processes (which - in our opinion - are the glue that holds several products together).

(Abecker, Bernardi, Hinkelmann, Kühn, and Sintek, 1996) integrate information retrieval and knowledge management. Although their approach also deals with work processes, they do not represent them explicitly so that the processes can be changed on the fly.

The process-centered structure of the system has the following advantages:

• Processes are „natural" entities for managers and team members: they are well used to thinking about the process (e.g. for project planning).
• For their daily work, people don’t need knowledge per-se but the knowledge they need for performing specific task. A process-centered knowledge management system associates explicitly the task with the knowledge needed for it.
• By linking web references to task, the lost in hyperspace problem is reduced because the user immediately finds the knowledge needed instead of being forced to browse to relevant pages.