As organizations mature in their use of Business Process Management (BPM), they will realize the need to more directly and automatically align process outcome with business strategy by relating business goals and objectives to process behavior and outcomes. However, strides towards finding a suitable and practical solution unveils the limitations of current process modeling practice.

With BPMN as a typical example, the majority of today's business process modeling languages combine a procedural way of specifying the order of activities and an event-based model. All possible courses of action must be defined at design time, which, on the other hand, poses the risk of over-specification. There might be courses of action that are never needed. In addition, as a general rule, the lower the level of abstraction and the higher the degree of complexity of a process, the bigger the chance that one ends up realizing that it is not reasonable to model a business process in detail¹.

In contrast, goal-oriented processes are termed declarative in that they explicitly consider the concerns that govern a business process. At design time, the overall process goal is broken down into a hierarchy of sub-goals, each of which encapsulates one or more rule-driven procedural processes. Although, in reality, goal-oriented processes are both declarative and procedural, they are fundamentally different from purely procedural processes. An execution plan is created at run-time. During the initial stage of goal-oriented process modeling, processes are typically under-specified. However, processes can be modified and extended even at run-time.

According to general systems theory, “organizations are complex dynamic goal-oriented processes, with outcomes dependent both on the contextual situation as on the coordinated and purposeful action of different entities in the environment”.² All of these processes work together in a coordinated way to achieve defined goals and objectives.

In more concrete terms, organizations are able to adapt to rapidly changing contextual situations only in so far as possible actions are already built into business processes. As a result, greater process flexibility is an imperative requirement. The shift from inherently static processes (i.e. procedural processes exhibiting static process flow) to dynamic processes that can evolve during execution would meet this requirement.

There are basically two approaches to realizing dynamic processes: Dynamic Case Management and Goal-oriented Process Management. The latter approach rests on the premise that goals/objectives can be represented in a tree structure with one top-level goal and a number of sub-goals. A sub-goal represents a milestone, a familiar concept in project planning. For time planning, a goal hierarchy can be presented as a Gantt chart, given that each milestone has been assigned a date.

Breaking down business processes into sub-goals (milestone goals) means defining building blocks (i.e. compositions). Each building block implements a course of action (process) that achieves the sub-goal result.

A milestone goal only starts once the previous milestone has completed. If a problem is detected during execution that jeopardizes the timely completion of a sub-goal, the process can be dynamically modified without user intervention by evaluating alternative execution paths. The executing process can be wound back to the last successfully completed milestone goal, which also serves as a synchronization point. After possibly undoing previously executed process steps, the execution engine follows a different path.

Clearly, run-time agility is supported by executing different plans for the same milestone goal, depending on the actual situation. Process descriptions are open to future modifications. Business analysts and business users can add additional processes representing plans for alternative courses of action without changing any of the existing process definitions. This approach, natural to humans, makes incremental process development a reality. In other terms, loosely coupled process modeling has arrived.

In addition, process monitoring at the milestone goal level is really meaningful, since performance metrics and KPIs are directly related to goals. Monitoring at the process step level may often prove less valuable, since late completion of a process step may not put the timely completion of the process goal in jeopardy.

When it comes to executing a goal-driven process, the ICEE generates an execution plan on the fly. A similar yet simpler concept can be found with Relational Database Management Systems (RDBMS). A software component termed 'query optimizer' attempts to determine the most efficient way to execute an SQL query. It interprets a query, creates multiple execution plans, assesses them and selects the most efficient one based on certain criteria. The query optimizer works “under the hood”, meaning that ordinary business users are not even aware of its existence.

In a similar fashion, the ICEE would generate an execution plan for a business process, starting out with the top-level business goal/objective. Like a query optimizer, it would generate alternate plans representing alternate ways to achieve a business goal. It would consider milestone goals (sub-goals) and business rules (which represent formal expressions of business concerns).

In stark contrast to traditional BPMS, goals direct process execution, and processes are goal-driven by rules, which are derived from business policies and express them. Thus, processes are capable of dynamically changing behavior as business rules change. As a result, process execution becomes highly dynamic.