The Three Metaphors of Business Process Modeling

Event Based Architectures and Complex Event Processing (CEP) are an increasingly prominent part of today's advanced enterprise architectures. The event-driven process is one of the  seven important process usage patterns. Organizations use the pattern to interact and respond to a growing volume of business events and transactions on a daily basis. To create an effective event-driven process, you will need a new kind of analysis.

Event analysis is an emerging area of business process modeling that develops support for the decision-based processing of enterprise-significant events. It is also increasingly an essential part of strategies for the evolving Internet of things and crucial aspects of modern architectures in High-Consequence Systems Architectures, including C2 applications such as situational awareness.

Chandy and Schulte define "A business event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities." The event we refer to here is not the various BPMN events of the circular kind. We are referring to events that occur outside the walls of the organization. An event is Boolean in nature; it either happened (True) or not at all (False). The event is meaningful because it might affect a business process. It provides an external message or a channel that several processes must consume, activate and respond.

Do not confuse the business event with complex event processing (CEP). CEP is an approach to deselecting events that reveal the event with a SQL-like language.

Consequently, we have a new metaphor that is indispensable in business process modeling: the business event. The table below lists the key distinctions between the three business metaphors.

Business Event	Business Process	Business Decision
Unpredictable, random in nature	Stateful in Nature	Stateless In Nature
Is monitored by participants and sorted by rules	Sequence of activities conduction by participants	Logic, computations and business data, create actions and outcomes.
Based on observation	Sequence of activities and monitoring and control for participants	Actions, direction, control for events and processes
Improvements in observations improve risk management, agility and understanding	Improvements in process metrics	More consistent policies, tighter control of business strategies (BMM)
Representation is evolving	Visual BPMN	Visual Logic

Unpacking Decision Management: A Changing Landscape

There is an excellent recent review of knowledge management as written by Fahmi Ibrahim (here). I was struck by the parallels between KM and business rules, so I 'borrowed' his conclusions and mapped them to my understanding of the business rules industry.

Criticisms	Key Points
Poor Conceptual Understanding	The vast majority of the business rules literature (1)(2)(3)(4) and products are built on the assumption that business rules should be expressed as a linguistic, symbolic or interpreted evaluation of facts. However, the characteristics of this approach make it difficult to create, control and manage changes (5)(6). The alternate approach views business rules as a set of sequential sequence of logic that categorize, compares, computes and controls a business decision or direction. Many organizations have successfully implemented both approaches.
Lack of Common Framework	In reviewing the literature and standards, business rules and the business rules approach lacks a common framework and there is no consensus of a working definition of either. Commercial software focuses on IT infrastructure. In the OMG standard there is the semantic business rules vocabulary (SBRV). SVBR has very little to do with the needs of IT operations. Consequently, the business rules are misunderstood and underutilized, especially in rules intensive-areas such as health care, logistics, risk management and finance,
“Rebottled Old Wine‟	Many products employed expert systems that were developed over 3-decades ago to solve unrelated AI problems. Other approaches evolved from the limitations of the relational data bases (7)(8). The result is that the definition of business rules and business decisions is too narrow and will not encompass the evolving event driven infrastructures of tomorrow.
Bandwagon Effect	In the last 10 years, many companies jumped onto the rules bandwagon without understanding the meaning and implications of expert systems, fact-based modeling, or vocabulary approaches. In fact, many companies became bogged down in analysis paralysis and endless ‘death by meeting’.
Success or Failure	The business rules approach has delivered significant results but the success rate is mixed. There are many examples of organizations which have successfully implemented BRA. Yet anecdotally, we encounter initiatives will fail to have significant results. Like knowledge management, some have declared that BRA is a fad without real business benefits.
Value and Measurement	While business rules are widely recognized as a valuable metaphor for controlling business results there is little understanding of how to manage these.

I think business rules should support an expanded view of business rules in the enterprise-one that encompasses and moves beyond supporting a process decision (or endless meetings that might make that someday). New metaphors, especially events, are on the horizon. As with every method, the complexity of the situation will significantly expand. To survive, the business rules approaches should reduce complexity and increase transparency with today's model-driven approaches.

Business Process Management, Remember the Basics

As Sandy Kimsley pointed out in her links, Ken Swensen responded to the question, is BPM Dead? In all of our discussions of technology, business processes, business rules, business events, it is easy to lose focus on the basic worth of business process management.

Therefore, it is useful to review the differences between function- and process-orientation within organizations. Most organizations, that use BPM, intend to become process-centric. Organizations with a robust process focus are distinguished by having a extensive, cultural process orientation. Big, complex organizations consider the process focus as extremely important, and this system is particularly common in insurance, healthcare, and financial services. A functional organization orientation, on the other hand, is more prevalent in small enterprises and is well-suited to the way they handle business.

