Friday, July 31, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec G -- By Mathias Weske





Process Interactions

Business processes reside in single organizations. Since enterprises cooperate
with each other, it is essential to consider the interaction between enterprises.
Since all activities that an enterprise conducts are part of some business process, the interaction between enterprises can be described by the interaction
of business processes of these enterprises. These interactions typically
occur in a peer-to-peer style, following an agreed-upon process choreography.
These enterprises are reflected by the
respective value chains. Within these value chains are the business functions
realized by the business processes.
The buyer value chain contains an order product business function, and
the reseller value chain contains an order management business function. The
business process models that realize this interaction are shown in Figure 3.21.
The order product business function of the buyer starts by his placing
an order. This placing of an order is realized by a message to the reseller;
the task place order is responsible for sending this message. On the reseller
side, this message is received by a receive order activity. The processes continue
as specified. Since the message flow occurs between multiple activities
in both directions, the value chain level representation of the interacting business
processes—from buyer to reseller—is not complete in the sense that it
does not hold all possible orders of interaction.
Interacting process instances can be visualized adequately by event diagrams.
The distributed nature of interacting processes is represented by introducing
a horizontal line for each participant, on which the events of that
participant appear in an ordered fashion. Participants communicate by send ing and receiving messages. In event diagrams, a one-way message interaction
is represented by a send event, a corresponding receive event, and an arc connecting
the two events. Participants can communicate only by sending and
receiving messages.
It abstracts
from events regarding the initiating, enabling, starting, and terminating of
activities. Instead, it concentrates on message events. Each message send event
is marked by the activity instance during which the send occurs, and each
receive event is marked by the activity instance during which the receive
occurs. It is valid to assume that messages are sent on termination of the
respective activity instance and an arrival of a message triggers the enable
event for the receiving activity instance.


Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec F -- By Mathias Weske

Process Instances


Process models define restrictions on process instances that belong to the
process model. Therefore, it is essential to properly define not only process
models but also process instances. Modelling process instances is not an easy
task, because of their intangible nature. A process instance is started, and it
lives for a limited time period before it ceases to exist, similarly to activity
instances.
A process instance consists of a number of activity instances as well as
event and gateway instances. The ordering relationships of activity instances
in a process instance is defined by the relationships of the activity models in
the process model.
For instance, if a process model defines an execution ordering constraint
between activity models A and B, then for each particular process instance,
the activity instance that belongs to activity model A must have terminated
before the activity instance for B can be started.
An extension of the process metamodel discussed above is presented in Figure
3.17. There are additional classes for process instances and node instances
that are a generalization of activity instances, events, and gateway instances.
There are one-to-many relationships between the respective concepts at the
model level and at the instance level, as shown in the metamodel.
Each process instance is associated with exactly one process model, and
each process model is associated with an arbitrary number of process instances.
Each process instance is composed of an arbitrary number of activity
instances. Each activity instance is associated with exactly one activity model.
The same holds for events and gateways.
Note that each activity model is associated with an arbitrary number of
activity instances. In the case of loops, an activity model is associated with
multiple activity instances. An activity model that lies on a branch that is
not taken during a particular process instance is not associated with any
activity instance, explaining the cardinality of the association * that allows
zero occurrences of the association, i.e., there might be activity models in a
process model for which no activity instances are required for a particular
process instance.
After introducing events and event orderings to represent activity instances,
this section looks at events and event orderings that occur during
the enactment of process instances. Process models restrict for a process instance
the events and event orderings of its activity instances by imposing
execution constraints, such as sequential execution of activity instances. Execution
constraints need to be satisfied by all process instances based on a
particular process model.
The execution constraints can be precisely specified by events and their
ordering. For example, the execution constraint A ! B dictates that the start
event of the activity instance corresponding to B can only happen after the
termination event of the activity instance corresponding to A. This is the
basic idea of characterizing the execution semantics of process instances.
To illustrate these concepts, a process instance based on the process model
shown in Figure 3.15 on page 91 is investigated. Each process instance based
on this process model starts with an analyze order activity. Depending on
a decision, either the simple check activity or the advanced check activity
is enacted. This process model makes room for different process instances.
Depending on the decision made at the gateway node, either the simple check
activity instance or the advanced check activity is executed.
Event diagrams are also useful for capturing process instances. The event
diagram of a particular process instance is shown in Figure 3.18, where a
process instance is shown during which the simple check activity instance is
selected.
When the process starts, activity instances for all three activity models
are generated. In event diagrams, the subscripts of the init, enable, terminate, and skip events can be omitted, if the activity instance to which the event
belongs is clear.
The start event is represented by the event node N1 in the process model.
The occurrence of this event is represented in the event diagram by event n1.
Once this event has occurred, the AnalyzeOrder activity instance can start,
i.e., it can enter the ready state, represented by an enable event.
When the AnalyzeOrder activity instance terminates, (1) the AdvCheck
activity instance is no longer required, so that a skip event occurs for this
activity instance, and (2) the SimpleCheck activity instance is enabled, so
that it can start. When this activity completes, the final event n7 of the
process instance occurs.


Monday, July 27, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec E -- By Mathias Weske

Process Models and Process Instances

Business processes consist of a set of related activities whose coordinated execution contributes to the realization of a business function in a technical and organizational environment. Business processes are represented by business process models. Since this section concentrates on the execution ordering of activities, disregarding the technical and organizational environment of business processes, the term process model is used.
Object Facility for the process subdomain. In the M0 layer there are process instances that reflect the actual occurrences of a business process. Each process instance is an instance of a process model in the model layer M1. Process models are described by process metamodels, building the M2 layer. In order to express process models, there needs to be a notation in place that provides notational elements for the conceptual elements of process metamodels. For instance, if the process metamodel has a concept called activity model, then there needs to be a notational element for expressing activity models.
A process notation is associated with the process metamodel level and with the process model level; each process model is expressed in a process notation associated with the process metamodel that describes the process model.

Process Models

In this section, a simple process metamodel is introduced. Rather than being on completeness of modelling constructs, the focus of this section is on providing a well-described process metamodel that can be used to illustrate the core components of any process metamodel. Chapter 4 will look at process metamodels of higher complexity. Any modelling effort starts with identifying the main concepts that need to be represented. In metamodelling, the concepts to be represented are models. The following models are identified as concepts in the metamodel. • Process Model : A process model represents a blue print for a set of process instances with a similar structure. Process models have a two-level hierarchy, so that each process model consists of a set of activity models. Nesting of process models within process models is not represented, because it would introduce complexity that is not required. Each process model consists of nodes and directed edges. • Edge: Directed edges are used to express the relationships between nodes in a process model. • Node: A node in a process model can represent an activity model, an event model, or a gateway model. – Activity Models: Activity models describe units of work conducted in a business process. Each activity model can appear at most once in a process model. No activity model can appear in multiple process models. This stipulation can be relaxed by qualifying activity model identifiers with process model identifiers; to keep the process metamodel simple, this extension is not covered. Activity model nodes do not act as split or join nodes, i.e., each activity model has exactly one incoming edge and exactly one outgoing edge. – Event models: Event models capture the occurrence of states relevant for a business process. Process instances start and end with events, so process models start and end with event models. – Gateway Models: Gateways are used to express control flow constructs, including sequences, as well as split and join nodes.
Each process model contains elements at the model level, for instance, activity models. Process instances consist of activity instances. The model level and the instance level do not hold only for activities, but also for events and gateways. For instance, the start event model in a process model rules that each process instance begins with a start event instance. Since events are by definition singular entities, event instances are also called events.
Control flow in process models is represented by gateway models. As with activities and events, gateways are represented in process models by gateway models. This explicit representation allows our considering gateway instances for process instances. This is very useful, since each gateway model can be used multiple times in a given process instance, for instance, if it is part of a loop. The different occurrences of a given gateway can have different properties. For instance, an exclusive or gateway can in one instance select branch 1 while in the next iteration it can use branch 2. This situation can be represented properly if there are multiple gateway instances for a given gateway model in the context of a given process model. In the example discussed, the first gateway instance would select branch 1, while the second gateway instance would select branch 2.
The next step in modelling concerns the identification and formalization of the relationships between these concepts. Figure 3.14 provides a representation of the concepts and their relationships by a structure diagram, defining a process metamodel. Each process model consists of nodes and edges. The nodes represent activity models, event models and gateway models, while the edges represent control flow between nodes. Each edge is associated with exactly two nodes, relating them in a particular order. Each node is associated with at least one edge. The different types of nodes are represented by the generalization relation. Activity models reflect the work units to be performed, event models represent the occurrence of states relevant for the business process, and gateway models represent execution constraints
of activities, such as split and join nodes.
While the association between nodes and edges are defined at the node
level, the cardinality of the association between special types of nodes (activity
models, event models, and gateway models) differs. Each activity model has
exactly one incoming and one outgoing edge.
Each process starts with exactly one event, the initial event, and ends
with exactly one event, the final event. Therefore, certain events can have
no incoming edges (initial event) or no outgoing edges (final event). Gateway
models represent control flow. Therefore, they can act as either split nodes
or join nodes, but not both. Hence, each gateway model can have multiple
outgoing edges (split gateway node) or multiple incoming edges (join gateway
node).

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec D -- By Mathias Weske

Activity Models and Activity Instances
Business functions provide a high-level, coarse-grained representation of the work conducted by enterprises. Activities can be found in the leaves of the functional decomposition. This section investigates how activities can be described. In addition, the actual work conducted during business processes has to be characterized, i.e., activity instances have to be characterized. Note that activity models represent the M1 layer of the Meta Object Facility, while the activity instance layer corresponds to M0.
An activity model describes a set of similar activity instances, analogously to a process model describing a set of process instances with the same structure. While process models are typically expressed in graph-like notations (to
be investigated in detail in the next chapter), activity models can be expressed
in different forms, for instance, by plain text or by some formal specification
or references to software components that implement them.
Activity instances represent the actual work conducted during business
processes, the actual units of work. To make this discussion more concrete,
assume a process instance that represents the processing of an insurance claim
by Clara Smith on the damage amount of US $2000, submitted November 11,
2006. Let EnterClaim(Clara Smith, 2000, 11-11-2006) represent the activity
instance responsible for entering the claim in the software systems of the insurance
company. When the company receives the claim, a process instance is
started. Within this process instance, the activity instance EnterClaim(Clara
Smith, 2000, 11-11-2006) is started. When the claim is entered in the system,
this activity instance terminates.
Each activity instance during its lifetime is in different states. These states
and the respective state transitions can be represented by a state transition
diagram. The states
that an activity instance adopts during its lifetime are described as follows:
when it is created it enters the init state. By the enabled state transition the
activity instance can enter the ready state.
If a particular activity instance is not required, then the activity instance
can be skipped, represented by a skip state transition from the not started
state to the skipped state. From the ready state, the activity instance can
use the begin state transition to enter the running state. When the activity
instance has completed its work, the terminate state transition transfers it to the terminated state. When an activity instance is in the terminated or the
skipped state, then it is closed.
The state transition diagram representing the complex behaviour of activity instances is a refinement of the state transition diagram representing their simple behaviour. All state transitions possible in the simple diagram are also possible in the complex state transition diagram. The activity instance is initiated, and it enters the ready state before entering the running state. Finally, the activity instance terminates. However, the substates of the termination state are not represented. The simple diagram does not provide different states for successful and unsuccessful termination. When an activity instance can be started, it enters the ready state. If during the execution of a process instance certain activity instances are currently not available for execution, they can be disabled. Activity instances that are initialized, disabled, or enabled are in the not started state. Once an activity instance is ready, it can be started, entering the running state. Running activities can be temporarily suspended, to be resumed later. An activity instance can terminate either successfully or in failure. Terminated activity instances can be undone, using compensation or transactional recovery techniques. Based on the description of the behaviour of an activity instance, the question now arises on how to capture the actual behaviour of a concrete activity instance, i.e., on how to specify the trace of states and state transitions that the activity instance went through. In this section, events and event orderings are introduced to properly represent the essence of activity instances. The basic idea of using events for representing activity instances is quite simple: each state transition of an activity instance is represented by an event.
These events have a temporal ordering. Based on the state transition diagram for activity instances, each activity instance can be represented by a totally ordered set of events.
The causal ordering of events indicated by this definition can be graphically represented by event diagrams. In event diagrams, time proceeds from left to right, and events are shown as bullets. The causal relationships of events are represented by directed arcs. Due to the nature of event diagrams, they form directed acyclic graphs, where the nodes are events and the edges reflect causal ordering between events.
In the event diagram shown in part (a) of that figure, an activity instance that is properly executed is shown, while (b) shows the events of a skipped activity instance. To illustrate the relationship between state transition diagrams and event diagrams, each state transition ito the state transition diagram is associated with an event in the respective event diagram. The activity instance starts with a state transition to the init state. This state transition is represented by an initialize event in the event diagram. An enable state transition brings the activity instance in the ready state; this state transition is represented by an enable event. An activity instance in the ready state can be started, represented by the begin state transition. Finally, the terminate state transition completes the activity instance. Events are points in time, i.e., events do not take time. The time interval in which an activity instance is in one state is delimited by two events, the event representing the state transition to enter the state and the event representing the state transition to leave the state. For example, the time interval in which
the activity instance is in the running state is delimited by the begin and
terminate events.

Friday, July 24, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec C -- By Mathias Weske

Vertical Abstraction

Vertical abstraction in business process modelling is depicted in Figure 3.3, where distinct modelling subdomains are identified. As depicted, process modelling is at the centre of the modelling effort, because it also integrates the modelling efforts that are conducted in the other subdomains.
Function modelling, data modelling, organization modelling, and modelling of the operational information technology landscape are required to provide a complete picture of a business process. While these subdomains are the most important ones, additional subdomains can be defined if they are relevant. The functional model investigates the units of work that are being enacted in the context of business processes. The specification of the work can be done at different aggregation levels, from coarse-grained business functions to finegranular functions at the operational level that are realized by knowledge workers and information systems.
The specification of these functions can be informal, using English text or formal, using syntactic or semantic specifications of functions. While informal descriptions are mostly done at the coarse business level, more precise speci- fications are required in the software layer when it comes to implementation of certain functions using information systems. The investigation and proper representation of data in business processes is important, because decisions made during a business process depend on particular data values. Also data dependencies between activities need to be taken into account in process design, to avoid situations in which a function requires certain data not available at that time. The proper representation of the organizational structure of a company is an important requirement. Activities in the business process can then be associated with particular roles or departments in the organization. Many activities in a business process are performed by or with the assistance of information systems. The operational information technology landscape, i.e., the information systems, their relationships, and their programming interfaces, needs to be represented to use the functionality provided by the information systems. Process modelling defines the glue between the subdomains. A process model relates functions of a business process with execution constraints, so that, for instance, the ordering and conditional execution of functions can be specified. Data aspects are covered because particular process instances may depend on the structure and value of data involved in a particular business process. For example, in a credit approval business process, the type of approval depends on the credit amount requested. In addition, data dependencies between activities need to be taken into account in process model design.

From Business Functions to Business Processes

Value chains provide a high-level organization of the functions that an enterprise performs. To provide a more detailed view, these top-level business functions are broken down to functions of smaller granularity and, ultimately, to activities of operational business processes. Functional decomposition is the technique of choice. A partial functional decomposition of a value chain is shown in Figure 3.4, where a value system represents the highest level of aggregation.
The ordering of the value chains in the value system is not represented in this structure diagram because it does not have any formal meaning. There are complex interactions between these companies, so that, obviously, not all activities in the supplier value chain occur before all activities conducted by enterprise E.
The functional decomposition of the value chain of enterprise E is exemplified for one particular path of functions in the marketing and sales top-level business function. Among many other functions, marketing and sales includes a business function, OrderManagement, that contains functions related to the management of incoming orders. Order management is decomposed further into business functions for getting and checking orders. To check orders, they need to be analyzed, and there are functions for simple and advanced checking of orders. There are different symbols for business functions and for functions of the finest granularity: business functions are represented by rectangles, while functions of the finest granularity are represented by rectangles with rounded corners. Functions at the leaf level of the functional decomposition are also called activities. Traditionally, functional decomposition was used to describe enterprises based on the functions they perform. As discussed in Chapter 1, concentrating on the functions an enterprise performs and neglecting their interplay falls short of properly representing how enterprises work. Therefore, functional decomposition is used as first step in the representation of enterprises based on business processes.
Operational business processes relate activities to each other by introducing execution constraints between them. In principle, relating functions to business processes can be applied for different granularities of business functions. In case high-level business functions are considered, a textual specification of the process is used, since concrete execution constraints between their constituents are not relevant in coarse-grained business functions. Consider, for instance, the business functions incoming logistics and operations. At this very coarse level of functionality, no ordering of these business functions is feasible: both business functions are performed concurrently, and only at a lower level of granularity does a concrete ordering make sense. For instance, when the operations business function orders additional material, then there are concrete activities that have a concrete ordering. Within operations, an internal order is created and sent to incoming logistics. On arrival of this order, raw material is provided to operations. In case no raw material is available at the manufacturing company, an external order is created and sent to a supplier of the raw material. Therefore, business processes relate fine-grained business functions, typically the leaves of the business function decomposition tree.
The sample business process starts with analyzing the order, and then conducting either a simple check or an advanced check depending on the decision made during process execution. This process has a dedicated start event and a dedicated end event. The business process is started once the start event occurs; when it completes, an end event occurs. Events play a crucial role when interrelationships between business processes are expressed. A particular business function of higher granularity (CheckOrder) consists of fine-grained activities, which are related by execution constraints. However, the check order business function (and the business process that realizes it) is related to other business functions and their respective business processes. An example showing this situation is displayed in Figure 3.6, where a part of the value chain is shown, in particular, the business functions Receive Request, Request Analysis, and Quota Management are shown. Since there is a strict ordering between these business functions, an execution ordering relation is represented.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec B -- By Mathias Weske

Abstraction Concepts

To capture the complexity in business process management, different abstraction concepts are introduced. A traditional abstraction concept in computer science is the separation of modelling levels, from instance level to model level to metamodel level, denoted by horizontal abstraction. Horizontal abstraction concepts in business process management are discussed in Section 3.2.1. Even when using horizontal abstraction, separate subdomains need to be investigated. In order to follow the divide-and-conquer approach, these subdomains need to be represented separately. This abstraction mechanism is called vertical abstraction, and is discussed in Section 3.2.2. Aggregation can also be used to cope with complexity, motivating another type of abstraction. At a higher level of abstraction, multiple elements of a lower level of abstraction can be grouped and represented by a single artefact. For example, a set of functional activities of small granularity can contribute to a particular business function at a higher level of granularity: a coarse-grained business function “order management” might aggregate many smaller-grained activities, like receiving an incoming order, checking the inventory, and con- firming the order. This type of abstraction is called aggregation abstraction, because the coarse-grained business function aggregates activities of smaller granularity. Aggregation abstraction is different from horizontal abstraction, because all activities (the small-grained and the coarse-grained) are at one horizontal level of abstraction, e.g., the instance level. Aggregation abstraction is primarily used in the functional subdomain, where functions of smaller granularity are combined to create functions of larger granularity.

Horizontal Abstraction

Along the lines of the levels of abstraction identified by the Object Management Group, the metamodel level, the model level, and the instance level play important roles in the design and analysis of complex systems in general and software systems in particular. It is instructive to explain these levels in a bottom-up order, starting with the instance level. The instance level reflects the concrete entities that are involved in business processes. Executed activities, concrete data values, and resources and persons are represented at the instance level. To organize the complexity of business process scenarios, a set of similar entities at the instance level are identified and classified at the model level.
For instance, a set of similar business process instances are classified and represented by a business process model. In object modelling, a set of similar entities is represented by a class, and in data modelling using the Entity Relationship approach, a set of similar entities is represented by an entity type, and similar relationships between entity types are represented by a relationship type.
Models are expressed in metamodels that are associated with notations, often of a graphical nature. For instance, the Petri net metamodel defines Petri nets to consist of places and transitions that form a directed bipartite graph. The traditional Petri net notation associates graphical symbols with metamodel elements. For instance, places are represented by circles, transitions by rectangles, and the graph structure by directed edges. In data modelling, the Entity Relationship metamodel defines entity types, relationship types, and connections between them. Typical graphical notations of the Entity Relationship metamodel are rectangles for entity types and diamonds for relationship types, connected by lines. While often there is one graphical notation for one approach, a one-to-one correspondence between notation and metamodel is not mandatory. In a Petri net, the concept of a transition could also be represented by another symbol in a graphical notation. There are different notations for representing Petrinets, which differ in the graphical representation of transitions. While some
use rectangles, others use solid bars.
Therefore, it is important to distinguish between the concepts of a modelling
approach and the graphical notation used to represent these concepts.
The complete set of concepts and associations between concepts is called metamodel.
A metamodel becomes useful if there is a notation for this metamodel
that allows expressing models in a convenient way that allows communication
between stakeholders in the modelled real-world situation.
The different levels of abstraction and their relationships are shown in
Figure 3.2. A notation associated with a metamodel allows expressing the
concepts of that particular metamodel. Each model is described by a metamodel,
and is expressed in a notation associated with the metamodel.


Wednesday, July 22, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec A -- By Mathias Weske

Conceptual Model and Terminology

While the terms mentioned have been used in the previous chapters informally, the concepts behind these terms and their relationships will now be discussed in more detail, using conceptual
models. These models are expressed in the Unified Modeling Language, an
object-oriented modelling and design language.
Business processes consist of activities whose coordinated execution realizes
some business goal. These activities can be system activities, user interaction
activities, or manual activities. Manual activities are not supported by
information systems. An example of a manual activity is sending a parcel to
a business partner.
User interaction activities go a step further: these are activities that knowledge
workers perform, using information systems. There is no physical activity
involved. An example of a human interaction activity is entering data on an
insurance claim in a call centre environment. Since humans use information
systems to perform these activities, applications with appropriate user interfaces
need to be in place to allow effective work. These applications need to
be connected to back-end application systems that store the entered data and
make it available for future use.
Some activities that are conducted during the enactment of a business
process are of manual nature, but state changes are entered in a business
process management system by means of user interaction activities. For instance,
the delivery of a parcel can be monitored by an information system.
Typically, the actual delivery of a parcel is acknowledged by the recipient
with her signature. The actual delivery is important information in logistics
business processes that needs to be represented properly by information systems.
There are several types of events during a logistics process. These events
are often available to the user as tracking information. While the activities
are of manual nature, an information system—the tracking system—receives
information on the current status of the process.

System activities do not involve a human user; they are executed by information
systems. An example of a system activity is retrieving stock information
from a stock broker application or checking the balance of a bank
account. It is assumed that the actual parameters required for the invocation
are available. If a human user provides this information, then it is a user
interaction activity. Both types of activities require access to the respective
software systems.
Certain parts of a business process can be enacted by workflow technology.
A workflow management system can make sure that the activities of a business
process are performed in the order specified, and that the information systems
are invoked to realize the business functionality. This relationship between
business processes and workflows is represented by an association between
the respective classes. We argue that workflow is not a subclass of business
process, since a workflow realizes a part of a business process, so a workflow
is not in an “is-a” relationship with a business process, but is an association.
With regard to the types of activities mentioned, system activities are associated
with workflows, since system activities can participate in any kind
of workflow, system workflow or human interaction workflow. User interaction
activities and manual activities, however, can only participate in human
interaction workflows.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec M -- By Mathias Weske

Enterprise Services and Service-Oriented Architectures


