Goal Hierarchies

In LSPS, you can create BPMN processes just the way you know them; however, LSPS provides support for GO-BPMN processes, processes with a conservative goal-based extension of BPMN.

Such a process has a goal-based unstructured layer, which allows you to separate what the process should achieve from how it should achieve it:

• what to achieve is defined in goal hierarchies
• how to achieve the required state is defined in plans in BPMN

Let you just dive in and demonstrate the goal-oriented approach on an example.

Defining Your Goals

Let you consider a process for arranging a business trip:

• The main goal or purpose is to have the "Trip arranged".
• The trip is considered arranged after the accommodation, flights, and transport to and from the airport are arranged.

Once the trip is arranged, the purpose of the process has been met: this is the main goal: we identified the main goal, to arrange the trip, and the 3 sub-goals it comprises. In GO-BPMN, the goals are represented explicitly by Achieve Goals elements arranged in the required hierarchy.

In this case, the main goal will be the top Achieve Goal, that is, an Achieve Goal with no incoming "arrows" or decompositions: such goals are started, or triggered, by the process: when the process starts, the top goals start. The represent the ultimate required result.

As already defined above, to achieve the goal we must achieve multiple minor things subordinate to the main goal. The sub-goals are represented again by Achieve Goals. However, these are connected to their main goal and will be triggered all at once by the main goal: The sub-goals are executed in parallel manner.

Let's create the hierarchy.

Defining How to Achieve Your Goals

Since we have defined what we want to achieve, let's get to the how-to-achieve part. This is defined by Plans.

Each goal can be achieved in one or multiple ways: You can book a hotel, tickets, and the airport transportation in different ways, for example, by phone or online.

Generally, it does not matter how we achieve it: Therefore, a goal can have multiple Plans. The inside of a Plan defines how to achieve the task ahead using the standard BPMN flows that perform the action.

Now, decompose the sub-goals into plans. You should end up with a hierarchy similar to the one depicted below.

How to achieve a Plan or a BPMN process is defined by a standard BPMN flow in the Plans or BPMN Processes.

Let's start by defining a dummy flow in one of the Plans.

This flow simply starts the plan execution and immediately finishes: the None Start Event produces a token which passes through the Flow to the Simple End Event, which consumes the token. In your processes, you will want to execute Tasks, split your flow with Gateways, etc.

Example of a Plan body

Making Sure Things are on Track

Some Goals or the entire Process might need to run only under certain conditions, for example, if the business trip gets cancelled, it does not make any sense to continue the execution. You might even need to rollback what was already arranged.

You can deal with conditions in goal hierarchies either using a Maintain Goal or with preconditions and deactivate conditions of Achieve Goals:

• If you want to rollback or compensate some action, use Maintain Goals: these goals define a condition: the moment the condition becomes false, the Maintain Goal triggers one of its Plans.
  
• If you need to check the condition before something happens, use pre-conditions of Achieve Goals.
• If you need to interrupt an Achieve Goal when something happens, define its deactivate condition.
  

Execution

Let you take a look at the execution of a goal hierarchy and its process: note that the goal hierarchy is part of the process.

When you instantiate the model, the following happens:

1. One process instance is created for each process: the context data is created (variables are created and have their initial values assigned).

   Note that only processes that have the flags Executable and Instantiate Automatically are instantiated immediately.

2. All Goals become inactive.
   
3. Top Goals become Ready.
   
4. Top Achieve Goals with their precondition evaluated to true become Running. If there is at least one such Goal, the process instance becomes Running.
   • If the running Goal is decomposed to sub-Goals, the sub-Goals become Ready. These then continue their life cycle (have their precondition checked, etc.). The goal is achieved, when all its sub-Goals become achieved.
     

     Triggered Subgoals
   • If the running Goal is decomposed to Plans, the Plans have their conditions checked and one Plan with the condition true becomes Running: the None Start Event of its body is triggered.
     • If the body ends with an Error End Event, or it receives an error event, the Plan finishes as Failed (note the Plan must define the code of the error in its property Failure error codes) and the Goal triggers another Plan that was not executed yet.
       

       An alternative Plan running after a Plan failure
     • When the body ends with another End Event, the Plan finishes as Achieved.
     • When a Plan finishes as Achieved, its Goal becomes Achieved.
5. Once all Achieve Goals are Failed or Achieved, the process instance becomes Finished.

Summary

Goal-oriented approach to processes makes only sense if there are multiple parallel actions required to meet the goal.

If you want to use the goal-based approach, make sure the business process analysis is performed accordingly: the "extraction" of goals requires a change in the mind set. However, this additional effort can result in more autonomoyou business processes.

When designing such a process, you should proceed as follows:

• Extract the purpose of your process into Goals.
• Identify the possible ways of how to achieve the leaf Goals of your hierarchy.
• Decompose the leaf Goals into Plans and design the Plan bodies.

Pros

• Dynamic flow execution: Some goals might never be triggered or triggered only after an event.
• Process instance restart based on conditions if Plans are well-structured, that is, they are minimalistic.
• Performing multiple process parts synchronously.

If your model does not require any of the above, consider using plain BPMN.

Cons

• Business Process Analysis of goal hierarchies might involve a steeper learning curve than that of BPMN processes.
• Only one Goal hierarchy is instantiated per process instance (no multi-instance Goals).
• Goal hierarchies do not support processing of BPMN events since there are other mechanisms that substitute these.
• Goal hierarchies are not legible if they contain conditions: the semantics are not obvioyou from the diagrams.
• If hierarchies have many Goals with conditions that are checked continuoyouly and contain execution, for example, assignment expressions, they can result in performance issues.

Documentation

• Achieve Goals
• Maintain Goals
• Plans

Proceed to Simple Model.