A functional organization is an organization that delivers a strong capability in a limited number of functions. These might include highly specialized product and skills where knowledge or availability is limited. Obviously, a functional focus works for them.

Each focus,functional versus process-centric has advantages and disadvantages. In his admirable work on business process management, James Chang created the table below that summarizes the differences between organizations adopting each focus. A functional organization allows an easier balance of work among workers with functional excellence because they all have similar skills. This organizational style outlines natural, comprehensible ways that each task should be performed and assigns this to the appropriate proponent.

	Functional Organization	Process Organization
Work Unit:	Department	Team
Key Figure:	Functional Executive	Process Owner
Benefits:	Functional excellence, Easier work balancing because workers have similar skills, Clear management direction on how work should be performed	Responsive to market requirements, Improved communication and collaboration between different  functional tasks, Performance measurements aligned with process goals
Weaknesses:	Barrier to communication between different functions, Poor handover between functions that affects customer service, Lack of end-to-end focus to optimize organizational performance	Duplication of functional expertise, Inconsistency of functional performance between processes, Increased operational complexity
Strategic Value:	Supports cost leadership strategy	Supports differentiation strategy
Work Management:	Functional Quality Focus	Cross Functional Coordination

Table 1 Benefits and Drawbacks of the Functional Versus Process orientation in organizations (Business Process Management Systems, Chang).

Conversely, a process organization enjoys improved communication and collaboration and may therefore be highly responsive to market requirements. Further, performance is easily measured across the process organization, as it is stated in terms of process goals. However, process organizations suffer from lack of or poorer quality communication between the different functions relative to their functional counterparts. There is reduced end-to-end focus, as opposed to the functional structure. Moreover, there may be considerable duplication of functional expertise, inconsistent functional performance between processes, and increased operational complexity. This may make the structure of the process-based organization redundant and bulky.

- Tom Debevoise

BPMN in Visio 2010

I have been looking at Microsoft Visio 2010 and I would recommend it to anyone seeking a simple process modeling requirements tool. Ultimately, when your 'requirements' phase in process modeling is complete, the business analysts must move away from Visio and into the business process management suite.

There are many, many users of Visio who are 'process focused'. Moreover, there has been a significant investment in process modeling using Visio. When teams, who have not used an execution-oriented framework such as PMF, move these models into execution there will be issues. Visio 2010 Premium will help a bit by doing a very competent job at supporting early (learning and requirements) efforts in process modeling. The 'check diagram' function checks the proper syntax of the BPMN shapes. For instance in the diagram below, there are two errors: a message is flowing the wrong way and there is a 'hanging' activity.

Wrong

After you correct the issues the errors disappear.



Casewise, Orbis and others provide Visio 'bridges'.  Yet, all these will change when other vendors will seek to capitalize on Visio 2010's new BPMN features. This tool also supports moving process onto SharePoint 2010. Overall, I commend the Microsoft Visio BPMN team for their efforts.

Business Rules and Business Process Modeling Simplified

In BPMN 2.0 there is a shape for business rules:



 This shape denotes the place within the process model which calls business rules and obtains decision output.  The question is, how do you use it?

The difference between process and rules is simple; processes are stateful and rules are stateless. In BPMN a process has an explicit or implicit single start and one or more stops. In business rules there is no start or stop. It is an expression of a sequence of logical conditions.

Consider the figure below:



Simple Process with exclusive gateway, the process corresponds to the process: Start: When A Condition: Start Activity A When B Condition: start activity B, When either complete: Stop

This simple process uses the exclusive gateway to choose which activity to run. The activity, A or B, will run for an indeterminate time. When it is done the end is reached. A simple flow rule from Visual Rules is shown in Figure 2.  A flow rule is a graphical representation of a path of logic. There is no time element to the evaluation; either condition A or Condition B will be the outcome of the evaluation of the conditions in the two gateways-there is no time element to consider.





Figure 2: Simple decision graph with two exclusive outcomes, the diagram corresponds to the logic IF A condition Then A Outcome else If B Condition then B Outcome.

The two figures compare and contrast the similarities of BPMN and business rules. Both evaluate the logic conditions to decide which process activity or outcome to choose. The contrast is in the time element. This is what we mean when we stay the process is stateful and the decision graph is stateless.

If we connect the flow rule with the process then the process model looks like this:



This is simple, but most process decision are more complicated than that. I discuss process decisions in a white paper located here: