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.
Definition 2.1 A software architecture defines a structure that organizes the
software elements and the resources of a software system. Software elements
and resources are represented by subsystems. In a given software architecture,
these subsystems have specific responsibilities and relationships to other
subsystems.
Software architectures do not detail the internal structure of a subsystem;
but they detail their externally visible behaviour and, thus, their relationships
to other subsystems of the architecture. Internal aspects of a subsystem
can, however, be represented in the software architecture of the particular subsystem.
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. Figure 2.1 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 be reflected by a modified implementation of the operating system’s interface, for
instance, by developing a new driver for a new hardware device.
The next step in the evolution of systems architectures considers the management
of data. Before dedicated subsystems for handing data were developed,
each application program was responsible for storing its data persistently
and for retrieving it. Programming interfaces were used to store data.
Since the structure of the stored data matches the data structure in the application
program, each change in the data structures of the application results
in a change of the data structures in persistent memory, and vice versa. Due
to the strong link between the data structures in the application and the data
structures in persistent memory, any modification requires implementation or
reorganization effort.
Two additional problems are associated with this approach: the design and
implementation of data management takes considerable implementation effort
because dedicated storage and retrieval functionality need to be implemented
in each application. In addition, data consistency issues arise if multiple applications
store related data redundantly. In this case, the modification of a
data item needs to be realized by a modification of each copy of the data item
by different systems, introducing the potential for data inconsistency issues.
To provide a reusable set of functionality and to overcome the data inconsistency
problem, database management systems were introduced. Following
early data models, like the hierarchical data model and the network data
model, relational databases were developed. Relational database systems allow
modification of the structures of the physically stored data without affecting
the application programs. This important property is known as physical data
independence.
At the same time, logical data independence is covered, i.e., the ability to
change the logical organization of the data without the need to change applications.
Efficient and convenient access to large amounts of data, declarative query languages, most prominently the Structured Query Language SQL,
transaction processing capabilities to cater for concurrent access and recovery
from failure situations, security aspects, and many more features are realized
in today’s database management systems. Today, relational database systems
are an important backbone of modern information systems.
The layering of the subsystem—applications sit on top of database systems
that sit on top of operating systems, as shown in Figure 2.1—is simplified.
Applications do not only use the functionality provided by the database management
system—as the layering might indicate. Applications also directly
use functionality provided by the underlying operating system.
The next step in the evolution of information systems is dedicated to
graphical user interfaces which were developed to ease human interaction with
application systems. Before the advent of graphical user interfaces, users interacted
with application programs on the basis of mostly textual interfaces
that required extensive user training before work could be done efficiently.
Since until then applications covered a comparatively narrow ground and
the users of these systems were highly specialized employees, textual or simple
graphical interfaces were adequate for most applications. Due to increased
functionality of applications and the associated broadening of the competence
and skills of the personnel, more elaborate user interfaces were required.
The new role of the employees can be characterized as that of a knowledge
worker. Knowledge workers have a large set of capabilities and skills at their
disposal, from which they can choose the one that best suits the current task.
In order to be effective, knowledge workers require advanced user interfaces
to access the required functionality from powerful information systems.
The separation of the business logic covered in applications and the interaction
between the system and the knowledge worker led to the development
of graphical user interfaces, which also foster reuse of functionality at the user
interface layer. Today, graphical user interfaces are developed using elaborate
frameworks, increasing the efficiency of graphical user interface development.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment