"Goal-oriented Business Process Management"

If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"The Living Systems Process Suite is the only Business Process Management Suite (BPMS) that effectively captures and actively follows business goals with Goal-Oriented BPM. Leveraging smart self-adaptive software technology, it delivers end-to-end agility to structured and unstructured processes."
Source: Whitestein Technologies AG.

Resources Related to Goal-oriented Business Process Management:

• Business Process Management (BPM) (Wikipedia)
• Goal-oriented (Wikipedia)

Goal-oriented Business Process Management

1. Evolving Business Process Management
1.1 Introduction

The Importance of Business Processes

Business processes consist of a set of activities connected in a structured whole; they are a fundamental component of every enterprise. Their effective setup, execution, and evolution is of paramount importance to business operations:

• They constitute the organizational knowledge of the enterprise.
• They gather and structure the identity of the enterprise.
• They explicitly represent the basis for continuous improvement.

The Need for Evolution and its Signs Today

The increasing relevance of Business Process Management (BPM) as a discipline for organizing enterprise business processes is readily demonstrated by sustained growth in market size and in uptake of integrated BPM tools and platforms (BPM Suites, BPMSs). The trend toward more flexible ways of working, shorter organizational reaction times and fully embracing market and business unpredictability, is a powerful force that, while positioning BPM at center stage, also strains conventional approaches and tools beyond their limits. Terms such as Agile BPM, Dynamic BPM, and even SOA 2.0have been coined to express a new way of managing business processes and services much needed to address current business challenges.

Whitestein proposes a fresh approach that goes beyond current BPM. We name this comprehensive, unifying vision goal-oriented BPM.

White Paper Outline

The next Chapter 2 (p. 3) presents the concept of goal-oriented BPM. First, Section 2.1 (p. 3) illustrates the core idea of business goals and their coherent and full coverage of the whole business process life cycle. Subsequently, Section 2.2 (p. 5) deals with process modeling, Section 2.3 (p. 7) with process execution, and Section 2.4 (p. 10) with process monitoring and optimization.

Chapter 3 (p. 11) compares the approach with the widely known alternatives of flow-oriented BPM and Business Rules, and follows with comments concerning Business and IT architecture.

This white paper discusses goal-oriented BPM from a vendor-neutral viewpoint. To learn how Whitestein Technologies employs these ideas in a complete BPMS product, refer to the Living Systems® Process Suite Web page.

Case Study: Product Change Management

An example drawn from the domain of product change management is used in this document to ground the goal-oriented approach to BPM.

Regardless of the industry sector, any successful product is subject to change throughout its lifetime. Such change needs to be properly designed, assessed, and applied without jeopardizing factors such as product quality, time-to-market, and production cost. Product evolution is thus a dynamic activity by definition.

2. Goal-Oriented BPM
2.1 The Unifying Power of Goals

Every enterprise, from organization to operation, has business goals; they are the focal driver for every strategy, activity, and resource assignment and consumption. While this statement seems simple and straightforward, the consequences of truly embracing a goal-oriented approach to BPM, particularly in the pursuit of end-to-end business agility, can be far-reaching.

A New Landscape: Facets of Convergence

A common theme that pervades many aspects of the current market and architectural trends for enterprise computing, particularly in the BPM arena, is convergence. From a broad perspective, one of the ultimate aims of BPM is to enable efficient and effective cooperation between business and IT stakeholders: the convergence of business and IT factors to inform a globally optimal strategy lies at the very heart of business process management.

Looking closely at the evolution of the BPM Suites market and of the individual competing products, more lines of convergence become visible. The differentiating classification between human-centric BPM, which emphasizes business ownership of process models, workforce collaboration, and process model execution, and integration-centric BPM, which relates to EAI and focuses on service/system collaboration and process model transformation, has become less meaningful in the last two years.

Today, central issues of human-centric BPM are the defining topics of the market arena, and BPM Suites are expected to add value through description, execution, and continuous improvement of an enterprise's business processes. Application and IT integration are the means rather than the end. Even within the human-centric BPM space, the distinction between a strictly model-prescribed production workflow and a more ad-hoc case management working style is becoming increasingly blurred.

