TomDebevoise.com

The Business Rules Journal, Vol. 10, No. 4 (Apr. 2009), has published my most recent article: ”From Spreadsheets and Computer Code to Business Rules:  A Business Rules Approach to Decision Point Analytics,” URL:  http://www.BRCommunity.com/a2009/b470.html  

The URL requires a  membership (free). I support the work of this group and the conferences they sponsor. If you are not a member and you are interested in Business Rules, please consider joining.

Certainly, combining business process modeling with a business rules approach can create comprehensive, agile solutions that support a business model. Yet, it is not always easy to understand the role of these visual modeling approaches.

Technically, the BPM/Business Rules approach places process logic with the BPM suite and decision logic  in the business rules management system (BRMS). The process logic in a BPM suite sequences and controls activities and launches and cancels processes. Control is achieved with timers and exception handlers. Processes can be designed to recover from errors, restart processes and coordinate activities. The BRMS effectively designs, organizes and executes the logic behind a process decision. An effective BRMS can handle any depth and complexity of decision logic, including computationally complex logic and dense logic.

Clearly, Business Process Modeling Notation (BPMN) and BRMS are important functions for managing a business process. Moreover, processes and decisions can be reused interchangeably.

Assigning the correct problem domain or requirements to Process or Business Decision Logic is not always clear.

Business Process Modeling Notation is the global standard for describing business processes, yet there are no visual standards for business rules. That said, perhaps we can compare Innovations’ Visual Rules notation with analogous shapes in BPMN and discover some of the differences and similarities between modeling business processes and modeling decision logic.

Decisions and Gateways

Probably, the foundation element in Visual Rules is the Decision Shape:

It is used whenever a rule needs to make a distinction between two or more different situations. In general the Decision shape runs down a sequence of choices.  You can also configure the Decision to evaluate multiple conditions. The equivalent shapes in BPMN are the exclusive and inclusive data-based gateways:

The outcome of the two gateways is the same as the Visual Rules decision shape: decide among conditions in the flow of the process or rule flow. In Visual Rules, the branch of a decision can end abruptly with and assignment or ‘action’. It has been graphically designed to be concise. A Visual Rules decision set in a rule flow can span many dozens (or even hundreds) of decisions. The equivalent BPMN diagram would be unwieldy.

The objective of Visual Rules is to model business rules that decide with data, while a process mainly coordinates the activities of participants (departments, users and systems). So Visual Rules has no equivalent for the parallel or complex gateway in BPMN. Part of that process coordination might require the same logic as a decision with data. For instance, process attributes might direct a transaction to accounts payable or elevate an approval based of the size of the transaction. Hence, the overlap. Processes manage the concurrency of activities. The parallel gateway can ‘launch’ activities in parallel (split) and wait or merge the activities when they are done. I have never encountered the need to evaluate business rules decisions in parallel.

Subprocesses and Rule Calls

Now let’s reverse the comparison. In BPMN an important shape is the subprocess:

In Visual Rules the nearest equivalents are the call of a flow rule and the call of a decision table:

In BPMN, a subprocess can be self-contained within a participant lane or it can be a reference. In Visual Rules the call to other Flow Rules and Decision Tables enable reuse of logic in decision-supported business rules. You can organize your logic with the call to decision tables and other flow rules. Sets of decisions can be federated, organized according to a topic or business area, or divided into areas of expertise.

The BPMN subprocess might seem similar, yet it is mostly a way to organize and control activities within a process, and reduce the amount of needed notation. For instance, a process might need to post transactions to three operational systems. Grouping these into a subprocess permits the transaction to be treated and compensated as a single process. The subprocess can be timed-out with a timer event attached to the boundary.

Loops and Loops

Speaking of subprocesses, Visual Rules also supports loops with the shape:

There are three kinds of loops supported in Visual Rules: Looping while a condition exists; for a number of times with a counter; and for records in a list. There are (sort-of) equivalents in BPMN:

Standard Loop:

 and Multi Instance:

Again, as with other BPMN shapes, the similarities between the Visual Rules loops and BPMN loops  are overlapping yet divergent. Visual Rules loops traverse arrays and vectors of records and apply business rules. These loopsare important for developing complex algorithms. BPMN subprocess loops organize process logic. Also, the BPMN multi instance loop can start multiple process threads.

Exceptions and Others

Visual Rules can raise and handle exceptions such as database errors, math errors, general business exceptions and others. The Visual Rules shapes for these are (raise and handle):

In BPMN the exceptions, known as errors, are shown as:

Without delving into the details of BPMN, there are throwing and catching error events. Generally, BPMN exceptions are connected to the boundaries of subprocess.

There are other parallels we can draw. I hope you can see these shapes have overlapping , yet divergent, purposes. In fact, with enough, albeit brute-force effort, there is very little logic that cannot be implemented in either BPMN or Visual Rules. The question is: what is the correct tool for the correct problem area?

BPMN versus Visual Rules: Teams Address the Problem with the Proper Tool

I believe these are the salient features of the different problem domains.

A Business decision is mostly stateless and time-invariant. Visual Rules is adept at documenting and implementing complex decisions with clear, visual documentation. Moreover, business analysts can easily learn how to create and manage these decisions in Visual Rules. Next, Visual Rules is designed to complex logical decision: having thousands of branches, loops and decision tables. The Visual Rules Modeler is designed to permit detailed use-case testing, with data. You can debug and ’step’ through complex decisions.

Process logic is mostly concerned with coordinating and managing time-varying objectives and concomitant exceptions and states. BPM/BPMN is adept at managing process instances. Many BPMN shapes, such as the Timer, Error and Compensation Events have been designed to handle unforeseen process errors. BPMN is designed to model and document an enterprises business process. Most BPM tools can ‘play-back’ a process model for process verification. BPMN documents interactions among participants.

It is difficult to manage computationally complex and logically dense logic with BPMN. BPMN lacks the compact, organizational capabilities of a BRMS. Similarly, the BRMS lacks the process automation abilities in a BPMN engine. Because the objectives are different, it is expedient to separate process logic from and business decision logic.

Technology is Important, Peoples and Organizations are More important

Recently, I asked Sandy Kimsley of Column 2 to provide a reference for a great quote she made about BPM/Business Rules. I thought it went something like this: “The Business Rules folks want the BPM tool to call the rules engine then go away and the BPM folks want to never call the rules engine” or something like that.  When I asked her about this she said “I recall saying that the BPM people would build a huge decision tree in BPM rather than call BR, and the BR people just want the BPMS to have one step, which calls the BRMS.”

More to the point, the groups that manage processes and decision logics are very often different. A business process can cross different systems, department and organizations. Decisions are usually the responsibility of one organization (even if many provide the data).

In the business rules world, we often say that it is easier to change decision logic than it is to change process logic. This is conjecturing rather that stating facts.  Today’s BPMS is as adept at managing change as the BRMS. Another favorite saying of the Business Rules community is that business rules change faster that the process. Again this is more conjecture. Both these opinions miss the central point. The team responsible for business rules is almost always different than the team managing the business process. The objective of today’s BPMS and  BRMS is to end loose, verbal or documented requirements gathering and cede control to the owners of the requirements. One group of Subject Matter Experts (SME) uses BPMN to create processes. Another creates and manages the business rules.  BPMN is a visual tool set that empowers process managers and subject experts. The Visual Rules’  BRMS is a visual tool set that empowers decision modelers and experts.

Answer: when it is a function (Code Sample Included (See Link at End))

Many credit risk (and security) applications use a ’scoring’ approach to modeling risk. For instance in a Basel II Advanced IRB approach, the probability of default can be computed using a weight-adjusted set of objective and subjective factors. For real estate financing, objective factors may for example include the debt service coverage ratio (DSCR) and the loan-to-value. Subjective factors in the set might include the quality and experience of management. These factors are combined in a ’scorecard’ to estimate the probability of default (PD). We often see these scorecards in the form of Excel spread sheets. If you are experienced in business rules, you might assume that a scorecard like this would merely translate into a series of decision tables. The Innovations approach to modeling these is more nuanced.

