While business process management organizes the work that a company performs
by focusing on organizational and functional aspects, the realization
of business process activities also needs to be taken into account. Activities
can be distinguished depending on the level of software system support. The
terms system workflows and human interaction workflows were introduced to
characterize the different kinds of business process enactment.
A classification of activities in business processes was introduced in Figure
3.1, consisting of system activities, user interaction activities, and manual
activities. To recapitulate, system activities are performed by software systems
without user interaction, user interaction activities require the involvement of
human users and manual activities do not involve the use of information systems.
During the enactment of human interaction workflows, knowledge workers
perform activity instances. When a knowledge worker starts working on a specific activity, the respective application program is started, and the input
data as specified in the process model is transferred to that application program.
When the knowledge worker completes that activity, the output data
generated is collected in the output parameters. These parameter values can
then be stored in the application program. They can also be transferred by
the business process management system to the next activity, as specified in
the business process model.
Business process modelling aims at mapping high-level and domain-specific
features of the application process; the technical details—the main components
of the operational perspective—are taken into account in the configuration
phase of the business process management lifecycle. The heterogeneous
nature of information technology landscapes led to various kinds of interface
definitions, most of which did not prove to be compatible. With the advent of
service-oriented computing, the operational aspects of business processes are
represented by services, providing the required uniformity.
This section discusses how activities realized by software functionality can
be modelled. Conceptually, the same levels of abstraction apply to modelling
the operational perspective as to modelling the other perspectives: at the
metamodel level, interface definition languages reside. They describe specific
interface definitions at the model level. At the instance level executing software
code is categorized.
This approach fits the modelling of activity instances (and, therefore, also
to process instances) well, because activity instances can be realized by executing
software code. It also fits the organizational perspective in which persons
reside at the instance level. Persons are—at least in human interaction
workflows—responsible for performing activity instances.
In order to automatically invoke this software functionality, business
process management systems require concepts and technology to access these
systems. The operational perspective of business process modelling provides
the information that equips a business process management system with information
required to invoke the functionality of external application systems.
The operational perspective includes the invocation environment of application
programs, the definition of the input and output parameters of the
application program, and their mapping to input and output parameters of
business process activities. Therefore, functional requirements need to be detailed
in order for us to evaluate whether a certain software system provides
the required functionality in the context of a business process.
This perspective is not limited to functional requirements. Non-functional
requirements also need to be represented, for instance, security properties
and quality of service properties of the invoked applications or services, such
as execution time and uptime constraints. In service-oriented architectures,
these properties are typically specified in service-level agreements between
collaborating business partners. These service-level agreements are part of a
legal contract that the parties sign.
Interface definition languages are used to specify the usage of procedures
and functions, implemented by software system. They are also essential to
connect software systems that have been developed independently from each
other. Therefore, they are essential for middleware systems. Middleware based
on service-oriented architectures play an increasingly important part as realization
platforms for enacting business processes. The reminder of this section
discusses aspects of service-oriented architectures that are relevant for business
The creation of service wrappers that encapsulate business-relevant functionality
of existing information systems is called service-enabling. While there
are environments in which one service is realized by one information system,
the typical case is where business functionality is realized by the interplay of
multiple existing application systems, making service-enabling a costly and
Service-enabling closes the gap between business process activities and
the technical infrastructure for realizing them.
AnalyzeOrder is realized by a
service called Analyze Order Service which combines the functionality of three
underlying software systems that run on a technical infrastructure. While
the definition and realization of the Analyze Order Service is a complex and
challenging task, this book assumes that dedicated business functionality is
available and can be used to realize activities in business processes.
Service-oriented computing also facilitates the dynamic binding of services
to particular business process activities. This situation is represented in the
conceptual model of these layers by a many-to-many relationship between
activity and service. This means that a given activity can be realized by multiple
services. Advanced concepts in service engineering facilitate the dynamic
binding of a business process activity to a service at run time, providing the potential to increase fault tolerance by selecting from a set of possible services
a service that is currently operational.
A more detailed picture is provided in Figure 3.31, where enterprise application
integration middleware is explicitly shown. Two legacy systems provide
their functionality via enterprise application integration middleware. For each
of these systems, an adapter is realized that hides the heterogeneity of the
legacy systems from higher levels. But there can also be existing software
systems that do not require the enterprise application integration middleware