BIS'99 Springer London Berlin Heidelberg New York Barcelona Hong Kong Milan Paris Santa Clara Singapore Tokyo Witold Abramowicz and Maria E Orlowska (Eds) BIS '99 3rd International Conference on Business Information Systems, Poznan, Poland, 14-16 April 1999 Springer Witold Abramowicz Professor Department of Computer Science, The Poznan University of Econo mics, Pola nd Maria E Orlowska, Osc, Professor Department of Computer Science and Electrical Engineering, The University of Queensland, Australia ISBN 978-1-85233·167·2 Springer·Verlag London Berlin Heidelberg British Library Cataloguing in Publication Data BIS'99: 3rd International Conference on Business Information Systems, Potnan, Poland, 14·16 April 1999 l.lnformation storage and retrieval systems · Business· CongreMes I.Abramowia, Witold II.Orlowska, M E (Maria E.) lIl.lnternational Conference on Business Information Systems (3rd: 1999: Poznan) 025'.06658 ISBN·i3: 978-1-85233·167·2 e ISBN·13: 978·1-4471-C87S-7 DOl: 10.1007/ 978·1-447W875·7 Library of Congress Cataloging in Publication Data A catalog record for this book is available from the LibraryofCongress Apart from any fair dealing for th e purposes of research or private study, or criticism or review as permined under the Copyright, Designs and Patents Act 1988 this publication may only be reproduced stored or transmined, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms of licences issued by the Copyright Licensing Agency Enquiries concerning reproduction outside those terms should be sent to the publishers © Springer.Veriag London Limited 1999 The use of registered names, trademarks etc in this publication does not imply even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use The publisher makes no representation, express or implied, with regard 10 the accuracy of the information contained in Ihis book and cannot accept any legal responsibility or liability for any errors or omissions that may be made Typesetting: Camera ready by contributors 34/3830·543210 Telekomun ikoc io Polsko S.A , Poland's notional telecom operator, i s the largest flower in Poland ' s carparate garden How large exactly? We ll, our cap ito l base is over 30% bigger than the sum of all the other compan ies on the Polish Stock Exchange Combined Our recent privotisotion attracted investors from Poland and overseas and was healthil y oversubscri bed And our results reflect our ambitions: a customer bose that 's growing at a rate of 14% a year; on investment programme that has already yielded lightning developments in the areas of ISDN, Internet and data transmissions services Of course, there's also the small matter of profits A large matter, in our case In 1996, net profits were 758 million zloty In 1997, 1350.6 million zloty Rosy figures, we think you' ll agree T£LEKOMUHII(.>.CJA I'OLSI(.> LA -$ , The odver1lse m.nt I'\os b n (JIved by TP SA and appro d by J Henry Sch.od & Co L,d J HenlY Sch.od & Co L,d " ,.gulo.od by ,he Sf and IS tn Global Coordlr\Otor o ~ 800ktunner ," th I"Ihol publ" off rlng of SA ', ordinary thor and GOR,- 'P Preface Welcome to BIS'99! Business Information Systems 99 is an international conference being held for the third time BIS'99 aims to discuss the development, implementation, application and improvement of computer systems for business processes It is addressed to the scientific community, people involved in the development of business computer applications, and to consultants helping to properly implement computer technology and applications in industry Over 50 selected papers will be presented at BIS'99 during the scientific and practical sessions The papers deal with a variety of topics related to computer systems in management, from the point of view of their application (e.g., electronic commerce), their business or industrial users (e.g., business process re-engineering), and technology (e.g., data warehousing) The submitted papers underwent a rigorous reviewing process, and the resulting program should provide an outstanding representation of international research in this area We believe that BIS'99 will provoke some interesting international discussion amongst participants, particularly as this meeting includes a number of invited lectures by international experts in the area The BIS'99 international Program Committee was composed of 53 scientists from diverse locations - from the USA to Australia, from countries with a stable economy through to those undergoing economic transformation This aspect further helps to enrich the conference program BIS'99 will be held on the premises of the Poznan International Fair during INFOSYSTEM - the most important trade fair of all the electronics, telecommunications and computer engineering events organized in Poland This is another excellent opportunity for BIS'99 participants to observe the current market on offer of computer hardware and software We wish to express our gratitude to all those individuals and institutions who made this conference possible: to the authors of papers for their contributions, to the Program Committee members and the additional referees for carefully reviewing the submissions, to the keynote and invited speakers for kindly VIII accepting our invitation, and to all the members of the Organizing Committee, with special thanks to Danuta Nowacka, Mahmoud Fagir, Pawel Jan Kalczynski, Krzysztof Wecel and Przemyslaw Grzeszczak from The Poznan University of Economics, Poland and who has proved to be the "heart and soul" in the local organization of BIS'99 Additional thanks are due to Kathleen Williamson of The University of Queensland who has provided valuable help in the preparation of the proceedings, and Rebecca Moore at Springer Verlag for her help and advice Finally, but very importantly, our gratitude goes to the Sponsors for their involvement and valuable support, specially for Telekomunikacja Polska S.A We thank everyone involved for the work they have put in to bring together such an interesting program, and we look forward to sharing this with all participants We look forward to welcoming you to Poznan in April Wit old Abramowicz and Maria E Orlowska Program Committee Co-Chairs, BIS'99 Table of Contents Inauguration Session Building a Case for Consonance Gary Klein, James J Jiang, Michael Boyd The Impact of Time Pressure on Idea Generation Robert M Myers, Jay E Aronson, Robert B Wharton 13 A Discussion on Process Losses in GSS: Suggested Ground Rules for the Electronic Environment Wm Benjamin Martz, Jr 24 Suggestions for Improving the Diffusion of GroupSystems in Organizations Morgan M Shepherd 35 Facilitating and Coordinating Distributed Joint Applications Development James Suleiman, Roberto Evaristo, Gigi G Ke/ly 45 Knowledge Management Information Systems in Customer-Oriented, Dynamic Environments: The Marketplace as a Metaphor Peter C Lockemann' 55 Knowledge Management: Life Cycle and Implementation Techniques August- Wilhelm Scheer, Ursula Markus 76 Utilising Knowledge Resources: An Activity Perspective of Knowledge Management Henry Linger 86 The Strategic Role of Marketing Information Systems in Modern Business Jacek Unold 103 Internet Software Engineering on the Web Joseph E Urban 113 Data Warehousing Data Warehousing Beyond Tools and Data: Justification, Organization, and Structured Development of Data Warehousing Applications Robert Winter 125 x To the Stars through Dimensions and Facts jaroslav Pokorny 135 Generating Sample Data for Mining and Warehousing josef Schiefer, A Min Tjoa 148 Data Mining and Knowledge Discovery in Business: Past, Present, and Future Zdzislaw S Hippe 158 From Economical Theory to Management Systems On the Difficulties of Cost/Benefit Analysis: What Management is Buying when Buying Information Technology Systems Kenneth Wong, Wita Wojtkowski 173 User Preferences in Evaluating Usability of Software Product: A Multicriteria Approach Marcin Sikorski 182 Business Process Re-engineering Re-engineering: Problems with Theory and Practical Application jerzy Kisielnicki 191 Flexible Business Process Models and their Application Christian Mittasch 203 Business Processes Based Information Systems Development Vaclav Repa 216 Database in SupPort of BIS Towards Exploitation of the Data Universe - Database Technology for Comprehensive Query Services Klaus R Dittrich, Ruxandra Domenig 231 Prototype Validation of the Rectangular Attribute Cardinality Map for Query Optimization in Database Systems Murali Thiyagarajah, B john Oommen 250 Workflow Management Issues Time Management in Workflow Systems johann Eder, Euthimios Panagos, Heinz Pozewaunig, Michael Rabinovich 265 On Capturing Process Requirements of Workflow Based Business Information Systems Wasim Sadiq, Maria E Orlowska 281 Author Index 295 List of Authors Aronson Jay E Department of Management Terry College of Business The University of Georgia Brooks Hall Athens, USA e-mail: jaronson@blaze.cba.uga.edu Boyd Michael School of Business The University of Texas of the Permian Basin Odessa, USA e-mail: boyd_m@utpb.edu Dittrich Klaus R Department of Information Technology University of Zurich Zurich, Germany e-mail: dittrich@ifi.unizh.ch Domenig Ruxandra Department of Information Technology University of Zurich Zurich, Germany e-mail: domenig@ifi.unizh.ch Eder Johann AT&T Labs - Research Florham Park, USA e-mail: hans@research.att.com Evaristo Roberto College of Business Information Technology and Electronic Commerce Department University of Denver Denver, USA e-mail: evaristo@du.edu Hippe Zdzislaw S Department of Computer Chemistry University of Technology Rzeszow, Poland e-mail: zshippe@prz.rzeszow.pl Jiang James J Department of Computer Information Systems College of Administration and Business Louisiana Tech University Ruston, USA e-mail: jiang@cab.latech.edu Kelly Gigi G School of Business Administration The College of William & Mary Williamsburg, USA e-mail: ggkell@business.wm.edu Kisielnicki Jerzy Warsaw University Faculty of Managemaent Warsaw, Poland e-mail: jkis@wspiz.edu.pl Klein Gary College of Business and Administration The University of Colorado, Colorado Springs, USA e-mail: gklein@mail.uccs.edu Linger Henry School of Information Management & Systems Monash University Caulfield East, Victoria, Australia e-mail: henry.linger@sims.monash.edu.au On Capturing Process Requirements of Workflow Based Business Information Systems* Wasim Sadiq and Maria E Orlowska Distributed Systems Technology Centre Department of Computer Science & Electrical Engineering The University of Queensland Australia email: {wasim.maria}@dstc.edu.au Abstract The workflow technology manages the execution of business activities and coordinates the flow of information throughout the enterprise It is emerging as one of the fastest growing disciplines in information technology It is essential to correctly and effectively capture the workflow specific requirements of business information systems before their deployment through workflow management systems In this paper, we look at different issues in capturing such requirements and propose a systematic layered modeling approach We split the workflow specification requirements into five basic dimensions: structure, data, execution, temporal, and transactional The concepts introduced in this paper have been applied as a foundation to t~e development of a workflows modeling and verification tool, FlowMake Introduction The past few decades have witnessed a tremendous growth in business process automation It is essential to understand the operations of business processes before any information systems are developed and implemented For this purpose, business data and process modeling methodologies are used Data requirements are modelled through conceptual data modeling methodologies like entity-relationship, and process modeling methodologies like data flow diagrams, are used to identify business processes and capture the flow of information between them Organizations are partitioned into several functional areas and information systems are deployed for each of the divided areas Activities within a functional * The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of the Commonwealth Government of Australia W Abramowicz et al (eds.), BIS ’99 © Springer-Verlag London Limited 1999 282 business area are either manual, automated, or a combination of both For large organizations, the systems supporting the functional areas run in heterogeneous and distributed hardware and software environments Generally, each system itself is also developed following a modular approach The related modules and systems must communicate and coordinate with each other to effectively achieve their functional objectives The coordination of these automated or manual activities has historically been performed manually In recent years, the possibility of automating such coordination is being explored through workflow technology The Workflow Management Coalition [14] defmes workflows 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." Workflows represent the organizational flow of information from one processing entity, either manual or automated, to another The processing entities use this information to accomplish assigned tasks These tasks take some information from the preceding tasks, perform some work based on the information received using the services of the assigned processing entities, and proceed to the next task(s) in the workflow The on-line information management systems accomplish much more automation than their batch-oriented counterparts Sophisticated computerization provides further possibilities for automating the execution coordination Workflow management systems provide capabilities to partially or fully take over the responsibility for coordinated execution of workflow tasks from human coordinators The execution coordination involving tasks and processing entities is accomplished by enforcing associated business process rules and constraints Before a workflow management system can be deployed to manage workflows, process defmition tools are required to model workflow processes Information about the process rules and constraints is stored in the workflow repository The workflow management systems make extensive use of this repository in their operation On the basis of the process defmitions, workflow management systems create and execute workflow instances and coordinate the interactions between its tasks The workflow management systems promote a component oriented information systems development approach The workflow based information systems separate the process logic from application logic The process logic is implemented through a workflow management system and the application logic through underlying application components Whereas, in conventional information system both process logic and application logic are embedded into the same system This separation requires that at the time of capturing the requirements of information systems a clear distinction be made between these two types of requirements This paper is an attempt to provide a framework that helps in capturing the process logic requirements of workflow based information systems There are several workflow management systems in the market Most of these products also provide graphical tools and a variety of modeling languages to define workflows We believe, however, that there is a need to identify and systematically classify the issues that should be targeted during the workflow modeling process The major contribution of this paper is to provide a breakup of the modeling effort 283 into five intuitive phases Furthermore, we identify a means of capturing different requirements of workflow applications A CASE tool, FlowMake, for workflow modeling and verification has also been developed as an outcome of this work The FlowMake provides workflow analysts and designers a well-defmed framework to model and reason about various aspects of workflows Partitioning the Workflow Model The primary objective of a workflow management system is to coordinate the execution of activities or tasks in an organization Correspondingly, a workflow modeling framework should cover the techniques and tools to capture, analyze, and specify different aspects of tasks and their coordination Manipulate Tasks Perform Control Control Constraints Figure Workflows building blocks We divide a workflow application into four building blocks: objects, tasks, performers, and constraints The overall characteristics of these four components identify the nature ofthe application We use the keyword work to define these four building blocks: Work is performed on Objects An object is any entity of interest - Tasks specify the work to be done The work specified by tasks is generally performed on objects or on the basis of information contained in objects Performers carry out the work Tasks cannot perform the work themselves They need the services of performers Constraints control correct execution of the work Tasks specify what to and performers carry out that work The constraints ensure that the work is performed correctly The motivation of the work presented in this paper is to specify a framework for capturing the workflow specific requirements of a business information system In other words, capturing the essential information pertaining to the above mentioned four building blocks A workflow management system coordinates the execution of tasks Looking at Figure 1, we realize that this coordination is dependent on the constraints block The performers execute tasks conforming to the specified constraints As such, a primary objective of workflow modeling is to capture and ensure the correctness of these constraints 284 One way to enhance the understanding of workflow models and to reduce the complexity is to divide the modeling activity into phases By adopting a layered modeling approach, we can capture and analyze the modeling information for each of the phases Eventually requirements captured in all phases could be combined into an integrated workflow model Workflows Transactional Structure Data Temporal Execution Figure Partitioning the workflow model We propose to divide the modeling effort into five phases: structure, data, execution, temporal, and transactional In the following sections, we briefly explain the process information captured under each phase 2.1 Structure A workflow is a set of tasks that are performed to achieve some business objectives Generally, the tasks in a workflow are inter-related in such a way that the initiation of one task js dependent on the successful completion of a set of other tasks Therefore, the order in which tasks are executed is very important The first phase of this modeling framework captures the flow of execution from one task to another The structural modeling of a workflow defines the way a workflow management system would order and schedule workflow tasks This is the primary and perhaps the most important aspect of a workflow model and builds a foundation to capture other aspects of workflow requirements Generally, information modeling techniques include graphical representation that enhances the understanding of the model A workflow specification could also be represented using graphical objects In this section, we briefly describe the structural aspect of our workflow modeling language and its graphical representation This language is based on generic workflow modeling concepts as described in Workflow Management Coalition [15] For a more detailed description, the reader is referred to [13] The workflow models in this graphical language are modeled using two types of objects: node and control flow Node is classified into two subclasses: task and condition A task, graphically represented by a rectangle, represents the work to be done to achieve some objectives It is also used to build sequential, concurrency, and synchronization structures It is the primary object in workflow specifications 285 and could represent both automated and manual activities Tasks are executed by assigned performers A condition, graphically represented by a circle, is used to construct or-split and or-join structures A control flow links two nodes in the graph and is graphically represented by a directed edge By connecting nodes with control flows through five modeling structures, as shown in Figure 3, we build directed acyclic graphs (DAG) called workflow graphs where nodes represent vertices and control flows represent directed edges From now on, we will refer to vertices as nodes and edges as flows Synchronization Final Nesting Figure Workflow modeling structures Sequence is the most basic modeling structure and defines the ordering of task execution It is constructed by connecting at the most one incoming and one outgoing flow to a task A concurrency structure is used to represent concurrent paths within a workflow graph and is modeled by connecting two or more outgoing flows to a task At certain points in workflows, it is essential to wait for the completion of more than one execution path to proceed further A synchronization structure, represented by more than one incoming flow to a task, is applied to synchronize such concurrent paths A synchronization task waits until all the incoming flows have been triggered A choice structure is used to model mutually exclusive alternative paths and is constructed by attaching two or more outgoing flows to a condition object At runtime, the workflow selects one of the alternative execution paths for a given instance of the business process by activating one of the outgoing flows originating from the choice condition object The choice structure is exclusive and complete The exclusive characteristic ensures that only one of the alternative paths is selected The completeness characteristic guarantees that, if a condition object is activated, one of its outgoing flows will always be triggered A merge structure is "opposite" to the choice structure It is applied to join mutually exclusive alternative paths into one path by attaching two or more incoming flows to a condition object Since a workflow model is represented by a directed acyclic graph (DAG), it has at least one node that has no incoming flows (source) and at least one node that has no outgoing flows (sink) We call these initial andfinal nodes respectively To uniquely identify a final node for a workflow graph, we join all split structures Therefore, a workflow graph contains only one initial and one final node 286 A workflow instance completes its execution after its fmal node has completed its execution We need the iteration structure to model the repetition ofa group of tasks within a workflow The iteration is modeled through block structures As long as a certain condition is met, a sub graph of the workflow is repeated The nesting structure simplifies the workflow specifications through abstraction Using this construct, we can encapsulate a workflow specification into a task and then use that nested task in other workflow specifications For each execution of a nested task, the underlying workflow is executed The Workflow Management Coalition [15] identifies four primary workflow control structures: or-split, or-join, and-split, and and-join These are represented in our model through choice, merge, concurrency, and synchronization structures respectively We have the condition object to model the choice and merge structures However, the concurrency and synchronization structures are represented simply by directly connecting flows to tasks This approach reduces the number of modeling objects but at the same time allows explicit notation for workflow structural models Nevertheless, in certain cases, it requires the use of null tasks whose only purpose is the coordination of flow and compliance to the syntactical correctness criteria of workflow structures 2.2 Data The workflow tasks are generally defmed and executed outside the workflow management system The coordination relationship among these tasks is modeled through control flow specifications A data dependency may also exist between tasks that is not identified in control flow specifications A task T1 is called data dependent on another task T2 if, for its successful execution, it requires the data produced or provided by T2 Such a relationship is modeled by using a data flow that specifies the mapping between data provided by the T1 and received by T2 As shown in Figure 1, performers are responsible for task execution During task execution some objects are manipulated by tasks While the performers execute tasks they make use of or generate some data regarding the objects they work on Task Figure Task and performer data relationship 287 We classify such data in three categories: perfonner data, workflow data, and workflow specific perfonner data The peiformer data is generally invisible to the workflow application unless the perfonner makes it available to the workflow management system The workflow data is local to the workflow management system and is used for coordinating the task scheduling and execution A subset of workflow and perfonner data is common and called workflow specific peiformer data The workflow management system and the perfonners communicate with each other using this set of common data parameters This relationship is shown in Figure The structural and data aspects of a workflow model are significantly dependent on each other For example, the condition object needs the data parameters provided by a data flow to select the alternative path Similarly, a control flow path must also exist to satisfy a data flow constraint between two tasks We support the modeling of data flows through global workflow variables Each task has associated input and output containers The underlying application component of a task can read the variables in its input container and write into the variables in its output container The variables in these containers of a task are mapped to a subset of the global workflow variables, which are used to indirectly map the variables of one task to another 2.3 Execution Using the structure and data aspects of a workflow model, the workflow engine schedules appropriate tasks at different stages of workflow execution This scheduling activity is accomplished through the task scheduler that is a fundamental part of a workflow engine The task scheduler allocates the tasks to respective perfonners For task allocation, the workflow management system needs certain modeling infonnation for individual tasks that is captured by the execution aspect of the framework As shown in Figure 1, tasks are allocated to perfonners who in tum are responsible for carrying out the tasks We classify tasks into two categories: automated and human-oriented An automated task is perfonned completely and independently by a computer To execute such a task, the workflow management system would need information about the protocol to communicate with the underlying computer application A human-oriented is perfonned by humans and may also have an associated computing resource for accomplishing the task objectives For such a task, the workflow management system would also need infonnation about role and responsibilities of the person who would be executing the task As described earlier, we use the nesting structure to encapsulate a workflow into a task and then use that nested task in some other workflows The atomicity characteristic distinguishes between the tasks that could be decomposed into workflows and the tasks that could not be decomposed An atomic task is a single task from the point of view of a workflow management system A nested task encapsulates a workflow and the tasks in the encapsulated workflow have to be executed for the successful completion of the nested task It is possible to have an atomic task that 288 is more complex than a nested task It all depends on the workflow specifications However, as long as it does not decompose into a workflow, we call it an atomic task Under the scope classification, we have two types of tasks: external and internal Most of the tasks in a workflow specification belong to the first category An external task is any automated or manual activity that is performed to accomplish some business objective An internal task is a workflow management system activity that is performed to coordinate other external or internal tasks In some workflows, certain authorization may be required for task allocation The workflow application for such a process must have the ability to ensure that only the authorized performers execute the task Such authorization levels are also captured during the modeling of execution aspects Another important feature of workflows is distributed allocation of tasks to a group of performers Tasks use services of performers for carrying out their operations In a workflow application that involves a large number of humans as performers, effective task allocation policies are even more important For example, for a particular task there could be a group of performers who could perform the task There could be several considerations for allocating the task to a particular performer For example, we may want to maintain a balanced workload among performers These task allocation policies could be very complex and may involve many constraints It is important to capture and analyze the task allocation policies during the modeling process 2.4 Temporal The temporal aspects add another dimension to the scheduling of workflow tasks Without temporal constraints, a workflow task is initiated when its preceding tasks in structural specification have finished execution However, if any temporal constraints are specified, they must also be satisfied, besides other constraints, to successfully execute the task One may argue to include temporal constraints in execution partition However, in our opinion, these constraints are complex enough to be captured in an independent phase of workflow modeling In this section, we identify the types of temporal constraints that could be applied to workflow specifications At certain points in workflows, we may require a task to fmish by a specific deadline There is more than one way to specify such deadlines A task specific deadline does not depend on other tasks in the workflow We may specify that a task Tl must finish at a given time At the time of execution, if that deadline was reached and task Tl had not fmished its execution, the workflow engine would take appropriate actions The task specific deadline could be specified as a task property There could be two possibilities of specifying a task specific deadline The first type is specified at the initiation of the workflow that contains the task with deadline Such a deadline specification model the maximum time allowed for the workflow to fmish all the preceding tasks and the task with deadline specification The second type is specified at the time of the task initiation 289 and models the maximum time allowed for the execution of the task The task specific deadlines could be relative or absolute We can specify an absolute deadline irrespective of the current time For such a workflow, each instance would have the same task deadline as long as it is not changed at the workflow definition level Such deadlines are defined as workflow constants The relative deadlines are specified in relation to the current time An inter-dependent deadline introduces temporal dependencies between tasks For example, we may specify that task T2 must finish within a specified time after initiating or completing task Tl The workflow engine may have to finish several other tasks between Tl and T2 The temporal dependency is represented with the help of a temporal flow where the deadline constraint is attached to the flow Another type of temporal constraint is the wait constraint At particular stages of workflow execution, we may want to wait for a given time before proceeding Just like deadlines, this wait specification could either be task specific or inter-dependent A task specific wait specifies the time a task should wait for before starting its execution Just like deadline, this wait could be specified at the time of workflow initiation or task initiation The workflow initiation based wait models the minimum time allowed for the workflow to finish all the preceding tasks before starting or completing the execution of the task with wait specification The task initiation based wait models the minimum time allowed for execution of the task If the task finishes its execution before the wait time, it would wait before proceeding The inter-dependent wait introduces temporal dependency between tasks For example, we may specify that task T2 must not start or finish before a specified time after starting or completing task Tl The temporal dependency is represented with the help of temporal flow where the wait constraint is attached to the flow The workflows, with obligatory constraints must be able to handle any number of instances at a given time For example, the workflow to process the admission applications for a university has an obligatory constraint to process all the applications received These constraints, along with other temporal constraints, add to the complexity of workflow applications Other important temporal properties are the minimum, maximum, and average execution times for each task Such specification, along with deadlines, waits, and obligatory constraints are required to reason the feasibility and effectiveness of a workflow application In structural specification, we introduced the iteration concept that is based on some conditional value There is another possibility of iteration, called temporal iteration, that is modeled to repeat a task for a given time period Such a concept is very useful for transactional workflows, where we may want to model a task with time dependent redo properties in case of failures There are several other constraints like workload, availability and efficiency of staff, holidays, etc that may affect the timely completion of workflow tasks The identification of temporal constraints and associated bottlenecks during the modeling process is very important for workflows involving a large number of performers and expected instances 290 2.5 Transactional The concept of transactional workflows has been an active area of workflow research [2,9, 10] The difference between workflows and transactional workflows is similar to the difference between legacy applications based on flat sequential files and the applications developed using relational database management systems like Oracle The modern relational database management systems provide extensive transaction management features to ensure the consistent updating of databases and handling of system failures Similarly, transactional workflows extend the basic workflow model by introducing well-tested transactional features of the transaction management systems The concept of transactions is used in transaction processing systems to maintain the consistency of information systems in case of system and transaction failures and concurrent updates to the underlying database A Transaction conforms to the wellknown ACID (Atomicity, Consistency, Isolation, and Durability) properties Correspondingly, a transactional workflow management system should have facilities to define these transactional properties The concept of transactions fits beautifully within the database-oriented transaction management paradigm However, the transactional workflows for large enterprises involving heterogeneous and distributed environments may not meet the strict requirements of ACID properties [2] A database management system has to deal with computer programs and data only, whereas, a workflow management system deals with humans and manual activities as well Furthermore, not all the workflow processing entities may be based on database management systems supporting transaction management Therefore, a flexible transactional model is generally required for defining and managing transactional workflows The motivation behind modeling the transactional features of a workflow is to add the capability in the workflow to handle exceptional circumstances that would otherwise leave the workflow in an unacceptable state The transactional features of a workflow are handled by a workflow management system However, the workflow management system needs some information about transactional properties of the workflow tasks to control these features Two important transactional workflow concepts are abort and recovery A workflow starts its execution from a unique initial task and completes its execution after executing a final task During these two tasks, it may run several other tasks depending on the control flow specification Abort introduces an exceptional termination of the process during its execution There could be several reasons for abort For example, a system or application error could result into abnormal workflow termination It is also possible for the user to abort the workflow during its execution Recovery is the process of taking an aborted workflow from an unacceptable state to an acceptable state The way a system handles recovery depends on the underlying recovery mechanisms in the workflow management system In some cases of recovery, the system would need to undo the activities performed by some tasks For this purpose, during the modeling activity, we identify compensating tasks that are executed during recovery process to accomplish the task undo operations 291 Putting it all Together We have applied the framework for workflow modeling presented in previous section as a foundation for developing a CASE tool for workflow modeling and verification, FlowMake The layered approach of the proposed framework has been effectively applied in FlowMake Rather than modeling all the workflow constraints on a single graph, a workflow is partitioned into several graph layers, where the same tasks are presented with different partition related properties and constraints It is also important to note that although the workflow constraints could be partitioned into logical groups, inter-dependencies exist between them For example, the transactional specifications depend on the structural specifications An important and challenging aspect of the workflow modeling methodology and associated CASE tool is to ensure the consistency and reliability of the integrated workflow conceptual model p~ p~ ppP l&t"Sto< r 5Ioo r Figure FlowMake: Workflow Modeling and Verification Tool It is possible to easily get into error situations while building complex workflow specifications The identification of these errors is obvious and trivial for workflows that consist of only a few objects However, the verification of workflow conceptual specifications containing a large number of objects is known to be complex [8] 292 The extensive use of choice and concurrency structures in workflows and the overlapping data, execution, temporal, and transactional aspects further increase the complexity of some verification problems This inherent difficulty of manually verifying the correctness of workflows makes a strong case for the development of an automated verification engine Such an engine would become an essential component of a process definition tool for workflows The early detection of errors in workflow specifications during the modeling stage is of vital importance and facilitates the development of reliable and correct workflow applications The identification of a set of constraints for avoiding errors in workflow specifications is the first step towards developing a verification engine Some of these constraints have been identified in [l3] The implemented tool based on the framework presented in this paper, called FlowMake, provides workflow analysts and designers a well-defined framework to model and reason about various aspects of workflows It has been designed to augment production workflow products with enhanced modeling capabilities and to provide a basis for expanding the scope of the verification It attempts to identify inconsistencies in the model that could arise due to conflicting use of modeling constructs For example, it is possible that a particular instance of a syntactically correct workflow model stops executing before reaching and completing an acceptable fmal task because of a modeling inconsistency and thus terminating the workflow instance in an undesirable state FlowMake provides means to identify such problems in workflow models FlowMake is composed of four major components: the repository, the workflow editor, the verification engine, and the interface Repository maintains workflow models and has been implemented using relational technology Worliflow Editor provides a user-friendly graphical environment to maintain large workflow graphs It is also used to visualize inconsistencies in design Verification Engine implements the algorithms to check the consistency of workflow models Interface component provides linkage to workflow products through import and export of workflow models Presently, the tool allows importing of process models from IBM workflow product MQ Workflow (previously known as FlowMark), analyzing them for structural conflicts, and exporting them back to the product More information about FlowMake is available at hnp:llwww.dstc.edu.auJDDU/projectslFlowMake/ Conclusion The contribution of the work presented in this paper is to identify a layered framework for capturing the requirements for a workflow based business information systems We divide the workflow modeling effort into five partitions: structure, data, execution, temporal, and transactional We introduced a graphical language for workflow modeling and discussed the issues in capturing and specifying the workflow constraints The presented framework is applied as a foundation to develop a methodology and automated tool for the modeling and verification of workflows 293 There are several workflow products available in the market The framework presented in this paper is based on generic requirements of workflow applications and is not influenced by any of the products However, the framework could be used to model and analyze workflow requirements before mapping to workflow products The framework may also be used to evaluate the functionality supported in workflow products for each of the partition We believe that the presented framework represents a logical, intuitive, and effective breakup of workflow constraints References I Aalst WMP van der (1998) The Application of Petri Nets to Workflow Management The Journal of Circuits, Systems and Computers 1998, 8(1 ):21-66 Alonso G., Agrawal D., EI Abbadi A., Kamath M., Guenthoer R., Mohan C Advanced Transaction Models in Workflow Contexts In Proceedings of the 12th International Conference on Data Engineering, New Orleans, 1996 Butler Report Workflow: Integrating the Enterprise The Butler Group, 1996 Carlsen S Conceptual Modeling and Composition of Flexible Workflow Models PhD Thesis Department of Computer Science and Information Science, Norwegian University of Science and Technology, Norway, 1997 Casati F., Ceri S., Pernici B., Pozzi G Conceptual Modeling of Workflows In: Papazoglou M.P (ed) Proceedings of the 14th International Object-Oriented and EntityRelationship Modeling Conference, Springer-Verlag, pp 341-354 (Lecture Notes in Computer Science no 1021) Ellis C.A., Nutt GJ Modelling and Enactment of Workflow Systems In: M Ajmone Marasan (ed) Application and Theory of Petri Nets, Springer-Verleg, Berlin, 1993, pp 1-16 (Lecture Notes in Computer Science no 691) Georgakopoulos D., Hornick M., Sheth A An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure Journal on Distributed and Parallel Databases 1995; 3(2):119-153 Hofstede A.H.M ter, Orlowska M.E., Rajapakse J Verification Problems in Conceptual Workflow Specifications Data & Knowledge Engineering, January 1998; 24(3 ):239-256 Kuo D., Lawley M., Liu c., Orlowska M.E A General Model for Nested Transactional Workflow In: Proceedings of the International Workshop on Advanced Transaction Models and Architecture (ATMA'96), Bombay India, 1996, pp 18-35 10 Kamath M., Ramamritham M Bridging the gap between Transaction Management and Workflow Management Proceedings of the NSF Workshop on Workflow and Process Automation in Information Systems: State of the Art and Future Directions Athens, Georgia, May 1996 11 Rajapakse J On Conceptual Workflow Specification and Verification MSc Thesis Department of Computer Science, The University of Queensland, Australia, 1996 12 Reichert M., Dadam P ADEPTflex - Supporting Dynamic Changes of Workflow without loosing control Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow and Process Management, 1997 13 Sadiq W., Orlowska M.E On Correctness Issues in Conceptual Modeling of Work flows In: Proceedings of the 5th European Conference on Information Systems (ECIS '97), Cork, Ireland, June 19-21, 1997 294 14 Workflow Management Coalition The Workflow Management Coalition Specifications - Terminology and Glossary Issue 2.0, 1996, Docwnent Nwnber WFMC-TC-1011 15 Workflow Management Coalition Interface I: Process Definition Interchange, Process Model, 1998, Docwnent Nwnber WfMC TC-1016-P Author Index Aronson, Jay E 13 Boyd, Michael Dittrich, Klaus R 231 Domenig, Ruxandra 231 Eder, Johann 265 Evaristo, Roberto 45 Hippe, Zdzislaw S 158 Jiang, James J Kelly, Gigi G 45 Kisielnicki, Jerzy 191 Klein, Gary Linger, Henry 86 Lockemann, Peter C 55 Markus, Ursula 76 Martz, Wm Benjamin Jr 24 Mittasch, Christian 203 Myers, Robert M 13 Oommen, B John 250 Orlowska, Maria E 281 Panagos, Euthimios 265 Pokorny, Jaroslav 135 Pozewaunig, Heinz 265 Rabinovich, Michael 265 Repa, Vaclav 216 Sadiq, Wasim 281 Scheer, August-Wilhelm 76 Schiefer, Josef 148 Shepherd, Morgan M 35 Sikorski, Marcin 182 Suleiman, James 45 Thiyagarajah, Murali 250 Tjoa, A Min 148 Unold, Jacek 103 Urban, Joseph E 113 Wharton, Robert B 13 Winter, Robert 125 Wojtkowski, Wita 173 Wong, Kenneth 173 ... 978-1-85233 167 ·2 Springer·Verlag London Berlin Heidelberg British Library Cataloguing in Publication Data BIS' 99: 3rd International Conference on Business Information Systems, Potnan, Poland, 14 16 April. .. April 1999 l.lnformation storage and retrieval systems · Business CongreMes I.Abramowia, Witold II.Orlowska, M E (Maria E.) lIl.lnternational Conference on Business Information Systems (3rd: 1999 :...Springer London Berlin Heidelberg New York Barcelona Hong Kong Milan Paris Santa Clara Singapore Tokyo Witold Abramowicz and Maria E Orlowska (Eds) BIS '99 3rd International Conference on Business Information