Even at the technical architecture level, core Service Oriented Architecture(SOA) concepts are now being enriched by architectural convergence with Event Driven Architecture (EDA) concepts with a particular focus on Complex Event Processing (CEP).

Change is the "New Black"

Cutting through all the above dimensions of convergence there is the widespread and ever more important need to address and master change.

Business and operational environments typically generate a high frequency of events that change how business is conducted: economic fluctuations, political and normative changes, technical and commercial innovations, among others.

Equally, business stakeholders can benefit from the ability to change their processes on demand, quickly, easily, and cheaply.

Mastering change through dynamic and agile BPM yields highly apparent competitive advantages, since rapid and inexpensive process changes result at a minimum in reduced time to market and total cost of ownership.

Why Goals?

To benefit from and thrive on this trend toward multi-faceted convergence, a sound, general concept that can encompass and unify the many aspects of BPM is demanded. In particular, a concept is needed that lends itself well to application within change-aware operational and business environments. Business goals are such a concept, because:

• They are explicit, self-evident statements of what a business must achieve.
• They are relevant at multiple levels of business decision-making.
• They offer stable business objectives, shifting variability and change to the tactical plans and operations used to achieve them.

In day-to-day business operations, it is standard behavior to set business or operational goals, decompose those goals into milestones (sub-goals) and assign plans of activities to each milestone. It should also be routine to track the execution of activity plans to monitor performance, detect problems and take appropriate action.

Goals allow process management responsibility to drive general project planning and tracking, focusing on what is to be achieved before drilling down to consider the details of how to achieve it. The controlling aspect of a business process is therefore captured through goals and sub-goals independently of underlying activities.

Pitfalls of Approaches to Goal-Oriented BPM

To wholly realize the potential of the goal approach, a sound and complete goal-oriented BPM language is required with appropriate tool support. The two major pitfalls in achieving this endeavour are:

• Failing to cover the whole process life cycle with business goals.
• Diluting the goals moving from business requirements to implementation.

Goal-oriented ideas cannot be effective in BPM if used only for process modeling, as this compromises the readiness of a process to change (as with most transformational methods). External factors causing change or internal opportunities promoting change most typically arise when a process is executing, thus goals must also be used to drive process execution ensuring seamless correlation between model and model instances.

A similar argument can be made for process monitoring, control, and optimization. As the next sections show, Whitestein's approach consistently applies business goals to process modeling, execution, and optimization.

The second pitfall is that identifying business goals is relatively straightforward, but a far harder task is to correctly propagate the meaning of goals and their consequences to process activities and running business systems. Enabling critically valuable collaboration between business and IT professionals at the process level can be achieved if business goals are preserved and recognizable in all the end products of an enterprise's BPM program.

Finally, model-driven should not imply simply generation from a model, but rather a persistent connection between model and model instances that supports evolution of both within a framework of assured unification. Standard transformational methods cannot properly achieve model-driven BPM: the only sound approach to delivering goal-oriented, model-driven BPM is direct model, and thus goal, execution.

2.2 Goal-Oriented Process Modeling

Plans and Goals to Express Processes

Using a goal-oriented approach to business process modeling means to separate the statement of what the desired system behavior is, from the possible ways to perform such behavior. More precisely:

• The desired result is described by achievement conditions to be made true and as maintenance invariants whose violation must be avoided: achieve goals and maintain goals, respectively.
• The ways to obtain a desired result are described by plans: modular process graphs decorated with the conditions defining their applicability and the results they obtain when successful.

As a business process is ultimately a structured aggregation of activities, retaining this structure is important as a second step beyond the explicit representation and clear separation of goal and plan levels in a model. Suitable structures must thus be provided for both by supporting the decomposition of goals into sub-goals and plans into activity graphs.

Thus, the steps to perform goal-oriented business process modeling are:

• Express the intentions and requirements of the process through goals and sub-goals, organized as a hierarchy.
• Define plan modules, which will contain activity graphs, stating what they require and what they achieve, grouping together any that may be used to achieve the same goal (albeit in different ways).
• Define the activity graphs contained within plans, describing their aggregation structure.

When represented graphically, a goal-oriented process model will look similar to Fig. 2-1 (p. 5), with elements representing goals and plans, and links representing goal decomposition and goal-plan association.

Goal 'Mining'