The roles in service-oriented architectures as discussed above are not completely
filled in typical enterprise scenarios. The specification of services is
typically done by the provider of the service, i.e., by the system architects
responsible for service-enabling the particular application.
The service registry is installed locally, and its access by other companies
is usually disallowed. The most striking difference to service-oriented architectures
as defined by Burbeck is the absence of dynamic matchmaking. As
enterprise services are developed, they are specified and registered in a local
registry. When a new composite application is developed, the designers consult
the registry to find suitable services that can be used to perform certain
tasks in the composite application. This search is a manual process, which in
some cases is assisted by a taxonomy and a textual description of the services.
There are a number of hard problems in this context that are unsolved
today. One of the main problems regards the scoping of services: the functionality
provided by one or more application systems that is suitable for an
enterprise service. If the granularity is small, then the level of reuse is small
too, because many enterprise services need to be composed to achieve the
desired functionality.
If on the other hand the granularity is large, then there might be only
few scenarios where the enterprise service fits well and where using it makes
sense. Tailoring of services of large granularity is also not a valid option, since
extensive tailoring hampers reuse. As in many related cases, there is no general
answer to this question. The choice of a suitable service granularity depends on
the particular usage scenario and on the properties of the application systems
to integrate and the composite applications to develop.
In enterprise services architectures, each enterprise service is typically associated
with exactly one application system. This is a limitation, since building
an enterprise service on top of a number of related back-end application
systems involves system integration, so that reuse is simplified.
To illustrate this concept, an example is introduced. Consider a purchase
order enterprise service in which an incoming purchase order needs to be stored
in multiple back-end application systems. In this case, the enterprise service
can be used with ease, since it is invoked once by a composite application and
it automatically provides the integration of the back-end system by storing
the purchase order—with the relevant data mappings to cater to data type
heterogeneity—in the respective back-end application systems.
An integration of legacy systems can be realized within an enterprise service.
This allows using enterprise services at a higher level of granularity, so
that integration work can actually be reused in multiple composite applications.


Enterprise Services Bus


In a recent development, enterprise application integration middleware provides
standardized software interfaces to the enterprise applications that it
integrates. As the term enterprise service bus indicates, each of these enterprise applications is then attached to this bus, which acts as a centralized component to integrate these applications
An enterprise service bus hides the heterogeneity of the enterprise applications
by introducing service interfaces. To realize these service interfaces,
traditional enterprise application integration adapter technology is typically
used that is also in place in traditional enterprise application integration middleware,
as discussed in Section 2.2.2.
By introducing standardized interfaces to the outside world using services,
however, an enterprise service bus goes one step beyond traditional enterprise
application integration middleware. It must not be overlooked, however, that
the term enterprise service bus is also used by software vendors to rebrand
existing technologies for marketing reasons.

Service Composition


To realize composite applications in service-oriented enterprise computing environments,
service composition techniques are appropriate. The general principle
of service composition is depicted in Figure 2.25, where application systems
in the lower part of the figure represent services that can be used to
realize composite applications.
The composite application shown uses functionality provided by a CRM
system, an SCM system, and an ERP system. The application logic realized
in the composite application defines a process consisting of three activities.
The ordering of these activities can be specified in a process model.
Since the business process is realized by a composition of services, processes
of this kind are also called service compositions.
Enterprise application integration middleware in general and enterprise
service bus middleware in particular provide a good technical basis to realize
service compositions, because they provide standardized services interfaces
that can be used in service compositions. Typical enterprise application integration
middleware features a system workflow component that uses either a
proprietary format for system workflows or, if it is based on services, the Business
Process Execution Language for Web services.

Monday, July 20, 2009

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec L -- By Mathias Weske

Enterprise Services

In enterprise computing environments, the functionality of application systems can be described and provided by services. Figure 2.22 visualizes a serviceenabled application system. The functionality of the application system is provided through services, depicted by semicircles on top of the application system. Services need to be specified in a way that the specification of services is decoupled from their implementation. Detailed specification of services facilitates
the flexible configuration of services by composing services to achieve
complex functionality.
In an existing application built with several services provided by different
business partners, the partners can modify the realization of their services, as
long as the service specification does not change. Based on the service specification,
an improved service implementation can be integrated seamlessly in
a service-based application. New potential business partners can use publicly
available service specifications to offer their own implementations of the services.
As a result, individual parts of a complex service-based application can
be exchanged without redesigning the application.
Service orientation is also one of the main influencing factors for enterprise
application integration. Enterprise services architecture characterizes the development
of added-value applications that take advantage of existing functionality
provided through standardized interfaces.
Enterprise services architecture is based on the understanding that complex
applications will be increasingly built on top of existing functionality.
This functionality is provided by legacy systems, which are an important asset
of companies. Making this functionality reusable is a challenging task. The
idea is to encapsulate the functionality of existing software systems in a service,
realizing enterprise services. Enterprise services can be used to realize
enterprise application integration scenarios.
As pointed out by Woods, there are a number of business drivers that
foster the development of enterprise services. The main driver is change: the
ability to change the enterprise application system infrastructure is a competitive
advantage for an enterprise. There are a number of current trends that
motivate the development of enterprise services:
• Rise in the power of the customer: Value-added services are essential, because
customers can change suppliers easily, without much effort. Positive
user experience is important, as the success of online auctioning sites and
online shops with community building indicates.
• Systems transparency: The Internet has brought customers and suppliers
inside a company’s IT infrastructure. Weak or missing integration of enterprise
application systems will be immediately exposed to the customer.
• Rise in computer mediated interaction with customers and suppliers: Companies
differentiate themselves on their service to their customers. Dan
Woods indicates that “Outsiders can now peer into the glass house of the
data centre and see if it is a mess.” An example of a messy situation is
one where a customer cannot be serviced well, because the client interface
provides information only about one aspect of the customer, and the
other aspects are hidden in application systems that are not accessible.
Due to lack of integration, this valuable information is not available, so
the customer does not feel well cared for.
• Products as services: Corporations are increasingly perceived by the set
of services they provide. These services exposed to the market can be
realized by enterprise services, which provided by the back end application
systems of the enterprise. But also services provided by third parties can
be integrated, so that better applications and end user services can be
provided to the customer.
• Multi-tier applications: There is also a trend towards multi-tier applications,
where each tier is provided by a different enterprise. This means that
the tier 1 company provides value-added services directly to a customer,
using the tier 2 services from a set of business partner companies. These
companies might use tier 3 services provided by other companies. By flexible
integration based on the service paradigm, many new applications and
services can be realized.

