analysing, modelling and improving workflow application development processes

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2001; 6: 35–46

Analysing, Modelling andImproving WorkflowApplication DevelopmentProcesses

Practice SectionMathias Weske1*†, Thomas Goesmann2, RolandHolten3 and Rudiger Striemer4

1Eindhoven University of Technology, The Netherlands2Fraunhofer ISST, Germany3University of Munster, Germany4adesso AG, Germany

The success of workflow projects to a large extent depends on how workflow applicationdevelopment processes are planned, organized and conducted. Based on lessons learnedfrom problems encountered during real-world workflow projects, this paper presents adevelopment methodology for workflow application development processes, which guidesproject managers and developers through the complex structure of these processes, aimingat developing more adequate, usable and reliable workflow applications. Copyright 2001John Wiley & Sons Ltd

KEY WORDS: workflow application development processes; development methodology; case study

1. INTRODUCTION

Workflow management systems aim at the con-trolled execution of complex application processesin distributed and heterogeneous environments(Georgakopoulos et al. 1995, Leymann et al. 1994).These systems are already and will continue toseverely influence and shape the structure ofinformation systems in business and non-businessenvironments. While software development pro-cesses have been investigated for some time now(e.g. Boehm (1981)), the specific properties ofworkflow application development processes(WADP) have received little attention so far. This

*Correspondence to: Dr. Mathias Weske, Eindhoven Universityof Technology, PO Box 513, 5600 MB Eindhoven, The Nether-lands†E-mail: m.weskeKtm.tue.nl

Copyright 2001 John Wiley & Sons, Ltd.

paper tries to remedy this situation by analysingproblems encountered during the conduction ofreal-world workflow projects and by formalizingthe experiences drawn as a development method-ology which can be adapted to the needs ofparticular workflow projects. While the generalstructure of the development methodology is basedon techniques known from software engineeringprocess models, the specific properties of workflowapplications and their implications to developmentprocesses of workflow applications are well takencare of.

We now introduce basic concepts in workflowmanagement, used in the remainder of this paper.Workflow schemas are representations of appli-cation processes and of the technical and organiza-tional environment of their execution, to be usedby workflow management systems for controllingthe execution of workflows. Typically, differentperspectives are covered in workflow schemas.

Practice Section M. Weske et al.

The functional perspective describes what has tobe done within a workflow. The operationalperspective determines how it is done, i.e. whichmethods, techniques and tools are used to performa given workflow. The behavioural perspectivedefines the behaviour of the workflow, i.e. itspecifies when and under which conditions aworkflow is executed. The informational perspec-tive specifies the data objects which are beingmanipulated during workflow executions and theflow of data between workflow activities. Theorganizational perspective describes how the work-flow is embedded in the context of the organization,both in terms of personnel and information infra-structure. This perspective is often covered byroles, which specify properties of personnel andsoftware systems. When a workflow is performed,a technique called role resolution is used to assignpersons or software systems to workflow activities.Once a workflow schema is defined, a workflowinstance can be instantiated which represents abusiness process, e.g. the processing of an order.We denote by workflow application an informationsystem in which work is co-ordinated by a work-flow management system. Typically, numerouspersons with different backgrounds and experi-ences collaborate in a workflow application. Inorder to develop adequate workflow applications,these persons, their skills and expertise also haveto be taken into account.

Workflow applications are developed in complexprocesses in which numerous persons with differentbackgrounds participate. While workflow appli-cation development processes differ from oneproject to the next, the general procedure can bedescribed as follows (Holten et al. 1997). The firstphase deals with gathering information, relevantfor the application process. Empirical studies basedon interview techniques and analysis of availabledocumentation are used. The activities in thisphase are centred around the application domain,and technical issues are often not considered. Thenext phase involves business process modelling,in which the information gathered is used tospecify business process models. The main purposeof business process modelling is to provide ageneral and easy-to-read notation, which enablesinformation system experts and domain experts tovalidate and optimize business process models.The result of this phase is specified in a businessprocess model, which is used as a basis for theCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

36

next phase, the workflow modelling phase. Its aimis to enhance the business process model withinformation needed for the controlled execution ofworkflows by a workflow management system,involving adding technical information and purg-ing application specific information which is irrel-evant for workflow management. Finally the work-flow application is deployed in the targetenvironment, and the operational phase starts.