A fundamental step in any goal-oriented process modeling methodology is identifying the business goals, particularly higher-level goals, that formulate the process description and later drive its execution.

While the general attributes of a business goal, such as expressing a desired result or capturing something to be achieved, remain the same, there are different means of concretely finding and organizing them.

In activity-centric goal-oriented modeling goals are expressed as the desired completion of certain key activities; an abstract view of what needs to be done that is general enough to allow further specialization through goal decomposition and multiple alternative plans. This is a suitable choice when flow-oriented process models or examples are available.

In object-centric goal-oriented modeling goals are taken from the desired states of relevant business objects. Progress through the process is measured by monitoring these business objects and their state evolution toward their goal states. This approach is well suited to cases where a business domain model is an important asset, perhaps when Business Intelligence analysis is necessary.

In team-centric goal-oriented modeling goals are used to describe the human collaboration patterns through which business processes are actually carried out. According to this approach, each team has its own goal structure with the resulting business process emerging from the loosely coupled collaboration among teams. This option is well suited to the highly collaborative, case management type of business processes.

Benefits of Goal-Oriented Process Modeling

Adopting a goal-oriented modeling approach results in several benefits:

• Business user empowerment. Users can work at the goal level, expressing and refining what is to be achieved by a process.
• Improved process clarity. The goal level describes the purpose of a process in terms of what it is designed to finally achieve (main goal) and the milestones on the path to achieving it (intermediate goals). This yields whole process visibility even across organizational boundaries.
• Encapsulation of tactics. The set of plans attached to a given goal represents a collection of alternative operating tactics. The details of these tactics do not spark dependency chains across involved systems.
• Lowered model maintenance costs. The widespread use of declarative specification reduces the dependence on fine details allowing models that are both more stable and easier to change. Moreover, plans can be reused and combined with ease.

Goal-Oriented BPM in Change Management

Considering a manufacturing industry, an important phase of change management is the assessment of an Engineering Change Request/Order - a document describing a proposed change of the product.

Among the various assessment criteria for a change request, cost assessment is one of the most relevant. Typically, the process requires experts to size and evaluate the cost variation that would be caused by the change.

Such costs can be either estimated or precisely calculated. Both procedures are possibly complex and can have different variants (e.g., how to contact part suppliers to obtain the prices for the new parts, or with which approach to estimate the design costs for some new product features).

In some instances either method of cost assessment may be used arbitrarily. More commonly a preferred method is selected, such as ordering a precise cost calculation while disallowing an estimation. Yet another alternative is to estimate costs ad interim in the full expectation of needing to accurately calculate costs at a later time.

During process modeling, goals will be defined that capture the (desirable) situation where one or the other costs have been made available, such as:

• A have-costs goal: some form of cost figures are available.
• A have-calculated-costs goal: the calculated cost figures are available.
• A have-estimated-costs goal: estimates for the cost figures are available.

Consequences of the Goal-Oriented Approach

Using goal-orientation, the various cases and their context-dependence can first be abstractly generalized by defining goals such as have-costs, have-estimated-costs, and the relationships among them. Then, the temporal dependence between the various procedures becomes a logical dependence among goals.

Goal-plan separation, moreover, then allows reuse and easy replacement of different estimation approaches by simply defining them as alternative plans for the e.g., have-estimated-costs, goal. Some plans to achieve the have-costs goal may try to do so by activating the have-estimated-costs goal, thereby realizing dynamic goal decomposition.

2.3 Goal-Oriented Process Navigation

When a business process is executed, an effective goal-oriented BPM solution is able to directly run the goal-oriented models against the standard IT infrastructure, possibly within an SOA landscape.

Moreover, mastering change means executing complex business processes in the face of a potentially dynamic and unpredictable environment. This requires striking a careful balance between agility and safety.

Agile: Process Navigation and End-to-End In-Flight Model Update

To successfully tackle the challenges of a changing business environment, a goal-oriented execution engine must be able to smoothly adapt a process execution flow to account for new events in real-time.

An important distinction is between a change occurring to an executing process instance and a change to the originating model of that instance.

• An In-Model change is a situation that was foreseen and taken into account in the model.
• An Out-Of-Model change is, on the other hand, the result of an unexpected condition that lies outside what the process model is designed to manage.