Composite Service-Based Applications

With this background in enterprise services architectures, an intra-company scenario is sketched, where new applications should be built on top of an existing customer relationship management system, a supply chain management system, and an enterprise resource planning system. These systems expose enterprise services via standardized interfaces. The applications built on top are known as composite applications, as shown in Figure 2.23. Composite applications invoke enterprise services that provide the functionality of the underlying back-end systems. User interaction is realized by dedicated graphical user interfaces that sit on top of composite applications. Technological advance has paved the way for enterprise services. The main cornerstones of these developments are the full suites of enterprise applications that are available off-the-shelf today. There are rich middleware and enterprise application integration products that can be used for technical integration, most of which host a dedicated workflow component for process enactment. To integrate multiple application systems, data transformation is essential. With the advent of the extensible markup language (XML), there is an industry standard for data and message format specifications. While this base technology is in place, the integration logic still needs to be defined and
implemented in each integration project.
Processes are a key factor in realizing composite applications, because they provide a link from high-level business processes to the information technology layer. The structure of composite applications can in many cases be expressed as a business process. The activities of these processes are implemented by invoking enterprise services. Additional execution constraints like conditional execution can be represented by business process models; these can be realized by process orchestrations. Enterprise services can also be used to realize business interactions of multiple enterprises. In multi-tier scenarios for realizing innovative applications, interactions between the software systems of the business partners involved are required. These interactions are governed by a process choreography. Process choreographies have been defined informally above; they are subject of further investigation in Chapter 5. While the vision for enterprise services includes business-to-business processes, most enterprise services today are used in an intra-company setting, where the goal is to develop composite applications on top of well-specified business functionality represented by enterprise services.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec K -- By Mathias Weske

Enterprise Services Computing

Service-oriented computing is one of the major trends both in business engineering and software technology. The main idea of service orientation is to capture business relevant functionality as a service and provide sufficiently detailed information so that customers can use it. This definition of service orientation goes well beyond services that are realized by software systems. Consider a real-world service, for example, one to fix a car. The service the garage provides needs to be specified in a way that the customer can find and use. Once the car is fixed, the customer pays the bill and the service is completed. There are specific registries for finding real-world services, for instance, yellow page directories. This general idea of service orientation is applied to services provided by software systems. The requirements that apply to real-world services also need to be satisfied for services realized by software systems. Service-oriented computing uses well-specified service interfaces that rely on common interface definition languages to combine several services to new service-oriented applications. If service-oriented computing is used in largescale environments, an organizing principle is useful; this principle is introduced by service-oriented architectures, discussed next.

Service-Oriented Architectures

Steve Burbeck, one of the early advocates of service-oriented architectures, defines service-orientation as follows. Services are loosely-coupled computing tasks communicating over the internet that play a growing part in business-to-business interactions. [...] We reserve the term service-oriented for architectures that focus on how services are described and organized to support their dynamic, automated discovery and use. We do not address systems based on manually hardwired interactions, such as those used in EDI systems. In this definition, services communicate over the Internet. This means that services are expected to be used in business-to-business scenarios, where the participants are connected by the Internet. Although not explicitly ruled out, services that are provided and used within a company do not fully qualify in Burbeck’s definition. The second interesting aspect of this definition is the high degree of flexibility provided by late, run time finding and binding of services. Matching a service request to a set of service specifications in a service registry is a complex task, especially if automated discovery and use are sought, as implied by the definition. Burbeck’s definition mirrors the long-term vision of service-oriented architectures. But this architectural style is not only useful in Internet settings, where the services are provided by different organizations in businessto- business scenarios, but also in intracompany settings. Therefore this book adopts the following definitions. Definition 2.7 A service captures functionality with a business value that is ready to be used. Services are made available by service providers. A service requires a service description that can be accessed and understood by potential service requestors. Software services are services that are realized by software systems. Service-oriented architectures are software architectures that provide an environment for describing and finding software services, and for binding to services. Descriptions of software services provide a level of detail that facilitates service requestors to bind to and invoke them.  Service-oriented architectures are especially important in environments where many services are available and where the set of available services changes over time. Burbeck investigates this aspect in more detail and states as follows. To work easily, flexibly, and well together, services must be based on shared organizing principles that constitute a service-oriented architecture.

In a service-oriented architecture, organizations may use services offered by other companies, and companies may provide services to a growing services market. The vision is for information systems to use business functionality of service providers, so that reuse of functionality is realized at a level of coarse granularity. New applications can be built with less effort and existing applications can be efficiently adapted to changing requirements, reducing maintenance and development cost.
To enable service requestors to find and use them, they are specified, and their descriptions are stored in a service registry. The interactions between the three primary roles in service-oriented architecture are publish, request/reply, and bind. The service provider publishes service specifications in a service registry, and the service requestor searches the service registry and finds suitable services. The service registry provides the service requestor with information that allows the service requestor to bind to the service and, eventually, invoke it.

Sunday, July 19, 2009

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec J -- By Mathias Weske

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 implementation aspects do not matter for the users of these systems. Therefore, special care has to be taken in the rollout of workflow applications; early participation 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.

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 required to access the application system functionality. Another important source of trouble is relationships between different applications at the code level. Direct invocation between software systems is an example of these relationships, so that an invocation of an application system 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 functionality 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 impossible 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 enacted following a process model. Similar developments can be found in publishing 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 reservation
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 getting
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 systems,
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 integration
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

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec i -- By Mathias Weske

Human Interaction Workflows

In order to introduce human interaction workflows, it is useful to discuss its development. An early predecessor of human interaction workflow management systems is the office automation system, developed in the early 1980s. The goal of these systems was supporting the organization and the collaboration 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 business 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 interact with information systems are called human 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.
Goals attributed to human interaction workflows are reduction of idle periods, 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. 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 interact 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 application. The workflow management system then computes the current state and determines the activities next due.

Friday, July 17, 2009

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec H -- By Mathias Weske

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
without coding.
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.

System Workflows

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
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 dedicated
workflow component.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec G -- By Mathias Weske