This paper is an extended version of Weske et al.(1999); its remainder is organized as follows.Section 2 briefly describes real-world workflowprojects we have conducted, and it shows a setof important problems encountered during theseprojects. Section 3 proposes a development method-ology for workflow application development pro-cesses; concluding remarks complete this contri-bution.

2. CASE STUDIES

In order to create an empirical basis for our work,it is necessary to examine some of the experienceswhich we had in different companies whendeveloping and introducing workflow appli-cations.* For that reason, we have chosen sixGerman as well as multinational companies work-ing in transportation, telecommunication, insuranceand production, which were planning, developing,or already introducing workflow applications. Inorder to achieve comparable results, the investi-gation of the different workflow projects followeda common method.

The studies are organized in three steps: survey,modelling, and analysis. The survey step centresaround interviews, with typical questions like‘Which were the main objectives/results for/ofyour workflow project?’, ‘What kinds of activitiesdid you carry out?’, ‘What kinds of problemsoccurred, and how did you manage them?’ and‘In a follow-up project, which parts of yourdevelopment procedure would be subject tochange?’. The information gathered is structuredand serves as input for the next step, the modellingstep. Its purpose is to compare the different

* The case study was conducted within the co-operative projectMOVE (Hermann et al. 1998) which is funded by the GermanMinistry of Education, Science, Research and Technology(BMBF).

Practice Section Improving Workflow Application Development Processes

development processes, using a development pro-cess model for each case. The analysis step aimsat identifying the relationship between the mainproblems encountered and the way workflowapplications have been developed. The detectedrelationships are described textually, to serve asinput for the development methodology. We nowsketch key properties of these projects (Goesmannet al. 1998).

Project 1 was carried out by a telecommunicationsservice provider. The project focused on the devel-opment and introduction of a workflow applicationfor a core business process including the integrationof several legacy applications. Due to severalproblems which were identified during the devel-opment, the project was delayed considerably. Themain issues encountered during this project arereviewed below. A logistics services companyinitiated a workflow project aiming at the improve-ment of customer service processes, hereafterreferred to as Project 2. That workflow project wasconducted using traditional software engineeringtechniques. When the system was operational,severe performance problems were encountered.As a result, the workflow management system wasremoved from the system architecture, and anew version of the application was built withoutworkflow management technology. In Project 3,another logistics enterprise planned a workflowmanagement application for an order processingbusiness process. This project also suffered fromdelays, caused by integration problems. In parti-cular, the requirements of existing legacy appli-cations were not identified in early project phases,which caused considerable development overheadin later phases. In Project 4, a manufacturingcompany started a project to deploy a productionplanning and controlling system in an enterprise.In the following project phase business processesthat are suitable for workflow management tech-nology were identified. Project 5 was carried outby an insurance company to evaluate workflowmanagement technology with a prototypical appli-cation. During the development of the prototype,severe runtime problems were identified. Finally,the company decided not to use a workflowmanagement system for the development of theapplication. Project 6 focused on the introductionof a SAP R/3 application in an optical engineeringenterprise. Several of the R/3-supported businessCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

37

processes will be performed using a workflowmanagement system in the next years.

By examining the different development pro-cesses and the problems encountered, we are ableto identify two classes of relationships: the firstclass combines those cases, where the problem candirectly be shown by the existence or by the causalorder of development activities (Problems 1 to 3,see below); the second class consists of cases inwhich specific problems occurred during oneparticular activity (Problems 4 to 6). This distinctionis important for the treatment of the problems bythe reference development process model, as willbe discussed below.

Problem 1. The organizational and technicalperspectives of the workflow schemas haveoften been worked out independently.

Organizational and technical perspectives dependon each other strongly, because there are technicalconstraints (like integration of legacy systems)which have a strong influence on the design oforganizational structures. An important flavour ofthis problem is the modularity of legacy appli-cations. Often these applications have a muchcoarser granularity than required by the workflowapplication. These properties of existing infor-mation systems have to be taken into account inan early project stage. We remark that in one of theexamined workflow projects, Problem 1 required acomplete redesign of the organizational model,which caused a considerable delay in the project.

Problem 2. In most cases, the selection of aworkflow management system was done ina very early project state.