In-model changes are managed by defining and maintaining the, potentially many, context-dependent ways a process can succeed using available modeling language artefacts and tools. For goal-oriented BPM, this is primarily achieved through goal-plan separation, since the ability to assign different plans to a single goal brings two major benefits:

• When a goal needs to be achieved, the most suitable plan is chosen.
• If conditions change, a plan can just fail and another plan attempted.

This execution model, where the goals represent the stable milestones to achieve process success, and the plans are opportunistic and context-specific ways to reach these milestones, is called process navigation, in analogy to route planners and car navigation systems.

By definition, there is no way to handle out-of-model changes without somehow modifying the original model. The problem is more complex than just model versioning, as an effective solution to out-of-model process changes must provide at least the following:

• Apply a newer model version to a running process instance.
• Migrate process activities, organizational structures, and live data.
• Concurrently execute instances of different versions of a model.
• Support large model updates batches of specifically selected instances.
• Define instance-specific actions (both pre- and post-migration).

Only comprehensive support for all the above points can be called end-to-end in-flight model update. A BPMS that limits its model update support to model versioning and instance update will appear adequate in simple, demonstration scenarios, but will then fail to deliver smooth migration in a realistic, large-scale production environment.

Safe: Autonomic Computing and BPM

The unprecedented agility enabled by process navigation and end-to-end in-flight model update cannot be traded for process safety and manageability. A BPM Suite (BPMS) for agile business processes must therefore also include a strong set of monitoring and control capabilities. Beyond process inspection tools for human operators, effective safety for agile systems requires self-management, i.e., the BPMS monitors its own operation and handles undesirable situations.

Autonomic Computing is a broad initiative to equip IT infrastructure and increasingly also software with self-management capabilities, pushed forward by IBM and others, including Whitestein Technologies, since 2001. The four defining self-management properties for Autonomic Computing are:

• Self-configuration. The system adapts its operating parameters to mutable external conditions, some even unpredictable at design time.
• Self-healing. The system is able to recover from unfavorable conditions and malfunctions, determining and performing compensation actions.
• Self-optimization. The system continuously assesses its own performance and adopts performance improving alternatives.
• Self-protection. The system detects threats and enacts preventive and corrective measures to ensure continued correct operation.

A key to the Autonomic Computing vision is the presence of feedback control loops in the system. In principle, any system exhibiting self-management can be divided into:

• A base system, providing functionality needed to meet the design goals.
• An autonomic controller, monitoring the base system and the external environment, and deciding and enacting self-management policies.

The original focus of Autonomic Computing was on IT infrastructure, but the basic ideas apply to most systems and even to organizational entities. When the base system is an entire BPM system, the addition of an autonomic controller results in Autonomic Business Process Management.

In autonomic BPM, as pioneered by Whitestein, the system is the ensemble of software, hardware, and human resources, with the norms and policies defining it; It is this system that exhibits self-management qualities. Autonomic actions can be either automated or subject to human supervision.

Benefits of Goal-Oriented Process Navigation

The goal-oriented approach brings several additional benefits when applied to live process execution:

• Clearer and more precise business requirements. Direct goal execution lets business directly control executable behavior. This fosters IT department trust in business modelers.
• Execution transparency. Direct goal execution means run what you model, see the model running, fostering business stakeholder trust in IT.
• Automatic, negligible-effort exception handling. With context-driven process navigation, the system decides the best way to achieve a goal.
• Limitless agility in process evolution. End-to-end in-flight model update allows full scalable (re-)definition of business processes on-the-fly.

Goal-Oriented BPM in Change Management

Another example from the change management domain illustrates a concrete application of goal-oriented BPM at process execution time.

A change request assessment involves several experts from different areas of competence. If one expert fails to respond within an expected time frame, an agile BPM system should explore alternative options, such as:

• Attempting to contact other people with the same area of expertise.
• Seeking an automatic approximation of the expert evaluation.
• Seeking other combinations of expert assessment to cover the required aspects of the change request, omitting the missing expert's domain.

The goal-plan separation of goal-oriented BPM is an ideal enabler of effective support for different strategies and tactics. The defining constraints are expressed at the goal level and allow top-down strategy selection.

