FlowTEC - An information system supporting virtual ... - CONPROF

FlowTEC - An information system supporting virtual enterprises Ansgar Schmidt, Thomas Sindt, Murat Tepegöz TZI- Center for Computing Technologies University of Bremen P.O.BOX 330 440 28334 Bremen Germany

Abstract. The complexity of global engineering processes requires new information technologies which can handle the flood of information between different organizations and engineers. FlowTEC proposes an information system architecture that especially fulfills the requirements of information systems supporting virtual enterprises. The system provides a new technology to support intra- and inter-organizational information flows. It is based on an explicit enterprise model, which defines different aspects – data, workflow, organizational units, tools – of distributed processes. In order to support distributed processes, which are spanned across multiple organizations, FlowTEC introduces a cascading multi-server architecture, where several FlowTEC servers are arranged in a hierarchy. This architecture concept allows an administrator to scale up a virtual enterprise not only on company level, but also on a fine-granular level of organizational units. The cascading server architecture is transparent with respect to the global company-wide information system.

1.

Motivation

The complexity of global engineering processes requires new information technologies which can handle the flood of information between different organizations and engineers. Unfortunately, existing groupware and information management systems do not adequately support cooperation between groups/teams of different organizations. These systems have no knowledge about the cooperating organizational units, the underlying inter-organizational processes, and the exchanged documents. Therefore, it is necessary to provide an information system infrastructure, which guarantees an effective information management in distributed engineering processes. The basic idea of FlowTEC enables companies to control their information flow. FlowTEC operates and helps employers of a virtual enterprise (cf. [4]) after it has been founded. The organization management system is designed especially for virtual enterprises taking into account the distributed culture. In the same way the workflow management system and the document management system are designed for

distributed data. In contrast to other CSCW (Computer Supported Cooperative Work) systems, FlowTEC is not created in a monolithic architecture. FlowTEC features a cascading server architecture. The whole system is based on many distributed FlowTEC systems which act together. FlowTEC can operate for virtual enterprises or in an enterprise itself to manage departments. So FlowTEC realizes the idea of 'enable many to act as one'. In the first part this paper gives a general idea of virtual enterprises and the underlying requirements. Taking this into consideration, the second chapter describes the functionality provided by the FlowTEC system. The third chapter introduces the system architecture from a technical point of view.

2.

Virtual Enterprises

2.1

Fundamentals

A virtual enterprise (VE) (cf. [2, 4, 10, 11, 12]) is a cooperation of companies like an alliance. The difference between a VE and an alliance is on the one hand the missing headquarters of a virtual enterprise and on the other hand the extensive use of modern information and communication techniques. In most cases alliances as well as VEs are founded for the same reason. Often it is not possible for one company to realize a large-scale project by its own. By searching partners and founding together a VE it is possible for the new company to realize the project by focusing their sphere of competence especially on this project. Because of their know-how the newly generated VE / leading company has an advantage over other companies in the market. For the customer the virtual enterprise seems to be one company. One of the basic aims of the VE is to minimize the management overhead. In order to use a simple hierarchy and organization, mutual trust among all partners is indispensable. As the VE Figure 1: The Virtual Enterprise Principle implements flexible structures, it is able to react to the market requirements at short notice.

2.2

Hardware and software demands

State-of-the-art IT technology is required for establishing and managing a VE. Network and an internet or intranet ability, is needed. The server systems have to guarantee a short access time even during peek accesses. The main goal of such a system is on one hand to give every person involved the right information and on the other hand to ensure the consistency of the information. Only the person who has the right information can draw the right conclusions and make the right decisions. Depending on the topicality of the information the company is able to react faster onto the market. This holds especially true for a VE. It has to be ensured that the information is correct and available at any time and any place. All this must be guaranteed for each member of the virtual enterprise. On the one hand, the information should be delivered automatically to the special customer by the system, and on the other hand each customer should get any information manually he is allowed to access. In order to automate the information flow it is necessary to define the organization structure as well as the information flows of the business process themselves. This definition should be modifiable at short notice to guarantee the flexibility of the virtual enterprise. Apart from the definition of organization and information flow structures it is necessary to define the business process and the engineering processes. Thus it is possible to automate, to generalize and to document the flow of events. Such workflows have to be started either manually by the user or automatically by events. It has to be possible to decompose the processes during their definition and to define the dependencies of these processes. As rules can be defined for a VE with the help of processes, information flows can be influenced in a wide range. Information is stored mostly in documents. By changing documents information is generated and has to be sent to the recipients. There is a great need for application integration. Therefore, the system should be able to handle documents together with their applications. Last but not least, the provided software should be system-independent and executable on almost any platform.

3.

The FlowTEC System.