Business-to-Business Processes

The business motivation behind interacting business processes stems from
value systems, which represent collaborations between the value chains of
multiple companies. These high-level collaborations are realized by interacting
business processes, each of which is run by one company in a business to
business process scenario. This section studies interactions between business
processes performed by different companies.
For the sake of concreteness, this section uses an example from the area of
order processing, described as follows. A buyer orders goods from a reseller,
who acts as an intermediary. The reseller sends a respective product request to
a manufacturer, who delivers to product to the buyer. In addition, the reseller
asks a payment organization to take care of the billing.
There are many interesting issues to study: how do we make sure that the
business-to-business process created by putting together a set of existing business
processes really fulfils its requirements? Structural criteria, for instance,
absence from deadlock, need to be valid for these processes.
The problem is aggravated by the fact that internal business processes are
an important asset of enterprises. Therefore, few enterprises like to expose
their internal processes to the outside world. This means that the properties of the overall business-to-business collaboration cannot be based on the actual
detailed local processes run by the enterprises, but rather on the externally
visible behaviour and the associated models to represent it.

Workflow Management

The developments in enterprise software architectures and in organizationlevel
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 interpret
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.

Thursday, July 16, 2009

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec F -- By Mathias Weske

Organizational Business Processes

The early 1990s saw process orientation as a strong development not only to
capture the activities a company performs, but also to study and improve the
relationships between these activities.
The book Reengineering the Corporation, which was briefly discussed in
Section 1.1, proved instrumental in this development. The general approach
of business process reengineering is a holistic view on an enterprise where
business processes are the main instrument for organizing the operations of
an enterprise. Business process reengineering is based on the understanding that the products and services a company offers to the market are provided
through business processes, and a radical redesign of these processes is the
road to success.
Process orientation is based on a critical analysis of Taylorism as a concept
to organize work, originally introduced by Frederick Taylor to improve industrial
efficiency. This approach uses functional breakdown of complex work to
small granularities, so that a highly specialized work force can efficiently conduct
these work units of small granularity. Taylorism has been very successful
in manufacturing and has, as such, fuelled the industrial revolution in the late
eighteenth and early nineteenth century considerably.
Small-grained activities conducted by highly specialized personnel require
many handovers of work in order to process a given task. In early manufacturing
in the late eighteenth and early nineteenth century the products
were typically assembled in a few steps only, so that handovers of work did
not introduce delays. In addition, the task were of a rather simple nature, so
that no context information on previously conducted steps was required for a
particular worker.
Using Taylorism to organize work in modern organizations proved inefficient,
because the steps during a business process are often related to
each other. Context information on the complete case is required during the
process. The handovers of work cause a major problem, since each worker
involved requires knowledge on the overall case. For this reason, the functional
breakdown of work in fine-granular pieces that proved effective in early
manufacturing proves inefficient in modern business organizations that mainly
process information.
From a process perspective, it is instrumental to combining multiple units
of work of small granularity into work units of larger granularity. Thereby, the
handover of work can be reduced. But this approach requires workers to have
broad skills and competencies, i.e., it requires knowledge workers who have a
broad understanding of the ultimate goals of their work.
At an organizational level, process orientation has led to the characterization
of the operations of an enterprise using business processes. While there
are different approaches, they have in common the fact that the top-level business
processes are expressed in an informal way, often even in plain English
text. Also each enterprise should not have more than about a dozen organisational
business processes. These processes are often described by the same
symbols as those used for value systems, but the reader should be aware of
the fact that different levels of abstraction are in place.
The structure of organization-level business process management is shown
in Figure 2.12. The business process management space is influenced by the
business strategy of the enterprise, i.e., by the target markets, by business
strategies opening new opportunities, and, in general, by the overall strategic
goals of the enterprise.
Business process management is based on the resources of an enterprise,
most prominently on the information systems in place. Information systems
enable knowledge workers to perform business process activities in an effective
manner. Information systems also have implications on business processes,
since some business processes might not be possible without appropriate information
system support.
Stakeholders are among the most important influential factors of business
process management. The stakeholder box in the left hand side in Figure 2.12
represents the fact that stakeholders have implications on the organizational
business processes. But business processes also have implications on the stakeholders,
as shown in that figure, too. Stakeholders include external business
partners, customers, and the personnel of the enterprise.
The organizational business processes are influenced by a number of activities
that the company performs: the management, the organization, the controlling,
and the optimization of business processes, as shown in Figure 2.12.
Management and organization include activities for the identification of
business processes, as well as the selection of roles and persons responsible, and
the rollout of the implemented business processes in the enterprise. Setting
up a business process management team and, if desired, installing a Chief
Process Officer in the management of the enterprise are additional activities.
Each business process contributes to one or more business goals. To gain
information on how efficient the business processes are actually conducted
and whether the business goals are actually met by the business processes,
controlling activities are conducted. Key performance indicators of business
processes are determined, for instance technical indicators, such as average
response time and throughput, but also domain-specific aspects, such as, for
instance, reduction of error rate, and cost savings.
Controlling also develops methods to measure key performance indicators
and to actually install them in the operational business processes. Valuable
information on shortcomings of current business processes can be found, which
can be used to continuously improve and optimize them.
Organizational business processes have a large granularity, and they involve
many persons and activities in a company. Therefore, they are typically
described in a textual form, often using a forms-based approach. This means
that individual process activities and their orderings are not addressed. The
elements of these forms include the name of the business process, a person
responsible for it, the objects addressed, the inputs and the results of the process, and the suppliers and customers of the process, both of which are
organizational business processes.

Business Process Management (Part-1 Foundation[Chapter II Evolution of Enterprise Systems Architectures ] ) Sec E -- By Mathias Weske

Enterprise Modelling and Process Orientation

In addition to developments in software architecture, business administration
also contributed to the rise of business process management. There were two
major factors that fuelled workflow management and business process management.
Value chains as a means to functionally break down the activities a
company performs and to analyze their contribution to the commercial success
of the company, and process orientation as the way to organize the activities
of enterprises.

Value Chains