For each strategy (i.e., each sub-goal of the main goal) multiple different plans can be provided to pursue the strategy in varying situations.

A goal-oriented approach allows the expression of a wide and diverse set of solutions without an explosion in the complexity of the process definition and execution as found in, for example, BPEL and similar approaches.

2.4 Goal-Oriented Process Monitoring and Optimization

Adopting goal-orientation for both process modeling and execution combines several benefits, but the full circle of business process life cycle is covered only when the goal-oriented abstractions are also used in process monitoring, optimization and control.

Enhanced, Layered Process Visibility

A separate goal level allows tracking of business process evolution independently of operational details. If needed, the structure at the plan level, together with plan attributes such as cost and time, allows the continuous fine-grained assessment of the current state of work.

Goals represent the major milestones of a process instance and have life cycle states such as inactive, running, or achieved. A look at the goal hierarchy of an executing process instance immediately communicates the progress state and the reasons for it.

Goal-Oriented Business Activity Monitoring

Beyond process status tracking, the major objective of real time monitoring is process value assessment and improvement. By defining Key Performance Indicators and measuring them in real time, discovering process optimization opportunities becomes quicker and easier.

Moreover, capturing and directly executing business goals supports defining, monitoring, and processing KPIs not only at the procedure level, but also at the goal level. Business owners can immediately assess performance and locate improvement opportunities on a high-level, structured view of the process, without delving into the details of BPMN contingencies. This fast assessment is the optimal fuel for the strong dynamic BPM focus of end-to-end in-flight model update: applying model changes immediatelyto exactly the running processes that need it, no matter their execution state and data, delivers process improvement ROI at unparalleled speed.

Goal-Oriented BPM in Change Management

Another example from change management is the adoption of fast-trackor lightweight paths to reduce completion time, resource usage, or cost.

Let us suppose that some unforeseen event delays process execution. With goal level KPIs a goal-oriented BPM system can track the expected completion time and proactively determine that some deadline cannot be met.

The system can then do much more than to simply report the problem. Leveraging goal hierarchy it can propose options to the user and justify them:

1. Leave the process as it is and just shift the deadline [standard cost, standard quality, two weeks delay]. Option chosen to minimize change.
2. Run the process with the fast-track path [increased cost, standard quality, one week early]. Option chosen to optimize the 'completion time' KPI.
3. Run the process with the lightweight path [decreased cost, decreased quality, on-time]. Option chosen to optimize the 'total cost' KPI.

The foreseen values of the KPIs and the corrective actions can be defined and described at the goal level (e.g., disabling one or more goals for the fast track case), abstracting from the specific procedures actually followed.

3. Discussion Comparison

The innovative approach to BPM described in Section 2 Goal-Oriented BPM(p. 3) has some unique features that set it apart from other more common BPM styles. Beyond what has been already said, however, it is useful to explicitly compare goal-oriented BPM with other more classical approaches.

Comparing with Model Transformation BPM

The first comparison to make is against traditional workflow engines or newer BPMS products that adopt a model transformation approach:

• Business owners define a graphical business process model.
• The model is automatically transformed into an executable language.
• IT experts complete the model with technical bindings and run it.

The execution language can be actual programming code or more often an orchestration language such as BPEL. This approach is mostly taken by vendors focused on SOA and integration into an EAI environment.

Goal-oriented BPM brings direct goal execution as a doubly effective improvement on this approach:

• The goal level makes process models simpler and easier to change.
• What is executed is exactly what is modeled. No transformations.

As noted in the previous sections, the resulting benefits are superior agilityand stronger collaboration between business and IT professionals.

Comparing with Direct Model Execution BPM

A second relevant category of BPM vendors takes a more business-friendly route and avoids model transformation:

• Business and IT experts define a graphical executable process model.
• IT experts complete the model with technical bindings.
• Both business and IT experts can run the model as it is.

Vendors proposing this approach ask users to model business processes with a flow-oriented language, at times proprietary but mostly BPMN.

Such vendors (or, at least, the best in class) have an execution model bearing some basic similarity to goal-oriented BPM. These could be compared to running a goal-oriented process model with a single goal and a single, large plan that attempts to take care of everything in every situation.