In our modeling experiences with security, financial or credit risk rating, we use often use decision tables. For instance, we use a decision table to assign the standard BASEL-II risk weight-categories. In the business rules approach, a decision table is a concise way to decide a proposition. Decision tables assign one or more values to parameters based on conditions in the table. Some business rules engines, such as OpenRules or Corticon, drive the majority of their logic from decision tables. I maintain that over-use of decision tables complicates your model. Also, overreliance on the decision tables might result in an incorrect solution.

For instance, a decision table might group a range of numeric values into different groups Consider the FICO  estimates for credit card charge-off from this recent Fair Isaac Publication on page 3*. A range selection decision table might look like:

Yet, unless your application needs crude estimates of the charge-off rate, this approach might not be very good. Another approach would be to develop a ’strait-line’ interpolation of the values.  You can do this by creating an expression in the decision table. A portion of this table might look something like this:

To me, this looks pretty complicated. If you change the FICO scores, you will need a lot of testing to make certain the intervals are properly computed.

Either decision table approach has significant errors. If your application is used by credit or loan underwriters, then one of the simple tables above will suffice. If your application is computing the financial risk for a large portfolio, you will want to avoid the errors inherent in the decision tables. You might consider using a more interpolation accurate method such as Newton’s divided difference. The divided difference approach is basically an extension of the ’strait-line’ interpolation. In strait line interpolation, we use the first derivative (the rise over run) to compute the value. In divided difference we compute the higher derivatives and apply them to the computation. The following graph summarizes the differences:

The simple decision table will yield a single value with a range of errors. The strait line decision table improves the estimated value. The divided difference approach offers the least error for this.

Here are a few sample values as computed by the three approaches: 

 The errors with the decision approach can be very significant, depending on your application’s needs. The divided difference offers more accuracy and simplicity.

In Visual Rules it is a relatively simple matter to build a divided algorithm. You can build dynamically allocated arrays and manipulate them with visual shapes for looping interators and expressions. A fragment of the visual solution is viewable by clicking on the thumbnail below:

Divided differance in Visual Rules

The other choice is to code this into java. There is a pretty good solution here; however, a visual solution to this simple algorithm offers obvious benefits:

• You do not need to declare variables and functional structures, the solution is more direct
• You do not need to know Java or C++ to solve, test and debug your algorithm
• The solution is more compact and it is simpler for others to maintain the visual solutionq

Certainly, decision tables are a simple way to develop and model decisions. Yet, they should be used appropriately. For example, consider the following decision table:

A risk rating evaluation of credit would allocate a portion of the ‘management experience’, a subjective factor to the overall risk. Certainally, most decision tables have more than one parameter; however the decision table is properly used in this contect. 

I have included an export of this visual rules project divideddifferance. (Right click on the link and save the project archive on your hard drive) You will need the most current version (4.4) of Visual Rules. You can download this here. As always, if you need help with this please drop me a line.

*These values were ‘guestimated’ from the FI report and should not be used in any application.

Thanks to Christopher Hansert of Innovations Software Technology, for help with this post!

Banks are required to keep cash reserves in relation to their financial (credit), operational and market risk. Minimum capital is typically specified as a percentage of the risk-weighted assets of the bank. International guidelines state that the minimum amount of this reserve should be around 8% of total risk-weighted assets. These capital requirements were established by the Bank for International Settlements in 1988 (Basel I). It is well known that the collateralized debt obligations (CDO’s) for the sub-prime market and other sub-prime real estate backed securities were given a rating of AAA by the external credit assessment institutions (ECAI’s) such as Standard and Poor’s and Moody’s. A Rating of AAA can usually be translated to one default every 10,000 years.

