Business
Object Workshop IIBusiness
Object Workshop IIRevised 29 October 1996
The key idea behind workflow systems is to extract the process management out of enterprise-wide applications which implements business processes. The same method can be used for building applications which can be invoked in workflow activities. Applications can be build out of software components with an additional special component for controlling the other components. A componentware system realising this idea could be used in combination with a workflow system. This would reduce a lot of problems which exists in today's workflow systems. The design and the requirements to these components are described in this paper.
In this section the essential terms of workflow management are introduced (see also [WFMC96a]). Then it is described which advantages can be derived from the use of a workflow system. The main idea of workflow management is exposed by comparing today's software equipment found in enterprises with a typical use of a workflow system.
A workflow management systems (WFMS) is a software system for the coordination and cooperative execution of business processes in distributed heterogeneous computer environments. The objectives of a WFMS are in a first phase to model the structure of an enterprise and the sequence of all business procedures and in a second phase to control, to supervise and to record he exectuion of all modelled processes.
A sequence of business procedures is modelled in business processes. All sequential or parallel relationships between process steps will be specified in business processes models. For each step it is determined which work objects (data and documents) and which human, technical and organisational resources are necessary for the execution. A business process, also called workflow, is modelled as a graph with process steps as nodes and control and data flow relationships as edges.
A process step which is called activity in a business process is a piece of continuous work executed by one person. The worker (actor) of an activity can use an interactive application program to fulfil the objective of the activity. It is also possible to do something manually without computer assistance or to automate activities which don't need human interaction.
Figure 1 shows a model of a business process which is used in IBM's workflow system 'FlowMark' [IBM94]. Activities are connected via control flow connectors. After finishing Activity A1 Activity A2 is sequentially executed. A3 and B1 will be executed in parallel. Determined by the transition condition belonging to each control connector either the lower branch with A4 or the upper branch is executed. After finished the branch A5 is executed. Each activity has an input and an outputcontainer used for input and outdata. The transport of data is symbolised by the dataflow connectors.
By identifying and specifying business processes the possibility grows to optimise the enterprise potential not only locally but globally. It is easier to automate processes and integrate legacy applications if the organisational structure of an enterprise is process-oriented instead of divided in departments. The enterprise wide controlling of processes and the improved information system features create the capabilities to inform everybody about the states of all running processes into the last detail.
This is why the use of a workflow system can lead to high productivity rates.
The situation of the electronic data processing in enterprises can be charactized as follows:
Nearly all workers are using function-oriented programs to do their daily work. Typically programs to support this office work are word processors or spreadsheet applications. Most of these programs doesn't support cooperative work. Users cannot take a look in the history of a document and get the information who has modified something. They cannot ask the application which work has to be done next. There exists no reference to the business process in which the document was created and modified.
Beside the function-oriented programs exists a sort of more process-oriented applications mostly realised as big monolithic applications build for mainframe computers. These applications implement one specific business process in a "hardwired" manner. Other processes cannot be executed with these programs and changes in the underlying business process means a lot of effort for reprogramming.
The key idea of workflow systems is to make the notion of process explicit visible in the software system. Hence, you get a configurable system for executing business processes. The business process have to be organised in process steps. All function-oriented work is done in these activities. The activities are tied together via the specification of data and control flow. The workflow system is used to model the activities and their relationships and it controls the execution of this business process model. It also uses additional information like the structure of the enterprise organisation to optimise the execution of the computer aided business process.
The key idea of database systems is to extract the data management out of applications. Analogous, workflow systems extract process management out of applications.
Hence, workflow systems can be reused for the execution of business processes. Modifications are far easier to implement by using the principle: "modelling instead of programming".
Using workflow systems in practical work shows that today's systems doesn't meet the following requirements which are important for the acceptance of workflow systems at marketplace. In the following paragraphs are a few problems mentioned. These are used to motivate a concept to solve these problems that is described in the next section.
Reusing implemented workflow is only partially possible. After modelling a workflow in the modelling tool of the workflow system you can store the workflow in an external representation. This representation can be imported into the workflow system of another enterprise. This task is easy if the workflow systems are from the same manufacturer. It can be difficult if a conversion of the external representation is necessary. After importing the workflow small modifications with respect to the special conditions in the other enterprise can be done. Lots of business processes e.g. clearing of travel expenses are executed in a same or similar way. This eases the reuse of process specification.
In a business process model are only links to application programs stored but the applications itself are not included. Typically, the hardware and software is very different in different enterprises . Because of this it is not possible to use the same applications in the activities. Reuse of a business process model is easy. Reuse of activities with their included applications is costly.
Most applications used in activities are not available on all platforms that can be found in the workflow system. Imagine, an user will work exceptionally at a different workplace which has a different computer platform. Perhaps the necessary application program to execute this activities is not available on this platform. He will get an alternative program on this platform in order to do this work. He is not used to this program and so the productivity will be reduced. Perhaps he even can't do this work because there exists no equivalent program.
The modelling tool can be used to modify a workflow after the change of some aspects in the enterprise. Flexible and easy modification facilities are one of the main advantages of workflow systems over hardwired applications implementing processes. Adaption is only in the process model possible but not in the activities and their applications. The only but costly way to adapt applications is to hire a programmer to modify the program.
A workflow system offers services for fault tolerant execution, implements security aspects and so on. Most applications cannot use these services nor can they share in some of these concepts. Sometimes each application even implements the same services by itself. There exists no global use of concepts. All uses are locally.
Applications do not work together to fulfil one objective. They have no information about services implemented in other applications and they have no possibility to use services in other applications. Due to this lack a lot of functionality is multiple implemented. Most of these implementations are also incompatible. E.g a video conferencing application uses his own user management. After hiring a new worker the user management system in the video conferencing program and in the workflow system must be updated. You have to do the same thing twice.
Some further problems are not mentioned here. The main aspect of the problems mentioned above is that they can be solved by a single solution. This is to integrate a componentware system within a workflow system. After defining the term 'componentware system' a specialised system is introduced. It is motivated by the observation that application programs are also structured in a process-oriented manner similar to workflows. This feature is used to design a component process system. This system should be used in combination with a workflow system as a two level process system.
A componentware system is a software development system for assembling applications out of prefabricated software components. The components will be implemented and selled by independent software manufacturer. Each component is specialised to fulfil a specific function. The more complex functions of an application are build by combining components of less functionality. Additionally it is possible to adapt and customise the components for the special requirements of the end user of the application.
The main difference to ordinary programming of applications is that combining and customising components is not only possible for programmers but also for end users. Applications are not programmed from the scratch but combined from prefabricated software parts.
Looking at a function-oriented application leads to the observation that applications can be structured as a process. Functional blocks can be seen as process steps which are related to other function blocks. The relations are defining a complex structure of data and control flow.
That means, an application can be descripted as a set of function blocks (software components) and their relationship. The description specifies a model of an application process. Consequently, it is possible to extract the process management out of the application into a generic process system. This component process system can be reused for several applications. Because of the explicit modelling of the application process and the execution of the process by a runtime system it is easy to modify the application if something in the enterprise has changed and that has to be reflected in the business process. Components can be exchanged or the relationship between the components can be modified. It is also possible to do some modifications on the data produced or consumed by the components. This is every useful if an error situation is occurred. The user is now enabled to interact with the application and can find some solution which he can execute "by hand".
The end user of the application can create and modify the application by itself. Other programs can use the control facility of the components for their purpose. Especially a workflow system would gain more control possibilities and therefore the flexibility of the workflow system would raise.
This leads to a two level solution to implement enterprise wide applications (business processes). A workflow system is used for controlling the work in the distributed heterogenous computer environment found in most enterprises. It controls the execution of activities. A component process system is used in activities to coordinate and support the function-oriented steps of a worker.
Despite of the similarity of a workflow system and a component process system it is evident that two different systems are needed. The performance requirement in a component process system is higher as in a workflow system. In a workflow the transition time between two activities is not critical. Transition doesn't occur very often, the transition time is low compared with the working time of an activity. In a transition the worker is changed. It doesn't matter how long it needs to put an activity on the work list of the next worker. In a component process system a transition shifts between components the worker is using. The transition time should not delay the work with the application because the worker can't do anything during the transition time.
A component process system doesn't need the same additional informations like a workflow system (e.g the organisational structure of the enterprise). To use a workflow engine as a component process system would lead to much unnecessary work to be done by the engine. Also, a workflow system doesn't support any concept to integrate the GUI's of the components into one GUI of an application. There exists no layout module. The requirement for the mechanisms to transport data is different (e.g. Drag & Drop versus migration of documents).
The compare of the two level process management concept with the concept of mobile agents [Fisch96] shows that there exists a lot of similarities. The whole system work is not done by a centralised system but distributed over external control modules. These control modules (a mobile agent or the component process system) do their work on a host where the work has to be done. The modules are migrated to this host, do their predefined task and return their results to the centralised system.
The integration of workflow systems with systems to develop application programs out of pre-factored software components result in the following requirements for the components.
With respect to these requirements it appears to be possible to realise such a component model on the base of the standardised object technology CORBA [OMG95a]. All necessary interfaces can be standardised by the common object services in the OMA architecture. The programming language Java can be used for writing platform independent applications [BEANS].
The architecture of component process system can be derived from the architecture of a workflow system. There also exists a division in a developing system and a runtime system which are described in this section.
The components are stored in a component repository module. Because all applications made with the developing system are used in business processes in one enterprise, the components stored in the repository are domain specific. This means not all imaginably components has to be stored in the same repository [ZS95]. An enterprise would buy a domain specific repository.
Each component must register this interface and a description of their functionality in the repository. The user will use the repository to search for an appropriate component.
Each component gathered from the repository must b e configured before it can be build in the application. Therefore, we need a module to make customisation adaption on the generic software components.
After gathering and customising the components, the relationship between the componentes, mainly the data and control flow, have to be specified. This is best done by a graphical interface because the end user should not need programming skill. The control flow between components is much complexer as the control flow between activities. Therefore, is is advisable to support a glue-language which is needed to express this complexity. The language can be based on common scripting languages. In the toolkit must also exist a module to do the layout for the GUI of the components. The finished application should present an uniform GUI for all integrated components.
There exists a strong need for a comfortable simulator which can execute the modelled application process. This is necessary because the user should have the possibility to test whether the application is doing what he expected to do.
The runtime system is getting a description of the components and their relationship as input. If one component isn't available at the local host it has to be retrieved by the runtime system and transported to the local system. If the component can't be executed on the local system the runtime system has to implement a transparent method to use a remote runtime system for the execution of this component.
The runtime system instantiates all components and starts the application. Then it controls the data and control flow between the components. It also communicates with external applications like the superior workflow system.
A main requirement is the possibility to change easily from the runtime system to the developing system to do some modifications in the application process. This is an important feature that allows ad hoc modifications.
The university institution "Software Lab" was created for the purpose to intensify the technology transfer between research institutions and industry. In the mid of 1995 there was a cooperative project founded between the Institute of Parallel and Distributed High-Performance Systems (IPVR) of the University of Stuttgart and the German Software Development Lab (GSDL) of the corporate IBM in Boeblingen. Objective of this project is to implement a prototype workflow system which can be used to evaluate some concepts for executing fault tolerant workflows.
After concluding of the project it is planned to use this prototype workflow system as basic software and enhanced it in such an manner that applications based on workflow enabled components can be executed in activities. In parallel we will implement a prototype componentware system that fulfils the necessary requirements to use it in a workflow development environment.
Outgoing from the unsatisfying reusability of workflows, the inadequate possibility to adapt activities and the low integration of application programs in the workflow system, a new solution was proposed which solves these problems. The application programs invoked in activities should be build by using a componentware system. This enables the user to do some modifications on the finished application if necessary.
The observation that application programs are structured in processes similar to workflows leads to the design of a special componentware system. This uses the same key idea as workflow systems: Extracting the process management out of applications.
The designed component process system can be used in combination with a workflow system as a two level process management. The component process system supports the control in the activities and the workflow system supports the control between the activities.
[Adl96a] Richard M. Adler: "Distributed Coordination Models for Client/Server Computing", IEEE Computer, Apr, 1995.
[BEANS] Java Beans: http://splash.javasoft.com/
[Fisch96] Reiner Fischbach: "Dienstbare Geister", ix, No. 4, 1996.
[IBM94] IBM: "FlowMark for OS/2 - Modelling Workflow", SH19-8175, Denmark, 1994.
[OMG95a] Object Management Group: "CORBAservices: Common Object Services Specification", revised edition, March 31, 1995, OMG Document 95-3-31.
[WFMC96a] Workflow Management Coalition: "Workflow Management Coalition: Terminology & Glossary", Document Number WFMC TC 1011, Issue 2.0, June 1996.
[ZS95] Mansour Zand, Mansur Samadzadeh: "Software Reuse: Current State and Trends", Journal of Systems and Software, Sept, 1995.
Business
Object Workshop II