The benefits of complete Goal-oriented BPM (throughout the process model life cycle) arise from having many simple, context-specific flowsrather than a single large one. The goal level coordinates these multiple simple flows through a hierarchy of declarative conditions.

• The goal level keeps policies and strategies separated from procedures.
• The hierarchical organization of workflows better manages complexity.
• Multiple plans per goal offer automatic, zero-effort exception handling.

Comparing with Business Rules driven BPM

Another useful comparison is with respect to Business Rules engines and their use for BPM. A business rules system expresses the constraints and activities of a business process as rules, typically made by three components:

• An Event, specifying a situation that can trigger the rule application.
• A Condition, stating a constraint that must hold when the event occurs, in order for the rule to be applicable.
• An Action, to be triggered by the event and allowed by the condition.

A business rules system is a declarative way of specifying a business process, sharing therefore some benefits with goal-oriented BPM. The latter, however, has two areas of major improvement:

• Structure-awareness: Fully specifying process control flow is too rigid, but doing without any flow information can make a model hard to understand and track during execution. It is hard to predict which rules will fire next and what their impact will be; the process flow ends up being hidden in state variables coupling different rules together (flag-based control flow). With the presence of a goal hierarchy, on the other hand, the conditions are arranged in a structure that makes immediately evident which is the relevant subset (conditions from active goals).
• Time-awareness: An Event/Condition/Action rule reacts to events, but lacks the sequencing of a plan. After its event and condition, a plan in goal-oriented BPM has a structured activity graph the lets the plan unfold in time. The plan-goal connection shows what the plan aims at.

Goal-oriented BPM, combining goal and plan levels, strikes the right balance between the rule-like declarative and the procedural flow-oriented approaches to business process specification.

IT Architecture Considerations

Among the convergence trends outlined in Section 2.1 (p. 3), the case of Service Oriented Architecture and Event Driven Architecture was listed. Considering the needs and goals of BPM, it is clear that both SOA and EDA bring value to a BPM effort and should be combined:

• SOA provides the service landscape of activities that compose processes.
• EDA and complex event processing yield real-time information for agility.

An architecture style and technology that is particularly well positioned for the task is multi-agent systems. This style advocates an approach to software construction that has a few distinctive software engineering traits:

• Activity-centric description: Tasks and activities are first-class objects.
• Pervasive introspection: Major entities in the system have expressive descriptions, available at runtime.
• Autonomic feedback: The architecture fosters emergence of self-management properties through local and global perceive-decide-act loops.

These traits, together with the adoption of common software development best practices not only help to support goal-oriented BPM, but also generally improve software non-functional qualities, such as enhanced modifiability and robustness or increased understandability.

4. Summary

In a modern enterprise, the bar of 'challenges to overcome' rises persistently even as business processes are positioning in a central role as an essential tool to turn enterprise assets and potential into business success.

Observing today's dynamic and unpredictable business world, multiple convergence trends can be spotted. These trends push the limits of more conventional BPM and suggest evolutionary steps that can improve business process management under these circumstances.

Goal-oriented BPM is an approach that leverages the unifying value of business goals across the whole process life cycle: modeling, execution, monitoring, and optimization.

By striking an effective balance between flow-oriented and rule-based, between procedural and declarative ways to describe business processes, goal-oriented BPM increases agility and makes process change and optimization quicker, easier, and safer.

An effective and successful implementation strategy for this BPM evolution has to include both methodological and technological aspects, needs a comprehensive and adequate set of tools, and an infrastructure encompassing a suitable architectural style, such as multi-agent systems.

About Whitestein Technologies

Whitestein Technologies is a pioneer of self-adaptive enterprise software. We create software that dynamically responds to changing conditions so it can optimize your processes and infrastructures in real-time. To stay ahead, we are continuously advancing our innovations in the field of autonomous software agent technology. Whitestein's software products enable better management and optimization of your business processes and help your organization be more efficient and agile.

Whitestein Technologies is a privately held company founded in 1999 and is headquartered in Switzerland, with offices in Germany and Slovakia.

Contact Information

Whitestein Technologies AG

Tödistrasse 23
CH-8002 Zürich
Switzerland
Tel +41 44-256-5000
Fax +41 44-256-5001
For more information, please visit our site at http://www.whitestein.com/ or
send us an e-mail to info@whitestein.com.