The workflow projects examined spent differentamounts of time and cost in selecting a workflowmanagement system. Interestingly enough, systemselection was among the earliest phases in themajority of the projects. In most projects, the earlyselection has been identified as one of the mainsource of problems, since the selected workflowmanagement system could not support the specificrequirements needed in the respective project.When the deficiency of the selected system wasdetected in a later state (often only duringimplementation phases), work-around solutions


had to be developed in order to fulfil the needsrequired by the application.

Problem 3. The development process has beendone without prototyping.

Only in one project, a prototype of the targetapplication was developed. In most cases, prototyp-ing was either not considered necessary fordeveloping the workflow application or it wasomitted due to project delays. It turned out,however, that prototyping is a very helpful activityin building workflow applications. The mainreasons are as follows. First, the organizationalrequirements of the business process can be vali-dated in prototypes by the users of the system. Itturned out that system usability and front-enddesign are important factors for the acceptance ofthe new technology by the workflow participants.Secondly, technical restrictions can be tested in anearly project stage, which can save considerableresources in later project stages.

Problem 4. An automatic transfer of businessprocess models into workflow schemasproved to be unsuitable.

If business process modelling and workflow model-ling were carried out with different tools, anautomatic transfer of the business models intoworkflow schemas led to unacceptable results. Webelieve that a fully automatic transformation ofbusiness process models into workflow schemas isnot feasible since they focus on different aspects.In particular, business process modelling treats indetail the demands of the application from anapplication-oriented, i.e. from a business, point ofview, whereas workflow modelling focuses on thetechnological aspects of the application processand its organizational and technical environment.As a result, these domains are typically coveredby different people using different terminology,i.e. business terminology versus information sys-tems terminology.

Problem 5. The integration of legacy systemswas a critical factor for the success of work-flow projects.

In all case studies, the integration of complexlegacy systems was necessary. In none of theCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

38

examined projects only simple applications likeoffice systems had to be integrated. Besides, in allcases application integration was considered to bea critical success factor, since a re-implementationof legacy applications was not an option.

Problem 6. Severe performance problems couldbe identified during the field test phase.

During field test, every company of our surveyhad considerable problems regarding the perform-ance of the workflow management application ifthe application had to cope with a large numberof users and workflow cases. In one case theapplication was lacking reliability, too. Althoughthe integration of the legacy systems could beidentified as one cause for these weaknesses, theworkflow management systems were to a largeextent responsible for the technical problems.

3. DEVELOPMENT METHODOLOGY

To clearly organize the phases and activitiesinvolving the development of workflow appli-cations, this section presents a development meth-odology. We structure development processes byintroducing the notion of a phase. A phase definesa time interval during which particular activitiesare performed.

Typically, phases consist of related sub-phasesor activities, which are carried out by a group ofpersons, using a set of input documents anddeveloping a set of output documents. We stressthat our understanding of a phase requires creativework performed by people and, thus, cannot beperformed automatically (Holten et al. 1997). Ratherthan presenting a formal method for describingdevelopment models, we use a rather informalnotation, in which phases are represented by boxes,and informational and/or causal constraints aredescribed by directed edges. Despite being ratherinformal, the development methodology remindsworkflow project planners and managers to planand conduct workflow development projects. Theoverall WADP development methodology is shownin Figure 1.

The development methodology starts with aSurvey phase. In this phase, the goals of the projectare defined, the project team is established, andinitial information on the application environment


Figure 1. Development methodology for WADP

is gathered. The project managers then decidewhich business processes will be selected. Themain result of the Survey phase is a reviewed as-is business process model. The Design phase isnext, in which the developed model is analysedand optimized to reflect the overall goals of thebusiness, specified as a to-be business processmodel. (We remark that while business process re-engineering techniques are outside the scope ofthis paper, the development methodology can beenhanced such that these techniques are conductedwithin the development process.) Based on the as-is business process model, the project managementdecides whether workflow technology is adequateto support the requirements of the business processunder investigation. If so, a suitable workflowmanagement system is selected based on therequirements specified in the to-be business processmodel (System Selection), and the Implementationphase starts. The Test phase is next, which includeslab test and field test, as refined below. If the testsare successful, the Operational phase is reached.

We remark that the sequential processing of theCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

39