Value chains are a well-known approach in business administration to organize
the work that a company conducts to achieve its business goals. Value chains were developed by Michael Porter to organize high-level business functions and
to relate them to each other, providing an understanding of how a company
operates.
Porter states that “the configuration of each activity embodies the way
that activity is performed, including the types of human and physical assets
employed and the associated organizational arrangements” and he continues
to look at the enterprise and its ecology by stating that “gaining and sustaining
competitive advantage depends on understanding not only a firm’s value chain
but how the firm fits in the overall value system.”
In order to fulfil their business goals, companies cooperate with each other,
i.e., the value chains of these companies are related to each other. The ecology
of the value chains of cooperating enterprises is called value system. Each value
system consists of a number of value chains, each of which is associated with
one enterprise.
The value chain of a company has a rich internal structure, which is represented
by a set of coarse-grained business functions. These high-level business
functions, for instance, order management and human resources, can be broken
down into smaller functional units, spanning a hierarchical structure of
business functions of different granularity.
The process of breaking down a coarse-grained function into finer-grained
functions is called functional decomposition. Functional decomposition is an
important concept to capture and manage complexity. For instance, order
management can be broken down into business functions to obtain and store
an order and to check an order.
Figure 2.9 depicts a typical value system of an enterprise E, shown at the
centre of the value system. This enterprise manufactures goods. In order to
do so, it cooperates with suppliers S1 and S2 that provide raw material. To
bring the products to its customers, enterprise E cooperates with transport
and logistics companies that realize a channel from the manufacturer E to the
buyers.
The graphical arrangements of value chains in the context of a value system
are centred at the enterprise under consideration, enterprise E in the example.
If channel enterprise C1 was addressed, then C1 would have been drawn
in the centre, and it would have E among its incoming value chains and a
set of buyers among its outgoing value chains. Value systems provide a very
high-level characterization of the relationship of a particular enterprise to its
business environment.
The arrangement of the value chains in a value system does not imply any
particular ordering of the functions that the respective companies conduct.
Therefore, value chains do not have a formal meaning as far as the ordering
of the business functions is concerned. The arrangement of the value chains in
Figure 2.9 is quite obvious in a manufacturing environment, where enterprise
E receives raw material from its suppliers (incoming value chains) and delivers
products via its channels to its buyers (outgoing value chains).
In order to realize collaboration between suppliers, the manufacturer, channel
companies, and buyers, many activities have to be performed in a coordinated
fashion. The manufacturing enterprise E needs to negotiate a contract
with each supplier, and the flow of incoming raw material must be planned
and controlled properly. As a result, there are multiple interactions between
the enterprise and its business partners.
Although the ordering of the value chains indicates that the flow of information
and goods is from left to right, i.e., from supplier to enterprise E, in
this case the start of interaction is in the opposite direction, i.e., from E to the
supplier. The ordering of the value chains in a value system loosely follow the
overall impression the modeller wants to communicate with the value system.
The concrete interactions that realize the business collaboration are complex
interactions.
In the sample value system shown, the overall flow of goods and information
is from left to right. There are, however, also interactions in the opposite
direction. For instance, the ordering of raw material by the enterprise E from
Supplier 1 is realized by an interaction between these companies that originates
from E. This interaction is performed if the need for raw material is
determined.
This situation is depicted in Figure 2.10, in which the logical ordering of
the value chains in a subset of the value system shown above in Figure 2.9
is enriched by arrows between the value chains, representing interactions between
Enterprise E and Suppliers 1 and 2.
The value chain of a company subsumes all activities that the enterprise
conducts to fulfil its business goals. The organization of the business functions
within a value chain is shown in Figure 2.11. (Porter uses the term activity
for these highest-level business functions. To provide a consistent terminology
and to be in line with business process terminology, the term business function
is used in this book.) The value chain is based on a functional organization
of an enterprise, where the activities that are conducted are organized into
business functions.
From a business administration point of view, the business functions that
a company performs can be partitioned into primary functions and support functions. Primary functions contribute directly to the competitive advantage
of the company, while secondary functions provide the environment in which
the primary functions can be performed efficiently. The secondary business
functions include human resources, technology development, procurement,
and the infrastructure, all of which are required for supporting the primary
business functions.
All functions that a company performs need to contribute to the success of
the company, and the margin is the difference between the resources invested
and the revenue generated by the company. The primary business functions
of a value chain are as follows.
• Inbound Logistics: Business functions that collectively make sure the company
receives raw material, goods and information, required for performing
its business. For instance, in order to realize inbound logistics, a set
of suppliers needs to be identified, contracts need to be negotiated, and
operational procedures need to be in place. Inbound logistics interact significantly
with business partners to request quotations, to collect and select offers, to negotiate contracts, to organize transportation, and to manage
incoming goods and information.
• Operations: Operations aggregate business functions responsible for producing
added-value products that contribute directly to the revenue of the
company. In a manufacturing company, the products are produced by the
operations business function.
• Outbound Logistics: Once products are manufactured, outbound logistics
take care of distributing these products to warehouses or other distributing
centres so that they can be distributed to the customers.
• Marketing and Sales: In marketing and sales, the business functions for
marketing the company’s products and for selling them in a competitive
market are organized. The typical function in this primary business function
is organizing and conducting a campaign to market a new product.
• Services: Once a product is sold, the company needs to keep in touch
with buyers, both to cater to problems with the sold product and to provide
valuable customer information for developing and marketing future
products.
While Porter explains very well the functional decomposition of business functions,
he does not identify the role of processes, although processes fit very
well into the value chain approach. Below, the relationships of business functions
that a firm performs in the context of a value system are identified and
captured in business processes.
Due to the complexity inherent in large-scale organizations, the granularity
of business processes needs to be in line with the particular goals associated
with the business function that a particular business process supports. By
doing so, a complete picture of the work conducted by a company and the
processes that contribute to it can be developed.
While the approach by Porter is tailored towards traditional enterprises,
for instance, manufacturing, there is a rich set of extensions of Porter’s work.
Due to the technical scope of this book, these extensions and the business
implications of value chains and value systems are not discussed in detail.
However, value systems provide an appropriate holistic setting for the business
administration background of business process management.