If you read through these regulations you will find that this translated to a risk assessment of between 0 and 20. These bonds rapidly fell to junk status and a reevaluation of the risk of the loan portfolio jumped from 20% to 150%.

In mid 2008, as sub-prime CDO’s fell into junk status and the ECAI’s finally rated them properly as such, the regulatory cash reserves needed for compliance rapidly accelerated to a crisis point. An evaluation of their positions suggested paper insolvency. Ergo the credit crisis.

So everyone is searching for an explanation. This leads to congressional drama that reminds me of the tobacco executives testifying that nicotine is not addictive or automotive executives flying private jets prior to testifying before congress to bed for multi-billion dollar bail-out.

Moody’s chief executive stated in congressional testimony that “Maintaining our standards may conflict with maintaining market share,” (Clearly the ‘pay-to-play’ that ECAI’s engaged in was a big factor). They “… clearly broke the bond of trust”

Basel II permits banks to use several approaches to determining the cash reserves required in relation to their respective risk. The first, the standardized approach of using a straight percentage for the type of loan portfolio. The second, a foundation approach and the third, the Advanced-Internal Ratings Approach. The A-IRB approach allows for a financial institution to more granularly determine their credit risk, using a variety of factors, but qualitative and quantitative. This could result in the bank to hold more or less capital in relation to their ‘risk’, but would give the banks a clearer picture of their overall risk exposure.

Of course, Banks that make good loans to credit worthy customers are rewarded in that they are required to keep less capital. Unfortunately, for most US Banks, the opposite has been true….

Related links: Discussion of Business Rules and a Credit Risk Rating Platform Here:

(Thanks to David Kim, my boss and mentor for helping me with this!)

On an related note there is an interesting blog post on the BRMS industry consolidation (here):

So, iLog and Haley are being absorbed into IBM and Oracle respectively. My intuition is that each will become a sub-product (under BPM) within their parent companies. Moreover, there are culture wars to fight. I know many of the BPM guys at IBM and Oracle and they do not support the business rules idea or only give it lip service. The BPM guys will rule the nest. In my opinion, there is a very real chance iLog and Halley will die a slow death after these acquisition. IBM/WebSphere will cherry pick iLogs good ideas and Oracle/WebLogic will cherry pick Haley. What has happened to Tibco and Corticon. Also Ilog has a pretty widespread reputation for complexity as does Haley.

It is very exciting time to be a part of Innovation’s software technology. By way of back ground, let me explain. Just three or four years ago there were dozens of business rules management systems (BRMS) in our space.  So, we are the last of (2-3) independent vendors with technology of the highest importance.

The purpose of this posting is to briefly articulate all the reasons it is poor writing to continuously use the split infinitive. Just to be more precise, my real issue is with the infinitive: sort of…

Ok, I am not as funny as Douglas Adams when he said:

. “In those days men were real men, women were real women, small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri. And all dared to brave unknown terrors, to do mighty deeds, to boldly split infinitives that no man had split before - and thus was the Empire forged.”

(more…)

Volker Grossman, the product architect of Innovations Software Technology, gives a good overview of business rules and the Visual Rules approach.

Listen to his youtube presentation here:

If you are new to the Business Rules Approach, take good notes, especially at the begining. His presentation of a vendor’s viewpoint is excellent.

Consolidation in the Business Rules industry is nothing new. Oracle acquired Haley; which was acquired by RuleBurst. SAP acquired Yasu.  IBM acquired ILOG. To me it seems consolidation is a euphemism for what has really happened: the contortion of expert system technology into business rules solutions has run its course. A while back I wrote on the topic of inferencing and business rules approaches. Inferencing is an eclectic topic that is beyond the expertise of most business analysts and subject matter experts. Business requirements are expressed in the form of use-case paths and scenarios, not conjectures of facts or expressions of domain knowledge. The latter is the domain of expert systems; the former is the domain of sequential logic. These companies had to retreat into acquisition because their sales were rapidly declining and their reputation for complicated implementations was growing. The perfect storm arises with today’s harsh economic environment for enterprise software, market conditions and venture capital.