phases represents an ideal situation, which mostlikely will not be appropriate in most workflowprojects. To capture typical exceptions in thedevelopment process, we introduce additionaledges, e.g. we permit certain phases or sub-phasesto be re-performed during the development process.Defining and controlling the conditions underwhich development phases can be iterated is animportant task of the project management, andit can be assisted by the WADP developmentmethodology. We denote the property to step backin previously conducted phases as evolutionary,since development steps may iterate, incrementallyimproving the artefacts, for instance, businessprocess models and workflow schemes. In doingso, a high degree of flexibility in developingworkflow applications is provided. By definingpossible iteration structures, the development meth-odology helps in ruling out jumps that are notmeaningful. We mention that the evolutionarystructure is present both within phases and betweenphases. As will be discussed in the remainder ofthis section, we define potential back jumpsbetween sub-phases of different phases, e.g. aback jump from the Test phase to the SystemSelection phase.

3.1. Survey Phase

The overall goals of the Survey phase are twofold.First, initial information on the domain is gatheredto decide which business processes should besupported. The second goal of this phase is todevelop a reviewed as-is business process modelof the selected processes which contains bothorganizational and technical information (Figure2). Technical issues should also be taken intoaccount in this early phase in order to identifypossible restrictions due to limitations of theinformation systems to be integrated. In particular,legacy systems may pose specific requirements fortool integration. The Survey phase starts with aninitial survey of the business process on an abstractlevel in order to get an overview of the processand the roles and departments involved. The teamset-up for the Survey phase is done based onthis information by identifying the persons toparticipate in the detailed survey. For example,this first activity can be carried out in an initialmeeting with the project management.

The next activities comprise a closer look at both


Figure 2. Survey phase

the organizational structure of the company andthe documents. This information is helpful forthe process selection step, in which the relevantapplication processes are selected. In addition, thisinformation is useful for the preparation of thesurvey team kick-off meeting. In this meeting, theoverall goals of the project, the characteristics ofthe approach used, the processes to support, andthe following activities are presented to the teammembers in detail. We stress that a strong partici-pation of the employees involved is a key factorfor the quality of the business model and, eventu-ally, for the success of the project.

After the modelling method for the businessprocess model is selected, the main activity of theSurvey phase, the detailed organizational survey,is carried out. There are several options to obtain therelevant information in this sub-phase. (Adjacentboxes reflect a strong binding; typically the activitiesare executed concurrently, the persons collaborateclosely and share intermediate results.) Interviewswith survey team members are a costly but effectivemethod to get detailed knowledge on certainCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

40

activities within the business process. We stressthat a detailed analysis of the documents is suitablein most cases. The detailed survey yields an initialversion of the as-is business process model. Ifinformation is missing or ambiguous then thecorresponding parts of the detailed organizationalsurvey activity have to be repeated. In any case,the technical infrastructure of the company isanalysed. The business process model is thenextended with these aspects.

When a complete version of the as-is businessprocess model is created, a review meeting withthe entire survey team is carried out. The processmodel is presented to the team and discussedwith the team in order to eliminate potentialinconsistencies. Either these inconsistencies can beclarified in the meeting or the survey processiterates, and a new version of the process modelis developed after another organizational surveyactivity. The new process model is again discussedin a review workshop. If all team members agreeon the as-is business process model, the Surveyphase is completed.

3.2 Design Phase

As we have mentioned before, the Design phaseaims at analysing and optimizing the as-is businessprocess model. For that reason, this model servesas an input for this phase. The first set of activitiesdeal with organizational and technical modellingof the so-called to-be business process model,which represents the optimized business processwhich will be supported by the new application(Figure 3). The organizational part can be subdiv-ided into three sub-activities: process modelling;organizational structure modelling, and data mod-elling.

Besides organizational properties, technical fea-tures like the infrastructure, applications and thearchitecture should be reflected in the to-be businessprocess model. Organizational and technical to-bemodelling should be carried out in an iterativeway, so that the strong dependencies betweentechnical and organizational perspectives can betaken into account. At this point, fundamentalknowledge on the business process is available.Using this knowledge on the process and on theorganizational and technical environment in whichthe business process is performed, the team decidesif workflow is an adequate technology to support


Figure 3. Design phase

