If the business process model prescribes the activities and their execution
constraints in a complete fashion, then the process is structured. The different
options for decisions that will be made during the enactment of the process
have been defined at design time. For instance, a credit request process might
use a threshold amount to decide whether a simple or a complex credit check
is required, for instance, 5000 euros. Each process instance then uses the
requested amount to decide on the branch to take.
Leymann and Roller have organized business processes according to dimensions
structure and repetition. They coined the term production workflow.
Production workflows are well structured and highly repetitive. Traditional
workflow management system functionality is well suited to supporting production
workflows.
If process participants who have the experience and competence to decide
on their working procedures perform business process activities, structured
processes are more of an obstacle than an asset. Skipping certain process activities
the knowledge worker does not require or executing steps concurrently
that are ordered sequentially in the process model is not possible in structured
business processes.
To better support knowledge workers, business process models can define
processes in a less rigid manner, so that activities can be executed in any order
or even multiple times until the knowledge worker decides that the goals of
these activities have been reached. So called ad hoc activities are an important
concept for supporting unstructured parts of processes.
Case handling is an approach that supports knowledge workers performing
business processes with a low level of structuring and, consequently, a high
level of flexibility. Rather than prescribing control flow constraints between
process activities, fine-grained data dependencies are used to control the enactment
of the business process.
Tuesday, September 1, 2009
Business processes in Degree of Repetition work through control:
Business processes can be classified according to their degree of repetition.
Examples of highly repetitive business processes include business processes
without human involvement, such as online airline ticketing. However, business
processes in which humans are involved can occur frequently, for example,
insurance claim processing. If the degree of repetition is high, then investments
in modelling and supporting the automatic enactment of these processes pay
off, because many process instances can benefit from these investments.
At the other end of the repetition continuum, there are business processes
that occur a few times only. Examples include large engineering efforts, such
as designing a vessel. For these processes it is questionable whether the effort
introduced by process modelling does in fact pay off, because the cost of
process modelling per process instance is very high.
Since improving the collaboration between the persons involved is at the
centre of attention, these processes are called collaborative business processes.
In collaborative business processes, the goal of process modelling and enactment
is not only efficiency, but also tracing exactly what has actually been
done and which causal relationships between project tasks have occurred.
This aspect is also present in the management of scientific experiments,
where data lineage is an important goal of process support. Since each experiment
consists of a set of activities, an increasing fraction of the experimentation
is performed by analyzing data using software systems. The data
is transformed in a series of steps. Since experiments need to be repeatable,
it is essential that the relationship of the data sets be documented properly.
Business processes with a low degree of repetition are often not fully automated
and have a collaborative character, so that the effort in providing
automated solutions is not required, which lowers the cost.
Examples of highly repetitive business processes include business processes
without human involvement, such as online airline ticketing. However, business
processes in which humans are involved can occur frequently, for example,
insurance claim processing. If the degree of repetition is high, then investments
in modelling and supporting the automatic enactment of these processes pay
off, because many process instances can benefit from these investments.
At the other end of the repetition continuum, there are business processes
that occur a few times only. Examples include large engineering efforts, such
as designing a vessel. For these processes it is questionable whether the effort
introduced by process modelling does in fact pay off, because the cost of
process modelling per process instance is very high.
Since improving the collaboration between the persons involved is at the
centre of attention, these processes are called collaborative business processes.
In collaborative business processes, the goal of process modelling and enactment
is not only efficiency, but also tracing exactly what has actually been
done and which causal relationships between project tasks have occurred.
This aspect is also present in the management of scientific experiments,
where data lineage is an important goal of process support. Since each experiment
consists of a set of activities, an increasing fraction of the experimentation
is performed by analyzing data using software systems. The data
is transformed in a series of steps. Since experiments need to be repeatable,
it is essential that the relationship of the data sets be documented properly.
Business processes with a low degree of repetition are often not fully automated
and have a collaborative character, so that the effort in providing
automated solutions is not required, which lowers the cost.
Evolution of Enterprise Systems Architectures:
Process orientation in general and business process management in particular
are parts of a larger development that has been affecting the design of
information systems since its beginning: the evolution of enterprise systems
architectures.
Enterprise systems architectures are mainly composed of information systems.
These systems can be distinguished from software systems in the area
of embedded computing that control physical devices such as mobile phones,
cars, or airplanes. Business process management mainly deals with information
systems in the context of enterprise systems architectures.
The guiding principle of this evolution is separation of concerns, a principle
identified by Edsger Dijkstra and characterized by �focusing one�s attention
upon some aspect.� It is one of the key principles in handling the complexity
of computer systems.
While this principle has many applications in theoretical and applied computer
science, in the context of software systems design�and therefore also in
information systems design�it means identifying sets of related functionality
and packaging them in a subsystem with clearly identified responsibilities and
interfaces. Using this approach, complex and powerful software systems can
be engineered. Separation of concerns also facilitates reuse at a level of coarse
granularity, because well-specified functional units provided by subsystems
can be used by different applications.
Separation of concerns also facilitates response to change and is therefore
an important mechanism to support flexibility of software systems, because
individual subsystems can be modified or even exchanged with another subsystem
providing the same functionality without changing other parts of the
system�provided the interfaces remain stable.
Since local changes do not affect the overall system, a second guiding principle
of computer science is realized: information hiding, originally introduced
by David Parnas. Reasons for changes can be manifold: new requirements in
an ever-changing dynamic market environment, changes in technology, and
changes in legal regulations that need to be reflected in software systems.
While effective response to change is an important goal of any software system,
it is of particular relevance to business process management systems, as
will be detailed below.
Before addressing the evolution of enterprise systems architectures, the
understanding of software architectures as used in this book is described. In
general, software architectures play a central role in handling the complexity
of software systems.
are parts of a larger development that has been affecting the design of
information systems since its beginning: the evolution of enterprise systems
architectures.
Enterprise systems architectures are mainly composed of information systems.
These systems can be distinguished from software systems in the area
of embedded computing that control physical devices such as mobile phones,
cars, or airplanes. Business process management mainly deals with information
systems in the context of enterprise systems architectures.
The guiding principle of this evolution is separation of concerns, a principle
identified by Edsger Dijkstra and characterized by �focusing one�s attention
upon some aspect.� It is one of the key principles in handling the complexity
of computer systems.
While this principle has many applications in theoretical and applied computer
science, in the context of software systems design�and therefore also in
information systems design�it means identifying sets of related functionality
and packaging them in a subsystem with clearly identified responsibilities and
interfaces. Using this approach, complex and powerful software systems can
be engineered. Separation of concerns also facilitates reuse at a level of coarse
granularity, because well-specified functional units provided by subsystems
can be used by different applications.
Separation of concerns also facilitates response to change and is therefore
an important mechanism to support flexibility of software systems, because
individual subsystems can be modified or even exchanged with another subsystem
providing the same functionality without changing other parts of the
system�provided the interfaces remain stable.
Since local changes do not affect the overall system, a second guiding principle
of computer science is realized: information hiding, originally introduced
by David Parnas. Reasons for changes can be manifold: new requirements in
an ever-changing dynamic market environment, changes in technology, and
changes in legal regulations that need to be reflected in software systems.
While effective response to change is an important goal of any software system,
it is of particular relevance to business process management systems, as
will be detailed below.
Before addressing the evolution of enterprise systems architectures, the
understanding of software architectures as used in this book is described. In
general, software architectures play a central role in handling the complexity
of software systems.
Goals, Structure, and Organization in business management:
Arguably, the most important goal of business process management is a
better understanding of the operations a company performs and their relationships.
The explicit representation of business processes is the core concept
to achieving this better understanding.
Identifying the activities and their relationships and representing them
by business process models allows stakeholders to communicate about these
processes in an efficient and effective manner. Using business process models
as common communication artefacts, business processes can be analyzed, and
potentials for improving them can be developed.
Flexibility�the ability to change�is the key operational goal of business
process management. The subjects of change are diverse. Business process
management not only supports changing the organizational environment of
the business process, but also facilitates changes in the software layer without
changing the overall business process. Flexibility in business process management
is discussed in detail in Section 3.10.
A repository of the business processes that a company performs is an
important asset. To some extent, it captures knowledge of how the company
performs its business. Therefore, business process models can be regarded as
a means to expressing knowledge of the operation of a company.
But business process management also facilitates continuous process improvement.
The idea is to evolutionarily improve the organization of work
a company performs. Explicit representations of business processes are well
suited for identifying potentials for improvement, but they can also be used
to compare actual cases with the specified process models. While in principle
more radical business process reengineering activities can also be supported
by business processes, evolutionary measures to improve business processes
might in many cases be the favourable solution.
Business process management also aims at narrowing the gap between
business processes that a company performs and the realization of these processes
in software. The vision is that there is a precisely specified relationship
between an activity in the business process layer and its realization in software.
A metamodel is used to specify the semantics
of control flow patterns. An important part of this book deals with process
modelling techniques and notations. The most important ones are discussed in
a concise manner, including Petri nets, event-driven process chains, workflow
nets, Yet Another Workflow Language, a graph-based workflow language, and
the Business Process Modeling Notation.
better understanding of the operations a company performs and their relationships.
The explicit representation of business processes is the core concept
to achieving this better understanding.
Identifying the activities and their relationships and representing them
by business process models allows stakeholders to communicate about these
processes in an efficient and effective manner. Using business process models
as common communication artefacts, business processes can be analyzed, and
potentials for improving them can be developed.
Flexibility�the ability to change�is the key operational goal of business
process management. The subjects of change are diverse. Business process
management not only supports changing the organizational environment of
the business process, but also facilitates changes in the software layer without
changing the overall business process. Flexibility in business process management
is discussed in detail in Section 3.10.
A repository of the business processes that a company performs is an
important asset. To some extent, it captures knowledge of how the company
performs its business. Therefore, business process models can be regarded as
a means to expressing knowledge of the operation of a company.
But business process management also facilitates continuous process improvement.
The idea is to evolutionarily improve the organization of work
a company performs. Explicit representations of business processes are well
suited for identifying potentials for improvement, but they can also be used
to compare actual cases with the specified process models. While in principle
more radical business process reengineering activities can also be supported
by business processes, evolutionary measures to improve business processes
might in many cases be the favourable solution.
Business process management also aims at narrowing the gap between
business processes that a company performs and the realization of these processes
in software. The vision is that there is a precisely specified relationship
between an activity in the business process layer and its realization in software.
A metamodel is used to specify the semantics
of control flow patterns. An important part of this book deals with process
modelling techniques and notations. The most important ones are discussed in
a concise manner, including Petri nets, event-driven process chains, workflow
nets, Yet Another Workflow Language, a graph-based workflow language, and
the Business Process Modeling Notation.
Enterprise Applications and their Integration:
Based on operating systems and communication systems as a basic abstraction
layer, relational database management systems for storing and retrieving
large amounts of data, and graphical user interface systems, more and more
elaborate information systems could be engineered.
Most of these information systems host enterprise applications. These applications
support enterprises in managing their core assets, including customers,
personnel, products, and resources. Therefore, it is instructive to look
in more detail at enterprise information systems, starting from individual
enterprise applications and addressing the integration of multiple enterprise
applications. The integration of multiple enterprise applications has spawned
a new breed of middleware, enterprise application integration systems. Enterprise
application integration proves to be an important application area of
business process management.
These developments can be illustrated with an enterprise scenario. In the
early stages of enterprise computing, mainframe solutions were developed that
hosted monolithic applications, typically developed in assembler programming
language. These monolithic applications managed all tasks with a single huge
program, including the textual user interface, the application logic, and the
data. Data was mostly stored in files, and the applications accessed data files
through the operating system.
With the advent of database systems, an internal structuring of the system
was achieved: data was managed by a database management system. However,
the application code and the user interface code were not separated from each
other. The user interface provides the desired functionality through textual,
forms-based interfaces.
With lowering cost of computer hardware and growing requirements for
application functionality, more application systems were developed. It was
typical that an enterprise had one software system for human resources management,
one for purchase order management and one for production planning.
Each of these application systems hosted its local data, typically in a
database system, but sometimes even on the file system. In large enterprises,
in different departments, different application systems were sometimes used
to cope with the same issue.
What made things complicated was the fact that these application systems
hosted related data. This means that one logical data object, such as a
customer address, was stored in different data stores managed by different application
systems. Dependencies between data stored in multiple systems were
also represented by dedicated links, for instance through a contract identifier
or an employee identifier.
It is obvious that in these settings changes were hard to implement, because
there are multiple data dependencies between these disparate systems,
and changes in one system had to be mirrored by changes in other systems.
Detecting the systems affected and the particular change required in these
systems was complex and error-prone. As a result, any change of the data
objects, for instance, of a customer address, needed to be reflected in multiple
applications. This lack of integration led to inconsistent data and�in many
cases�to dissatisfied customers.
layer, relational database management systems for storing and retrieving
large amounts of data, and graphical user interface systems, more and more
elaborate information systems could be engineered.
Most of these information systems host enterprise applications. These applications
support enterprises in managing their core assets, including customers,
personnel, products, and resources. Therefore, it is instructive to look
in more detail at enterprise information systems, starting from individual
enterprise applications and addressing the integration of multiple enterprise
applications. The integration of multiple enterprise applications has spawned
a new breed of middleware, enterprise application integration systems. Enterprise
application integration proves to be an important application area of
business process management.
These developments can be illustrated with an enterprise scenario. In the
early stages of enterprise computing, mainframe solutions were developed that
hosted monolithic applications, typically developed in assembler programming
language. These monolithic applications managed all tasks with a single huge
program, including the textual user interface, the application logic, and the
data. Data was mostly stored in files, and the applications accessed data files
through the operating system.
With the advent of database systems, an internal structuring of the system
was achieved: data was managed by a database management system. However,
the application code and the user interface code were not separated from each
other. The user interface provides the desired functionality through textual,
forms-based interfaces.
With lowering cost of computer hardware and growing requirements for
application functionality, more application systems were developed. It was
typical that an enterprise had one software system for human resources management,
one for purchase order management and one for production planning.
Each of these application systems hosted its local data, typically in a
database system, but sometimes even on the file system. In large enterprises,
in different departments, different application systems were sometimes used
to cope with the same issue.
What made things complicated was the fact that these application systems
hosted related data. This means that one logical data object, such as a
customer address, was stored in different data stores managed by different application
systems. Dependencies between data stored in multiple systems were
also represented by dedicated links, for instance through a contract identifier
or an employee identifier.
It is obvious that in these settings changes were hard to implement, because
there are multiple data dependencies between these disparate systems,
and changes in one system had to be mirrored by changes in other systems.
Detecting the systems affected and the particular change required in these
systems was complex and error-prone. As a result, any change of the data
objects, for instance, of a customer address, needed to be reflected in multiple
applications. This lack of integration led to inconsistent data and�in many
cases�to dissatisfied customers.
Traditional Application Development:
The main goal of this section is to categorize business process management
systems from a software systems point of view into major developments that
information systems design underwent in the last decades. It depicts
the first stages in the evolution of information systems. The dates in that figure
provide only rough estimates�the respective systems architectures were not
uncommon at the dates given.
In the early days of computing, applications were developed from scratch,
without taking advantage of prior achievements other than subroutines of
fine granularity. Application programmers needed to code basic functionality
such as, for instance, access to persistent storage and memory management.
Basic functionality needed to be redeveloped in different applications, so that
application programming was a costly and inefficient endeavour. As a result
of the tight coupling of the programmed assembler code with the hardware,
porting an application to a new computer system results in a more or less
complete redevelopment.
Operating systems were developed as the first type of subsystem with
dedicated responsibilities, realizing separation of operating systems concerns
from the application. Operating systems provide programming interfaces to
functionality provided by the computer hardware. Applications can implement
functionality by using interfaces provided by the operating system, realizing
increased efficiency in system development.
Specific properties of the computer hardware could be hidden from the
application by the operating system, so that changes in the hardware could
bereflected by a modified implementation of the operating system�s interface, for
instance, by developing a new driver for a new hardware device. An operating
systems (OS) layer is depicted in as the lowest level subsystem.
systems from a software systems point of view into major developments that
information systems design underwent in the last decades. It depicts
the first stages in the evolution of information systems. The dates in that figure
provide only rough estimates�the respective systems architectures were not
uncommon at the dates given.
In the early days of computing, applications were developed from scratch,
without taking advantage of prior achievements other than subroutines of
fine granularity. Application programmers needed to code basic functionality
such as, for instance, access to persistent storage and memory management.
Basic functionality needed to be redeveloped in different applications, so that
application programming was a costly and inefficient endeavour. As a result
of the tight coupling of the programmed assembler code with the hardware,
porting an application to a new computer system results in a more or less
complete redevelopment.
Operating systems were developed as the first type of subsystem with
dedicated responsibilities, realizing separation of operating systems concerns
from the application. Operating systems provide programming interfaces to
functionality provided by the computer hardware. Applications can implement
functionality by using interfaces provided by the operating system, realizing
increased efficiency in system development.
Specific properties of the computer hardware could be hidden from the
application by the operating system, so that changes in the hardware could
bereflected by a modified implementation of the operating system�s interface, for
instance, by developing a new driver for a new hardware device. An operating
systems (OS) layer is depicted in as the lowest level subsystem.
Enterprise Application Integration in business management:
Enterprises are facing the challenge of integrating complex software systems
in a heterogeneous information technology landscape that has grown in an
evolutionary way for years, if not for decades. Most of the application systems
have been developed independently of each other, and each application stores
its data locally, either in a database system or some other data store, leading
to siloed applications.
Data heterogeneity issues occur if a logical data item�for instance, a
customer address�is stored multiple times in different siloed applications.
Assume that customer data is stored in an enterprise resource planning system
and a customer relationship management system. Although both systems use
a relational database as storage facility, the data structures will be different
and not immediately comparable.
These differences involve both the types of particular data fields (strings
of different length for attribute CustomerName), but also the names of the
attributes. In the customer example, in one system the attribute CAddr will
denote the address of the customer, while in the other system the attribute
StreetAdrC denotes the address.
The next level of heterogeneity regards the semantics of the attributes.
Assume there is an attribute Price in the product tables of two application
systems. The naming of the attribute does not indicate whether the price
includes or excludes value-added tax. These semantic differences need to be
sorted out if the systems are integrated. Data integration technologies are
used to cope with these syntactic and semantic difficulties.
Data integration is an important aspect in enterprise application integration.
In this section, the traditional point-to-point enterprise application.
in a heterogeneous information technology landscape that has grown in an
evolutionary way for years, if not for decades. Most of the application systems
have been developed independently of each other, and each application stores
its data locally, either in a database system or some other data store, leading
to siloed applications.
Data heterogeneity issues occur if a logical data item�for instance, a
customer address�is stored multiple times in different siloed applications.
Assume that customer data is stored in an enterprise resource planning system
and a customer relationship management system. Although both systems use
a relational database as storage facility, the data structures will be different
and not immediately comparable.
These differences involve both the types of particular data fields (strings
of different length for attribute CustomerName), but also the names of the
attributes. In the customer example, in one system the attribute CAddr will
denote the address of the customer, while in the other system the attribute
StreetAdrC denotes the address.
The next level of heterogeneity regards the semantics of the attributes.
Assume there is an attribute Price in the product tables of two application
systems. The naming of the attribute does not indicate whether the price
includes or excludes value-added tax. These semantic differences need to be
sorted out if the systems are integrated. Data integration technologies are
used to cope with these syntactic and semantic difficulties.
Data integration is an important aspect in enterprise application integration.
In this section, the traditional point-to-point enterprise application.
Subscribe to:
Posts (Atom)