Companies formerly eagerly awaiting to IPO, are now frantically looking for additional strategic investors to help sustain operations and “weather” the storm. This year’s storm is unlike any of the other’s we have seen, including the technology bubble earlier in this decade (see the links below). Many of the CSE’s that underwrote IPO’s are now gone or merged into a bank or have become bank’s themselves. Given the turmoil in the markets, it will be some time before we see new companies listed on the Nasdaq or NYSE. It’s not uncommon for any particular software company to have several VC firms take equity positions during the various growth phases of a company exhibiting strong growth potential. The first VC to fund a start-up takes the most risk, and is usually rewarded with the highest return. They often maintain a controlling interest. The addition of strategic investors along the way, signals the belief by those investors that a company can make it to the utopia known as an IPO. In today’s “perfect storm”, new VC funding will come not to accelerate a company’s IPO, but rather to sustain operations. There have been several recent cases of VC reluctance to provide additional funding in a down market, and therefore forcing the company to accept an acquisition offer.

One company has been scrambling to increase their maintenance revenue in exchange for free upfront licenses for customers using their competitors product. Given that maintenance revenue receives the highest multiple (usually 4x) in the valuation of a company, it’s fairly clear that we expect to see further industry consolidation.

But the storm does not end there. Remember Wolfgang Peterson’s great film “The Perfect Storm”? The perfect storm formed with the confluence of three hurricanes. Business Rules Technology companies caught in the downdraft of consolidation will suffer talent loss before, during and after the acquisition. Despite the acquiring company’s public positions, research and development money is allocated according to the revenue of the business unit. Everyone expects that the development team will be considerably cut back after acquisition. The entire operation will be ‘right-sized’ to the maintenance and (paltry) sales revenue.

On a related note you can read about the rapid downturn in VC funding in these links:

Dan Gallagher, MarketWatch, writes about VC firms changing their exit strategy:
http://www.marketwatch.com/news/story/venture-capital-firms-see-exit/story.aspx?guid=%7BEB136E14-091F-4CA4-9D67-5F95EE09458C%7D
Marc Herson writes about 36 IPO’s drying up:

http://www.riverture.com/my_weblog/2008/12/venture-funded-ipos-continue-to-dry-up-36-vc-ipos-hit.html

As I mentioned in previous blog entries, a dynamic application is an application where ‘change is part of the processes’. That is: the data, business rules, user workflow changes as the processes proceed.

A Credit Risk Rating process is a perfect example of a dynamic application. For instance:

• Credit Risk Managers observe loan defaults and related events and outcomes.
• They link results to the economic conditions, and decide new subjective and quantitative factors.
• They adjust or change the credit risk model thereby changing user-interfaces, scores and computations, change the work flow.

An effective credit risk solution should perform these changes- without code. Governed, continuous change is the key characteristic of the entire solution in a dynamic application environment. John Rhymer of Forrester research characterizes these applications as ‘designed for people and built for change’. By ‘built for people’, we mean the tools are simple to use, yet adequately robust to connect the process changes with the operating environment. By ‘built for change’ we mean tools that simply distribute and deploy the changes.

For instance, as shown in the figure below, business rules should create screens for the credit analysts.

 A dynamic Application Framework should deploy the user interface to the correct environment.

Clearly it is inefficient to create a credit risk solution according to the preindustrial pattern of “”plan – build – deliver“. In this traditional approach, a credit rating department creates a new credit scoring requirements review, which is then handed off to the IT department to fulfill. The correct solution must incorporate the credit managers into the application delivery process. This obviates the need for time-consuming fine-tuning by operating departments and programming experts that characterizes the traditional application development process.

My fellow co-author on the OCEB Certification Exam has written a great post:

http://www.arisblog.com/2008/10/20/bpm-certification-program-available-soon/