the process. This is done in the technology/workflow method selection box. If so, an appropri-ate workflow method is selected, and the appli-cation development process continues as describedin the development methodology. If, however, theproject management decides that workflow is notadequate, then the information gathered so far canbe used as input for traditional software develop-ment.

A second set of activities during this phase arecombined into to-be workflow modelling. We havealready described the distinction between businessprocess models and workflow schemas. The to-beworkflow modelling activity is subdivided intoworkflow process modelling, organizational model-ling and data modelling. The output of this activityis a workflow schema which reflects the contentsof the to-be business process model, enhanced byCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

41

workflow-specific features. Since the workflowmanagement system is not yet selected in thisphase, a method for building the workflow schemamust be chosen beforehand. An automatic transferof business models into workflow schemas is notsuitable in most cases (Holten et al. 1997), soappropriate resources should be provided for theto-be workflow modelling activity.

After the workflow modelling step has broughtout its product (i.e. the workflow schema), a reviewactivity can be carried out. Changes or newrequirements may concern the business processmodel or the workflow schema, making it necessarythat both business process modelling and workflowmodelling can follow this review. The reviewactivity may show that not enough informationwas gathered in the Survey phase. In this case,the WADP may re-perform parts of the Survey


phase; in particular, the detailed organizationalsurvey activity can be entered again to get themissing information, as shown in Figure 2.

3.3. System Selection and ImplementationPhases

During the Design phase, the to-be workflowschema is developed. The main purpose of theSystem Selection phase is selecting a workflowmanagement system, which is appropriate for theworkflow application under development (Figure4).

As was discussed in Section 2, one of the mainreasons for failing workflow projects is due toselecting an inadequate workflow managementsystem. Among the potential reasons for thissituation is selecting the system too early, since

Figure 4. System selection and implementation

Copyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

42

little or no information on the business processmay be available by that time. Consequently, it isimpossible to choose a system according to thespecific needs of the workflow application. Thispoint is important for the success of workflowprojects, since the workflow management systemscommercially available today differ considerablywith respect to their functionality. The selectionprocess starts with defining criteria for selectingan appropriate workflow management systembased on the business process model as specifiedin the Design phase. Obviously, there is a myriadof criteria to select a suitable workflow managementsystem, some of which are discussed now. Thefollowing set of criteria are relevant in the SystemSelection phase.

Integration criteria specify application and dataintegration aspects. In particular, the data structuresand types of application systems which can beintegrated in the workflow application are takeninto account. We remark that these are importantcriteria, since the success of a workflow projectmay rely on the integration of existing, domain-specific applications, which typically have beendeveloped independently from workflow appli-cations. Interaction criteria deal with the questionwhether the user interface of the workflow manage-ment system is adequate for the users and thetasks to be supported. In particular, can it becustomized to the specific needs of the application?Does the workflow client application have adequatenotification mechanisms, like push (the systemactively notifies the client) and pull communication(the client retrieves next workflow activities fromthe system)? Development criteria include theexpressiveness of the workflow language underly-ing the workflow modelling tool, e.g. is it possibleto express control flow, data flow and alternativeexecution paths, and other, application-specificproperties? In addition, are there powerful simul-ation and test facilities present? Does it supportflexible support for maintenance procedures andsecurity and integrity constraints that are requiredby the application? Runtime criteria deal with thequestion whether the system provides adequatefunctionality for the end-user as well as modellingand monitoring functionality for process designersand process managers. In addition, is the workflowsystem able to process the load expected for theapplication, i.e. does the system scale? Finally,general criteria include questions of whether the


system is available for the platform that is alreadyinstalled in the organization as well as issuesrelated to the reputation and product strategy ofthe vendor and reference installations.

Based on these criteria, using market analysisdata, an initial set of appropriate systems can bedefined. However, if the systems available do notmeet the criteria (or the systems cannot be usedin the particular setting) then the selection criteriahave to be re-defined. When a system is foundthat satisfies the criteria, it is tested against therequirements of the application. We stress that thisactivity may also lead to the re-definition ofthe criteria.