FlowTEC supports organizations like enterprises, departments as well as employees and authorities. This is done by defining processes, organizational structures and handling documents. Therefore it is necessary for every organization unit to install a FlowTEC system. All servers are identical and connected in a star topology to each other. Each unit is based on one server and three clients. The system functionality includes workflow management (cf. [1, 5, 6, 7]), organization management and document management (cf. [8]). This can be used inter- and intraorganizational. FlowTEC enables the user to integrate several applications and handle them. Each time the user is able to manage the integration process in order to guarantee the safety of the own system. Examples for application integration are video conferences,

cooperative work with documents or triggering other workflows. Especially the external workflow triggering enables the user to integrate existing workflows into the FlowTEC system. Each part of the FlowTEC System is described in the next chapters. 3.1

Workflow management system

The workflow management component helps the user to model the processes (cf. [3]) within FlowTEC. This component integrates all information from the document management, the organization management and the application integration in order to build a controlled workflow, which may be mandatory documents, requirements to the process owner or applications used. Basic Elements: There is no point in defining a workflow by defining every process individually. FlowTEC helps the user to generate definitions (or schemes, types) of processes from which the instances, actual processes can be derived. The process definitions consist of attributes, parameters (in/out), status information, access rights and the actual workflow definition, where the sequence of process steps is defined. We explain the workflow definition components in the following. Processes: There are two kinds of processes: atomic processes are executed by an actor, complex processes include workflow definitions and are handled by a WFMS. Actors: Actors are results of the organization structure. An actor can be either a complex organization unit (department, subdepartment or group) or a person. It is also possible to define the requirements for the handling of processes by a number of rules which have to be fulfilled. During atomic processes the actor can be chosen or the actor himself can choose the preferred job from a list. An operator can be a person or an application. Documents and attributes: On one hand a document can be changed or generated by a process, on the other hand the document as an information is necessary to run a process. The attributes and documents are passed within a workflow as parameters and can be changed. Additionally, control elements (connectors) use these attributes as control elements, so that depending on the attribute values only certain processes are triggered. Applications: In order to run atomic processes certain applications may be needed, which can be started automatically or manually. Time control: FlowTEC features a distinctive time control system. Every process can be defined by a starting time and a deadline. Furthermore, it is possible to define a duration as well as an iteration if required. Control structures: The following control structures describe the control flow of a workflow definition. These are sequences, parallelism, splitting and iteration.

Distributed processes: The distributed architecture of the FlowTEC system has the advantage, that it can hide the company confidential information. Sometimes in real life individual parts of a VE are competitors. The workflow as an entire system should be separated into simple runnable elements. As the connection between workflow servers is made by interfaces it is possible to trigger distributed workflows. In addition, complex workflows may run as a combined process in a workflow engine. These combined workflows are black boxes for all the other companies. Workflows can be defined top-down (starting with a macrostructure) as well as bottom-up (starting with a microstructure). The refining procedure can be executed by other companies. Access-rights (like reading, creating and modifying) can be defined for each individual process definition. Apart from this, a distributed process is a good idea to avoid overloading a single server. Changing of workflow definitions: In order to react flexibly to unforeseen external events, which concern processes in the VE, workflow definitions can be changed during run-time. Running workflow processes may be accessed only after their termination. Instances are generated according to the changed workflow definition. So far, a modification of the definition has no impact on running instance. As soon as an instances is running it is independent of the definition. 3.2

Document management

The document management component is responsible for all documents created in a VE and guarantees the consistency of all documents. As well as for the proper document processing this component serves also as a data type engine for the workflow component. Document description: The document management component does not access directly the contents of documents. Rather, information about the document is managed. This information is called meta-information. In order to describe a document, first of all it is necessary to specify the type of a document. These types are built of simple or complex data types. The simple data types (Integer, Boolean, String, Date) are predefined by the system. Out of these simple types the user can build more complex types. A new data type is distributed to all connected FlowTEC Systems immediately after its generation and can be used by everyone. Thus the document information in the entire VE can stay consistent and can be replaced. Data types are used in order to define a document type. Information about a document of this type should be given for its complete description. For example a document type called "account type" can be built upon the data types "address" (for the account recipient) and "real" (account amount). Because of their types the documents can be associated to during check-in. Therefore the user has to define a value (this can be the account amount) for each data type which is predefined in a document type. Searching can be done with this value. All this can be achieved by using a GUI which is adapted dynamically to defined data types.

