CONTENTS Workflow & WFMS Need for workflow instances scheduling Need to schedule Integrating WFMSs with PM Requirements for WFMS

Whenever a user wants to initiate a workflow instance he brings up the appropriate interface provided by a workflow management system (WFMS) and starts it. PROBLEMS : 1. Resource overload to meet deadline 2. Late deliveries due to limited resources can be the result of unconstraint workflow initiation. Hence, Management / schedule required.

NEED TO SCHEDULE : 1. Human resource capacity 2. Company should not over-commit itself or task assignment 3. Overall production throughput Project Management Tools Scheduling tools used to schedule tasks against resource over time in project settings. allow assigning resources to tasks over a time axis balancing the duration of tasks against the resources

Failure of project management tools : The reality & data maintainted in PM divert over time to the worse. Despite having a planned project,overloaded resources can be found as slipped deadlines and milestones. Inconsistency due to missing synchronization between the real task & planned project.

Workflow management systems 1. It establishes a software infrastructure for the automated support and execution of buisness processes through workflow instances. 2. it provides the end user with the required data and the appropriate application program for their tasks. 3. A WFMS is aware of changes since a user has to use WFMS functionality to make the change to the current workflow instance if possible with the given WFMS. 4. assign tasks to end-user based only on the fulfillment of constraints like control flow, data flow, transition conditions or pre- and post-conditions.

5. WFMSs in general do not take resource capacity, task difficulty or overall throughput into consideration and therefore do not assign tasks based on these factors. 6. Hence workflow instances are started independent of resource availability and resource capacity leading to overloaded resources.

WORKFLOW & PROJECT MANAGEMENT If their tight integration is possible, then it results into an environment where the planning and the execution of tasks are consistent with each other. Changes in assignment of resources or changes in start- time are send to the WFMS. Ad-hoc changes during workflow instance execution are reflected in the plan without delay. The WFMS notifies the PM which re- schedules based on the change and returns the new schedule. If automatic re-scheduling is not possible, a project manager has to be involved and has to do manual re- scheduling.

Furthermore, the assignment of tasks to resources can be done by a project planner, group leader or lead engineer according to the required skill level and the task’s difficulty. Problem : their integration is difficult due to the different underlying paradigms of the two software systems. Workflow management is concerned about the current execution whereas project management deals with the planning of the future execution

Integrating WFMSs with PM Integration consists of 2 parts : Schema integration Behaviour integration The conceptual objects of the systems have to be mapped to each other in order to determine their semantic relationships(schema integration). Based on this mapping, the state changes taking place in one system can be determined that have to be reflected appropriately in the other one (behavior integration)

Both systems have a database each storing their state information. Additionally, the execution logic is shown operating on the database as well as user interfaces. The goal is to integrate both systems on an application programming level in such a way that their execution logic mutually invokes each other to pass relevant state changes.

General system interaction In WFMSs as well as PM planning or definition can Be distinguished from execution. 1. In WFMSs “definition” refers to the definition of workflow types and “execution” refers to the execution of workflow instances. 2. In PM“definition” refers to setting up a project plan whereas “execution” means to maintain a schedule, to monitor the plan, to enter states of task completion or to do replanning.

General interaction patterns : Which system defines workflow types and which imports them? Which of the systems starts instances? Which system initiates run-time changes? Schema integration : WFMSs as well as PM work on their own conceptual objects implemented in their database schemes. A first step towards integration is to map the conceptual objects of WFMS [9] and PM [6, 10] to each other as shown in table.

PM do neither support conditional control flow nor recursion or loops. A direct mapping is therefore not possible. There are two basic solutions to the mapping. 1. Static mapping : If the mapping is done before runtime and a complete mapping is the goal,all possible routes are mapped to a project plan with an indication at those tasks which might not be executed (for example, when they are part of a conditional branch). 2. Continuous mapping : to map only the portion of a workflow type, which will be executed. This means that in the beginning only those steps are mapped which are before the first conditional branching. If the branch is decided, the branch will be mapped until the next branch. In case a loop is encountered, the first loop will be mapped and at runtime, when the decision is made to loop again, the tasks in the loop are mapped again. This mapping has the advantage that No conditional tasks appear in the project plan.

Behaviour integration : defines the interaction between a WFMS and a PM in such a way that both states stay consistent with each other. For each state change in one system it is defined how it affects the other system (if at all). The behavior integration is complete when all interactions between the systems are defined. Two approaches : 1. starts with listing the interfaces for each of the systems to be integrated. Only those interfaces can be used for defining the behavior integration. 2. defines the behavior integration independent of specific systems. The result is an “ideal” integration. From this behavior integration the integration of two specific systems can be derived.

Requirements for WFMS  A WFMS has to query the assigned resource for a step from the PM tool.  The addition, deletion and modification of workflow steps is necessary as well as to re-assign resources to steps at any point in time during workflow execution. A WFMS must assign workflow steps according to start times of tasks scheduled within the PM. This means that a WFMS cannot assign a step by itself but has to coordinate with a PM. Changes within a WFMS have to be communicated to a PM.  A WFMS must make build-time and runtime interfaces available. This allows a PM to communicate type changes as well as instance changes to the WFMS