When the system tests are successful then areview meeting is carried out in which the finaldecision on the system to be used is taken. If thekey requirements of the application are availablebefore the Design phase is completed, the SystemSelection phase can start before business modellingis completed. This usually saves considerableamounts of time, especially if the systems to betested require time to get hold of, to install, andto test. The Implementation phase is based onthe to-be workflow schema and the workflowmanagement system selected. Broadly speaking,this phase contains two major activities, oneof which deals with the implementation of theworkflow schema according to the formalisms andrules provided by the selected system. As is shownin Figure 4, this activity deals with specifyingprocess models, data models and organizationalmodels. The second activity in this phase isconcerned with tool integration, i.e. the integrationof external applications as specified in the workflowschema is performed. Depending on the supportprovided by the selected system, this activity mayinvolve a considerable amount of coding andextensive testing. In case of problems, the respectiveactivities are re-performed. This process continuesuntil the workflow implementation and the toolintegration meet the requirements imposed by theto-be workflow schema. Finally, a review combinesthe results from the two activities. As specified inthe figure, this process may iterate. This phaseresults in a workflow application, which is testedextensively in the next phase, i.e. the Test phase.

3.4. Test Phase and Operational Phase

The Test phase comprises the two sub-phases LabSimulation and Field Test. Overall goal of the TestCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

43

phase is to obtain information about the technicalstability and the organizational suitability of theworkflow application (Figure 5). The first task inthe Lab Simulation defines the simulation goals.This task directly depends on the to-be workflowschema created in the Design phase. The secondtask defines the test scenario. The test scenariodefines the business processes and workflowswhich shall be tested. This means that the amountof data and the relevant business tasks are definedand that time restrictions are also specified. Now,test routines have to be developed, the lab simul-ation is conducted, and its results are analysed. Ifsimulation analysis indicates that further simulationgoals are of interest, another iteration of this sub-phase is started. Redefinitions of the test scenariomay also be necessary. Notice that the simulationresults by themselves can indicate that a re-implementation of the to-be workflow model isrequired. In this case, the implemented workflowapplication is not suitable for the given businessapplication. If on the other hand the lab simulationfinishes successfully, a Field Test can start.

The Field Test is performed to show that theworkflow application is able to handle real-worldsituations, characterized by problems which (atleast partially) cannot be planned or predictedbeforehand. Therefore, the application is testedagainst real-world conditions. After defining thegoals of the Field Test, the business processes tobe tested are selected. For each such process, abackup solution must be provided to cope withpotential error situations. Meanwhile, theemployees involved in the tested processes haveto be trained on the new workflow application. Atthis point, the new system and the backup systemhave to be installed in the target environment.When the training is completed and the backupsolution is (tested extensively and) safe, the FieldTest can be performed. After its completion, thetest data generated will be analysed, which mayeven result in the definition of new test goals orwhich may show new requirements influencingthe selection of critical processes. This processcan iterate, such that the Field Tests becomeincreasingly accurate.

We remark that the Field Test may even showthat the to-be business process or workflow schemasare not suited. In this case, the respective phases(Design, Implementation) are entered again; itmay occur that the workflow management system


Figure 5. Test phase

selected is not able to handle the current situation,in which case the System Selection phase isreperformed. Typically, a demo license of a work-flow management system is used until the Oper-ational phase begins, to limit cost if the Field Testresults in a change of the selected system. Thereview activities in this phase may show severeproblems, resulting in stepping back into theDesign, System Selection, or Implementation phase.

The Operational phase comprises the sub-phasesInstallation and Run-Time as well as a set-upactivity, in which the technical environment forthe deployment of the workflow application isprovided. The completion of this activity and thesuccessful completion of the Field Test allow theCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

44

start of the Installation phase. Without going intothe details of this phase, the Installation sub-phaseincludes data migration and user training activitiesand the system deployment in the target setting,while the runtime sub-phase is characterized byperforming the daily business of the organizationusing the new workflow application, includinggathering workflow execution data which can beused for continuous process improvement tasks.

4. CONCLUSIONS

We conclude by discussing how the developmentmethodology helps in coping with the real-world


problems mentioned above and by providing abrief summary.