Repository and version control system: If a document is made available to a FlowTEC system, it is delivered into a repository on a server, where it is stored as an initial version accessible by all persons involved (who have access to the server). An employee can check out a copy of the document from the repository to his local workplace and manipulate it. Because of the document-related meta-information, FlowTEC can start an associated application. When a working copy of a document is changed and checked in, a user-defined workflow can be triggered. For example, the workflow can notify other document users or make the actual document version available. In contrast to read access, write access is characterized by locking the repository to other users. A document cannot be modified by more than one person at a time. Therefore, data consistency is ensured. Version control makes the access to older versions possible. Because the FlowTEC system is a distributed system, it is necessary to transfer documents between servers. This is highly transparent for users. The distributed FlowTEC systems acts like one system and locates the document in the net and transfers it to the user. Searching can be done by using the meta-information of the documents. Simple requests can be combined to complex ones. Distributed document management: The search, check-in, and check-out are available on all connected servers, under the condition that appropriate rights have been set. So a total repository is developed, to which all VE members have always access. Therefore the system makes an uncomplicated access and document exchange possible. One of the most important properties of a document management system is the visibility of documents. Not every member of a VE is allowed to read all documents, or even know about the existence of some of them. Although this contradicts to some extent the basic idea of a VE, for security reasons it is necessary for the participating real enterprises. 3.3

Organization management

This component serves for modeling the organization structure of the VE and for the mapping onto real organization units. Further, it is possible to administrate the FlowTEC access control system with this component. Organization units: Enterprises, departments or teams are modeled as organization units. Every enterprise includes departments and teams, which are also modeled as organization units. Behind every department or team exists a real department or real team, which also could be distributed. Supported organization types: The modeling of an organization type begins with building up hierarchy tree structures, which represent the base of all supporting organization types. First, the top organization unit has to be determined, then all other

units. These can be enterprises, departments or teams. When organization units are modeled, jobs can me mapped onto these. Furthermore, it is also possible to define flat and multi-dimensional organization structures. For example, a matrix organization or a combination of several organization types can be modeled. All defined organization units or jobs are maintained as objects in a database, which stores the organization structures or contact persons. To support the cascading server architecture, each server includes an organization engine, which includes the respective information about their organization structure. The organization management supports the following organization types as well as their combinations. The mapping of real organization units onto virtual organization units: Behind every organization unit as well as behind every job there is a consulting person, who has an address, a telephone number, possibly a fax number and an e-mail address, which are stored in a database. In order to contact an indirect address, i.e., sending an e-mail, the organization server provides the e-mail address and delivers the message. These are secured private data. Access control right system: Every organization unit or rather every job has one or more access privileges. These can include further privileges, the so-called complex privileges. These complex and normal privileges can be defined in and mapped onto the organization management. Basic access privileges are for example reading, writing, accessing and administration. Distributed organization: The central VE is a mapping of real distributed enterprises, which again can include distributed departments, teams and jobs Every enterprise has an organization server, which can connect further servers for the individual departments, teams and jobs. Each server has the knowledge about one detail of the organization structure. The global FlowTEC server, which is connected to all enterprise servers knows the complete structure. Because the addressing is done indirectly, the FlowTEC server hides all information that should be not visible to other enterprises.

4.

System architecture

4.1

Multi-tier server platform

The FlowTEC system is realize as a multi-tier architecture. This server architecture separates all abstraction levels from each other. A FlowTEC server consists of five layers: a database system, a database object layer, the server components of services (workflow, document management, and organization management) and a service provider (FORB (FlowTEC Object Request Broker)), which is the interface to the clients and to all other servers and is necessary for building a cascading server system. The last layer consists of the clients which use the FORB and the service components. The communication between all layers and between the companies within one layer is realized and coordinated by CORBA (Common Object Request Broker

Architecture). The system is implemented in Java 2.0 and hence platformindependent. 4.2

Object-oriented database as the basis

The objects of the FlowTEC system are kept persistent in a database. After indepth evaluation of different database systems with different concepts (relational, object-relational, object-oriented), the project decides in favor of the object-oriented database system “Objectstore PSE V3.0” by “Object Design”. Because of the object orientation of the database system, it is quite straight forward to store a FlowTEC object. In the contrast, with relational database systems we would have the problem of mapping objects on relations. Supporting Java is one more advantage of “Object Store”. The database itself is implemented in Java and therefore also platformindependent. 4.3

Database services (DB services)

The DB service component is realized on top of the database system. This component transfers the database objects into CORBA proxies. All database requests are handled by this layer. For other components the result is made available as CORBA objects. Beside this main task, the DB service component is also responsible for the management of a distributed database system. Another function is to ask for an object on every database of the adjacent servers, if the object is not found on the local server.

4.4

Services

The basic logic of FlowTEC is implemented in this layer (comparable to the CORBA facilities, e.g., the workflow facility [9]). It is built on top of the DB services layer. It is necessary for the workflow component to have access to all internal components of this layer. The OM service is used for controlling the processes and the DM service is used for data exchange.

Layer 1 (Clients)

Layer 2 (FORB)

