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 demand
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 system
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
Today, most enterprise application systems, such as enterprise resource
planning systems, host a workflow component that facilitates the flexible customization
of business processes within these systems. Observe that instead of
the term workflow management system the term workflow component is used,
because a workflow component is not a stand-alone software system; rather,
it is embedded in the application.
Definition 2.4 A single-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.
There is a dedicated workflow component that is fed with workflow
models that capture the process logic as well as technical execution information.
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 management
system makes sure that the application systems are invoked as specified
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 performed
by the workflow management system, using adapters similar to those
used in traditional enterprise application integration scenarios.
In system workflows, the workflow activities are performed automatically by
software systems. Therefore, knowledge workers do not interact with the application, and graphical user interfaces in general and work item lists in particular
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 workflow
management system that invokes for each activity a defined application
system. Each of these software systems provides an interface that the workflow
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 A system workflow consists of activities that are implemented
by software systems without any user involvement.
Enterprise application integration scenarios are typical candidates for system
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.
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 representation
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
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 dedicated