To take care of the strong dependencies betweenthe technical and organizational parts of the to-bemodels (Problem 1), the development methodologysuggests that organizational and technical to-bemodelling should be done collaboratively, and thatthe activities should exchange information. This isdone in the Design phase, where the sub-phases,dealing with organizational and technical model-ling are performed in an integrated way, i.e. theyare performed concurrently, and they exchangeinformation. In addition, multiple iterations of themodelling phases may lead to a concise andintegrated model which represents both aspectsproperly. System selection was often carried outin early project stages, resulting in Problem 2. Inthe proposed development methodology, systemselection is based on the to-be business model,which is created during the Design phase. Hence,the specific properties of the workflow applicationare known when the workflow management systemis selected. This information can be used to selecta system which is capable of supporting thisstructure. In general, the functional requirementsof the application are known when the system isbeing selected, which may lead to selecting moreadequate system and, eventually, to better work-flow applications. The development of prototypeswas identified as an important factor for the successof a workflow project (Problem 3). We did notdefine a separate prototyping phase in our model.Instead, prototyping is reflected by the evolutionarycharacter of the overall process and by a dedicatedField Test phase. An automatic transfer of businessprocess models into workflow schemas proved tobe unsuitable in most cases (Problem 4). Hence,the development methodology contains explicitsub-phases for business process modelling andworkflow modelling. We stressed that the inte-gration of legacy systems is a critical factor inworkflow projects (Problem 5). For this reason, theSurvey phase contains activities in which thecharacteristics of legacy applications are analysedin order to identify possible restrictions concerningthe integration aspect. Also, we suggest the defi-nition of corresponding test scenarios in the Testphase. Many of the workflow management systemsavailable are lacking performance and reliability ifthey have to cope with a large number of usersand workflow cases (Problem 6). Our developmentCopyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

45

methodology helps in dealing with this issue byproviding elaborated System Selection and Testphases. We stress that performance and reliabilityshould always be a key factor when conductingthe different lab simulations in the Test phase.

To wrap up, in this paper we investigateworkflow application development processes. Bymodelling and analysing workflow applicationdevelopment processes, the understanding of theseprocesses can be enhanced and, finally, workflowapplication development can be improved. Whilethe proposed development methodology isdesigned to avoid a number of problems relatedto workflow projects, not all potential problemsare solved by it automatically; in workflow projects,there is no substitution for knowledgeable projectmanagers, skilled developers and efficient users.However, given that ‘models are not right orwrong, they are more or less useful’ (Fowler 1997),we believe that our development methodology isindeed useful and can assist workflow projectteams in developing more useful, more reliable,and better workflow applications.

REFERENCES

Boehm B. 1981. Software-Engineering Economics. PrenticeHall: Englewood Cliffs, NJ.

Fowler M. 1997. Analysis Patterns: Reusable Object Models.Addison-Wesley: Reading MA.

Georgakopoulos D, Hornick M, Sheth A. 1995. Anoverview of workflow management: from process model-ling to workflow automation infrastructure. Distributedand Parallel Databases 3: 119–153.

Goesmann T, Striemer R. 1998. Development of workflowapplications in commercial settings: experiences andconsequences (in German). Technical Report ISST-Bericht44/98, Fraunhofer ISST Dortmund.

Herrmann T, Scheer AW, Weber H (eds). 1998. Improve-ment of Business Processes with Flexible Workflow Manage-ment Systems (in German). Volume 1. Physica: Berlin.

Holten R, Striemer R, Weske M. 1997. Comparingapproaches to develop workflow applications (inGerman). In Software Management, Oberweis A, Sneed H(eds), Teubner: Stuttgart, 258–274.

Leymann F, Altenhuber W. 1994. Managing businessprocesses as an information resource. IBM Systems Journal33: 326–347.


Weske M, Goesmann T, Holten R, Striemer R. 1999. Areference model for workflow application developmentprocesses. In Proceedings of International Joint Conference

EDITOR’S COMMENT

Workflow projects indicate some specific aspects regarding the underlying software process. In order tohandle organizational complexity as well as technological risks, the development process should providea suitable set of activities, closely interrelated to each other. The authors derive these activites from anumber of case studies, with a strong focus on the problems which occurred during some real worldprojects. This problem driven approach leads to a pragmatic process model, in which prototyping playsan important role for the success of workflow application development processes. It may help reducingthe risks, which are still involved in large workflow projects.

Copyright 2001 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2001; 6: 35–46

46

on Work Activities Coordination and Collaboration(WACC), Georgakopoulos D, Prinz W, Wolf AL (eds).ACM: 1–10.

analysing, modelling and improving workflow application development processes

Documents