Layer 3 (Services) Layer 4 (Database Service) Layer 5 (DBMS)

Figure 2: Architecture of the FlowTEC-system

4.5

FlowTEC Object Request Broker (FORB)

The FORB has two tasks. The first task is to offer the services to the clients and the second is to make it possible to build up a cascading server system by contacting its super server. The super server adds the sub-server in the list of its subordinate servers. This is how a hierarchical topology of FORBs is established, which makes the administration of the system in cooperating organizations possible. So the structure of the VE can be requested using the FORB. The FORBs itself communicates with CORBA. 4.6

Clients

The FlowTEC system offers three main clients systems for organization management, document management and workflow management. Furthermore, two other administration clients are provided. One tool gives the opportunity to organize the server structure (the FORB client). With the other tool it is possible to control external programs from the FlowTEC system, the application integration client. 4.7

The cascading server system of FlowTEC

A FlowTEC system includes several servers. Every FlowTEC Request Broker (FORB) can be connected to one server, and also to a FORB of a super server. So a hierarchy of servers in a system is built up. This hierarchy represents the cascading server system of FlowTEC. The advantage of this architecture is the simple administration. In every hierarchy workflows can be established, documents can be administrated and organization types can be defined. Thus, internal as well as crossorganizational capabilities for modeling and administrating VEs are provided. It should be of particular interest that this structure is only a technical realization of an organization connection. This architecture is handled transparently by the service modules. The communication of FORBs is done by CORBA. 4.8

Used technologies

The entire project is based on a combination of standard technologies. This makes an efficient and open system development and implementation possible. One of the main focuses of the project is the interoperability of the single system components. The system uses the industrial standard CORBA for the communication between every single component. 5

Conclusions

The special requirements for a VE useable system are fulfilled by FlowTEC. The system of the cascading servers allows a distributed usage with a minimum of security

hazards. Organization structures of companies can be modeled and be used in the system without access to other servers. The actual FlowTEC system is a prototype, which implements the basic architecture and the most important functions. FlowTEC is the result of a student project at the University of Bremen. A team of 12 students cooperated under the supervision of two assistant scientists and one professor. The following students contributed to the project: Nalan Akin, Senay Bayrak, Björn Imgrund, Andreas Lattner, Wolfgang Runte, Christian Schäffer, Ansgar Schmidt, Norman Schöneich, Holger Schulz, Thomas Sindt, Jan Stocker, and Murat Tepegöz. Gregor Joeris, Holger Wache, and Prof. O. Herzog were the supervisors. 6. [1] [2] [3] [4] [5] [6] [7] [8]

[9] [10] [11] [12]

Literature Mathias Becker: Workflow Management - Szenarien und Potentiale. In: Praxis des Workflow Managements, Friedrich Vieweg & Sohn Verlagsgesellschaft mbH, Wiesbaden, 1996 David Brütsch, Fabio Frigo-Mosca: Virtuelle Organisation in der Praxis. In: io Management 9/96, Handelszeitung Fachverlag AG; Zürich Curtis, B.; Kellner, M.I.; Over, J.: "Process Modeling". In: Communications of the ACM, 35(9), Sep. 1992; S. 75-90. William H. Davidow, Michael S. Malone: Das virtuelle Unternehmen: Der Kunde als Co-Produzent. Campus Verlag, Frankfurt / New York, 1993 Georgakopoulos, D.; Hornick, M.; Shet, A.: “An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure”. Distributed and Parallel Databases, 3(2), 1995; pp. 119-153. Heidi Heilmann: Workflow Management: Integration von Organisation und Informationsverarbeitung. In: Theorie und Praxis der Wirtschaftsinformatik März 1994, Forkel Verlag, Stuttgart Thomas Kock, Jakob Rehäuser, Helmut Krcmar: Ein Vergleich ausgwählter Workflow-Systeme. In: Information Management 1/95, Computerwoche Verlag GmbH, München Morschheuser, S.; Raufer, H.; Wargitsch, C.: Challenge and Solutions of Document and Workflow Management in a Manufacturing Enterprise: A Case Study. Aus: Lynn, M. (Hrsg.): Pro. of the 29th Annual Hawaii International Conference on System Sciences (HICSS). Los Alamitos 1996. S. 4-13 Object Management Group: "OMG Workflow Management Facility – Request for Proposals", Final CF RFP-9, OMG Document cf/97-05-06, 1997. Michael Reiss: Grenzen der grenzenlosen Unternehmung. In: Die Unternehmung 3/96, Verlag Paul Haupt, Bern Christian Scholz: Die virtuelle Organisation. In: Manager Bilanz, WM Wirtschaftsmedien AG, Zürich, 1997 Andreas Schräder: Management virtueller Unternehmungen. Campus Verlag, Frankfurt / New York, 1996