TomDebevoise.com

Dr.  Ketabchi, from Savvion, believes there are seven process usage patterns. These are:

1. Human Centric
2. Document Centric
3. System Centric
4. Decision Centric
5. Case Management
6. Project Centric
7. Event Centric

There is an eighth one, the ’shadowing’ process. This is a process for monitoring ‘legacy’ processes. Dr. Ketabchi A description of each of these processes can be found in this BPM Institute recorded webinar.

As the BPM Industry matures, these patterns will emerge. We know from design patterns, that best practices can emerge from the wisdom of expereince.

I believe there are some distinct business rules usage patterns. I list these here:

Event Based Architectures and Complex Event Processing (CEP) is an increasingly important 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 form 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 important part of strategies for the evolving internet of things and important aspects of advanced 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 as an external message or channel that one or more processes must consume, activate and respond.

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

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

  Two important aspects of the EVA are components that detect and respond. At Innovations, we have been working with the business event in a numbers of products and engagements. We utilize business rules on the response side in a numbers of ways.   

There is an excellent recent summary 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.

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

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 meaning of business process management.

So, 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 strong process focus are distinguished by having a pervasive, cultural process orientation. Big, complex organizations consider the process focus as very important, and this structure is very 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 operate business.

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

Each of these focuses-functional versus process-centricity-has its advantages and disadvantages. In his commendable 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 simple, comprehensible ways that each task should be performed and assigns this to the appropriate proponent.

 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 thus be extremely 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

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.

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:

Innovations Software Technology has released my most recent white here.  In this document, I review the early beginning of the Business Rules Approach (BRA), discuss the current practices, and conclude with some predictions.

The BRA has principally evolved from three sources: Artificial Intelligence (Expert Systems and others), Data Modeling, and Business Process Reengineering. Circuitously, expert systems became one of the originating technologies for business rules. In the white paper I explain the differences between the sequential logic approach and the inferencing approach adapted from expert systems.  I have experience with both and clearly my bias is towards sequential, graphical approaches. 

Before I worked for Visual Rules, I led the development of an open source business rules engine, OpenLexicon. OpenLexicon used a sequential approach; however, rules were developed with a language template. My understanding of the sequential approach also includes the lessons learned here.

Certainly, business rules and decisions are critical aspects of enterprise architecture. Yet they are aspect of a larger approach. Business rules have already expanded beyond the outdated paradigm of a process-decider. To remain viable the business rules approach will need to support an expanded vision within the enterprise-one that encompasses and moves beyond supporting a process decision.

Again, the paper is available here.

OMG has a number of standards related to Business Rules including the very complex, Semantics of Business Vocabulary and Rules (SBVR) and the Business Motivation Model (BMM). The one that will impact business rules vendors such as Innovations most directly is the Production Rule Representation. It stands at version 1.0 with version 1.1 coming out shortly. It can therefore be used for interchange of business rules amongst rule modeling tools (and other tools that support rule modeling as a function of some other task).

Paul Vincent is leading a committee that is developing a graphical notation for this standard. He discusses this in this recent post here .

In a recent blog post on the requirement network group, Chris Kosba posed a question concerning the role of ‘business rules’ in requirements gathering activities. Again, this raises a common misunderstanding about requirements and business rules.

I agree that it is important to understand when your requirement is supporting a business decision through rules. But to resolve this issue, we need to answer the perennial question: what problem are we trying to solve? As messy as the requirements page in Wikipedia is, the definition is pretty concise -a requirement is a singular documented need of what a particular product or service should be or perform.

If our requirement is that we should support the business rules, as defined by the business operations, (i.e. credit risk rating) then it is often pointless to document these business rules in requirements elicitation. The business rules are the data that drive the system. Documenting these rules would be equivalent to defining an employee database then defining the instances of employees in the tables. We know our employee table needs columns of first name, last name and middle initial.  This is a requirement. Is it a requirement that the table hold the records “John A. Smith, Bob H. Jones, and Sally L. Quill”?

If your system requires that business rules be supported by BRMS then, business rules should be visually expressed as truth tables or logic trees.  The truth table is a two-dimensional expression of conditions and conclusions. In Visual Rules, we call the logic tree a rule flow. In the real world, we often run into application requirements that are stored in spread sheets with logic that flows from worksheet to worksheet. Often, there are many tabs with dozens, if not hundreds, of lines of logic. We especially see this in score cards for probability of default (PD) models. These spread sheets can be converted into a visual model with the Visual Rules approach.

If the requirements documents reflect too many business rules, or business rules that should be in a BRMS, then they will become unnecessarily complicated.