The developments in enterprise software architectures and in organization- level business process management laid out in the previous sections led to workflow management. The important achievement of workflow management is the explicit representation of process structures in process models and the controlled enactment of business processes according to these models.
The model-driven approach facilitates a high degree of flexibility, because process models can be adapted to fulfil new requirements, and the modified process models can immediately be used to enact business processes.
In the 1990s, the Workflow Management Coalition (WfMC) was founded to bundle workflow related activities by vendors, users, and academia. The
Workflow Management Coalition defines workflows and workflow management systems as follows.
Definition 2.2 Workflow is the automation of a business process, in whole or in part, during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules.
Definition 2.3 A workflow management system is a software system that defines, creates, and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to inter- pret the process definition, interact with workflow participants, and, where required, invoke the use of IT tools and applications.
Workflow technology is capable of supporting business processes within a given application system or between a set of application systems, effectively integrating these systems. But workflow technology can also be used to enact business processes in which humans are actively involved, thus improving the collaboration between knowledge workers.
2.4.1 Workflows and Applications
Traditionally, application systems are designed and implemented not only by coding functions that the application carries out, but also by coding the ordering of these functions, i.e., the process logic realized by the application.
With growing complexity of the application systems and increasing de- mand for adapting application systems to new requirements, the coding of process logic in applications has a severe drawback: any modification of the process realized by the application requires a modification of the programming code. The code not only needs to be modified, but also tested and maintained, so that each modification consumes considerable resources.
Workflow management technology can be used to ease the modification of the process logic realized by applications. The functions of an application sys- tem are the steps in the workflow, and a workflow component uses a workflow model to enact the functions. By modification of the process logic specified in workflow models, the behaviour of the application system can be modified without coding.
Today, most enterprise application systems, such as enterprise resource planning systems, host a workflow component that facilitates the flexible cus- tomization of business processes within these systems. Observe that instead of the termworkflow management systemthe termworkflow componentis used, because a workflow component is not a stand-alone software system; rather, it is embedded in the application.
Definition 2.4 Asingle-application workflow consists of activities and their causal and temporal ordering that are realized by one common application system.Multiple-application workflows contain activities that are realized by multiple application systems, providing an integration of these systems.
OS GUI
DBMS Application
Database
Workflow Component
Fig. 2.17.Single-application workflow systems achitecture
The architecture of an single-application workflow system is shown in Fig- ure 2.17. There is a dedicated workflow component that is fed with workflow models that capture the process logic as well as technical execution informa- tion. The workflow component uses functions realized by the application and provides processes to the higher level, the graphical user interface.
In the case of multiple-application workflows, a dedicated workflow man- agement system makes sure that the application systems are invoked as spec- ified in the process model. In addition, data transfer between application systems is also taken care of by the workflow management system.
The relationships of the subsystems involved in a workflow application are shown in Figure 2.18. The integration of the application systems is per- formed by the workflow management system, using adapters similar to those used in traditional enterprise application integration scenarios. The detailed architecture of workflow management systems will be discussed in Chapter 7.
OS DBMS
ERP
OS Inventory Management
OS DBMS
SCM Workflow Management System
Fig. 2.18.Multiple-application workflow systems architecture
2.4.2 System Workflows
In system workflows, the workflow activities are performed automatically by software systems. Therefore, knowledge workers do not interact with the ap-
plication, and graphical user interfaces in general and work item lists in par- ticular are not required. The execution constraints are specified in a process model, and the workflow management system makes sure that the ordering of calls to the software systems is in line with the process model.
Figure 2.19 shows a scenario of a system workflow, with a dedicated work- flow management system that invokes for each activity a defined application system. Each of these software systems provides an interface that the work- flow management system can use, similar to the adapter in the enterprise application integration scenario sketched above. The workflow management system behaves like a centralized hub in an enterprise application integration scenario, but with explicit process representation and enactment control.
Definition 2.5 Asystem workflowconsists of activities that are implemented by software systems without any user involvement.
Enterprise application integration scenarios are typical candidates for sys- tem workflows. The design and implementation of system workflows can be regarded as a type of high-level programming, where functionality provided by application systems characterize the building blocks that are organized within a system workflow.
ERP System
CRM System SCM System
Inventory Management Data Warehouse
Human Resources Application
Fig. 2.19. System workflow integration scenario; a process model defines if and when enterprise applications are invoked
In enterprise application integration platforms without a dedicated process component, the interaction between the application systems is represented by rules, which are used to forward messages based on their type or content.
From these rules, the overall process structure cannot be derived easily, and
realizing change is cumbersome, because rules might trigger other rules, so that undesired side effects can occur.
Process modelling techniques can be used to provide an explicit represen- tation of the relationships between enterprise applications. Process models provide the conceptual basis for defining when and under which conditions enterprise applications are actually invoked in the context of an integration scenario.
Therefore, a dedicated process component responsible for modelling and enacting processes in enterprise application integration scenarios is adequate.
Workflow management systems are well equipped to act as this component.
Today, most enterprise application integration middleware systems host a ded- icated workflow component.
2.4.3 Human Interaction Workflows
In order to introduce human interaction workflows, it is useful to discuss its development. An early predecessor of human interaction workflow manage- ment systems is the office automation system, developed in the early 1980s.
The goal of these systems was supporting the organization and the collabora- tion of work involving multiple persons. Until then, supporting office work of individuals was at the centre of attention. It turned out that it is not sufficient to equip workers with adequate software for their individual workplace, but also to consider the relationship of the work activities that are performed by different workers and provide support for their collaboration.
By shared, consolidated data repositories and by improving the handover of work between employees, a considerable speed-up in office procedures could be realized. However, the scope of office automation was still quite narrow:
workers of a given organization process information objects, primarily using forms-based applications.
Today, human interaction workflows typically realize parts of a larger busi- ness process that has automated as well as nonautomated parts. The goal of human interaction workflows is to effectively support the automated parts of business processes by actively controlling the activities performed according to process models.
Definition 2.6 Workflows in which humans are actively involved and inter- act with information systems are calledhuman interaction workflows.
Workflow management systems also take into account the organization in which the process runs. In particular, for each step in a workflow process, the role responsible for executing is defined. Roles are groups of employees that qualify for this responsibility.
The role concept introduces an additional type of flexibility, because at run time of the workflow, a person currently available can be offered to work on the respective activity, and one of the persons can select the activity to
actually start working on it. Organizational aspects are discussed in more detail in Chapter 3.
Goals attributed to human interaction workflows are reduction of idle pe- riods, avoiding redundant work such as the entering of data multiple times by different knowledge workers, and improved integration of human work with underlying information systems.
Fig. 2.20.Sample human interaction workflow
A sample human interaction workflow is shown in Figure 2.20. In addition to the activities and their logical ordering in a process model, the information system required to enact the workflow for each activity is represented. This information is required, since the workflow management system at run time will invoke these applications and will feed the required process data to these applications.
In the workflow at hand, first an order is stored in an order management system. Then the inventory is checked to find out whether the order can be fulfilled. To keep the process simple, the process design assumes that the order can be fulfilled, i.e., there is no alternative modelled if this is not the case.
Then, concurrently, the shipment is prepared, the parcel is handed to the shipper, and the invoice is prepared and sent. The fulfilled order is archived, completing the human interaction workflow.
Human interaction workflows require particular graphical user interface concepts. The main concept is the work item list. Knowledge workers inter- act with the system using work item lists, which are also called in-baskets.
Whenever a knowledge worker can perform a process activity, he or she is informed by an item in his or her work item list. When the item is selected, the respective application is started, and the input data is provided. When
the activity is completed, the knowledge worker informs the workflow applica- tion. The workflow management system then computes the current state and determines the activities next due.
2.4.4 Challenges for Workflow Management
As discussed in the previous sections, workflow management has considerable benefits due to explicit process representation and process enactment control.
However, workflow management has also spawned criticism that has led to a broader perspective in business process modelling, organization, and control realized by business process management.
Lack of Adequate Support for Knowledge Workers
In contrast to many developments in software architecture and technology, workflow management systems have massive effects on the daily work for their users. The method of data storage and whether the program was developed with a procedural programming language or an object oriented programming language are relevant only for system designers and developers; these imple- mentation aspects do not matter for the users of these systems. Therefore, special care has to be taken in the rollout of workflow applications; early par- ticipation of users in the design of these systems is important to avoid user acceptance issues.
Workflow management systems represent not only processes but also the organizational environment in which these processes are executed. This means that persons are represented by their skills, competences, and organizational positioning. This information is used to select persons to perform certain activities. The active selection of persons by the workflow management system has not been considered appropriate, since human workers felt that a machine burdened them with additional work. This feeling might also be due to crude interfaces of early workflow management systems.
The role of knowledge workers is another area where traditional workflow management systems scored low. Workflow models prescribe the process flow, and a workflow management system makes sure that the workflow is performed just as it is described. This also means that there is little room for creativity for the knowledge worker. Any process instance that has not been envisioned by the process designer cannot be realized. This might lead to situations where certain parts of the overall business process are not handled by the workflow management system. Sometimes, even paper-based solutions were used by the knowledge workers, leading to inconsistent states in the overall process.
These shortcomings of traditional workflow management systems have spawned a number of developments, some of which are reported in Chapter 7.
Technical Integration Challenges
While system workflows are well equipped to support the process aspect of enterprise application integration scenarios, the same technical integration problems need to be solved in system workflow projects as those in traditional enterprise application integration projects.
Application systems that need to be integrated are typically not equipped with well-documented interfaces that can be used to get hold of the required functionality. Functionality of application systems might also be implemented in the graphical user interfaces, so that low-level implementation work is re- quired to access the application system functionality.
Another important source of trouble is relationships between different ap- plications at the code level. Direct invocation between software systems is an example of these relationships, so that an invocation of an application sys- tem automatically spawns off an invocation of another application system. In these settings, the overall process flow is in part realized at the application code level, so that the workflow management system is capable of controlling only parts of the actual process flow, but not the complete process.
The granularity of the workflow activities and the granularity of the func- tionality provided by the underlying application systems might be different.
Fine-granular business activities might have been designed in the process model that cannot be realized, because the underlying application system only provides coarse-grained functionality. In some cases, the interface to the application can be modified so that fine-grained functionality is available.
This alternative is likely to incur considerable cost, or it might be impossi- ble for some applications. Another alternative is changing the granularity of the business activities. In this case, certain properties of the process might not be realizable—for instance, the concurrent execution of two fine-granular activities. As a result, the run time of the workflow will not be optimal.
Service-oriented architectures and service-enabling of legacy applications are important concepts currently being investigated to address these technical problems.
Process Support Without Workflow Systems
Not all environments ask for a workflow management system. In cases where no changes to the process structure are envisioned, a coding of the process flow can be an attractive and adequate choice.
In database administration there are predefined procedures that are en- acted following a process model. Similar developments can be found in pub- lishing environments where print workflow is a common tool to describe and perform the steps that lead to publishable results. Most enterprise resource planning systems feature a dedicated workflow component that allows us to model new processes and enact them in the system environment. Due to their
close link to particular applications, these systems are also called embedded workflow management systems.
Business processes are also realized in online shops, such as train reserva- tion systems or electronic book stores, where steps of an interaction process are depicted in graphical form. This graphical representation guides the user in his interaction with the Web site. In a train reservation online shop, for instance, there are interaction steps for querying train connections, for get- ting detailed information on the connections, for selecting connections, for providing payment information, and for booking and printing the train ticket.
Since this type of interaction process can easily be realized using traditional Web page design, workflow management systems are not required. However, these examples show that the business process paradigm is helpful also in application scenarios that do not require dedicated workflow support.
Enterprise application systems, such as enterprise resource planning sys- tems, realize literally thousands of business processes. These processes can be customized to fit the particular needs of the company that runs the system. In most cases, the business processes are realized within the system, so no inte- gration issues emerge. If the predefined business processes cannot be tailored in a way that fits the needs of the company, then integrated process modelling functionality can be used to model new processes.