Both disciplines, Business Rules Management as well as Business Process Management (BPM), have been around for quite some years. In fact, the term ‘business rule’ was first published as early as 1984. This is why it is surprising that only during the last couple of years the subject of Business Rules Management got the attention of a wider audience. And only recently there is increasing emphasis on the combination of processes and rules. But what is the difference between business rules and business processes?

Business Rules

In early 2008 the Object Management Group (OMG) published the ‘Semantics of Business Vocabulary and Business Rules’ (SBVR) as a formal specification. The definition of a Business Rule given here follows common-sense:

Business Rule: a rule that is under business jurisdiction

“‘Under business jurisdiction’ is taken to mean that a business (or any other semantic community) can, as sees fit, enact, revise, and discontinue the business rules that govern and guide it. If a rule is not under business jurisdiction in that sense, then it is not a business rule. For example, the ‘law’ of gravity is obviously not a business rule. Neither are the ‘rules’ of mathematics.” It is characteristic for a Business Rule that it always removes a degree of freedom

Many people tend to think that Business Rules is just another trend or hype but in fact Business Rules are neither new nor old. The only difference is that they weren’t treated as a resource of their own before. Many Business Rules are hidden in source code (e.g. within legacy systems), workflow descriptions, decision tables or tacit knowledge buried in people’s heads. The Business Rules approach however is relatively new and wasn’t driven by technology but business practice which is pretty unique

So why would or should you care about Business Rules? A simple exercise is trying to explain your favourite game without using rules. Difficult? So why is it that we don’t have rules for the “business game”?

Taking Business Rules into consideration has multiple benefits. For one, you can develop remarkably stable processes if you separate the rules (Roger Burlton), because the really rapid change is in the rules, not the business process. Another advantage is the simplification of the process modelling. Instead of having quite a few branches coming out of decision points it is often possible to reduce them to just a couple. In fact, over 50% reduction of process steps and decisions/gateways can often be achieved. Looking at the insurance claim process, for example, many decisions have to be made in order to determine if a payment to the claimant will be made. Explicitly modelling all those decisions will not only ‘overload’ the process map but also reduce the flexibility in terms of changing the underlying Business Capturing the Business Rules separately will enable agility and result in a much simpler business process model.

Business Processes

A business process is a collection of procedural linked tasks which cumulate in the delivery of a service, solution or product to a stakeholder. The Business Process Manifesto establishes that: “Business Proccess clearly describe the work performed by all resources involved in creating outcomes of value for its customers and other stakeholders.”

But there should be a clear separation between the rules and the processes. The Business Rules Manifesto stresses that rule independence is key. “Rules are not process and not procedure. They should not be contained in either of these. Rules apply across processes and procedures.”

The individual way going forward is dependent on the current maturity level of your organisation. If you are just taking the first steps in the Business Rules space then the approach is different to a situation where lots of Business Rules are already documented in a systematic and standardised way. Many software systems are available and the major BPM vendors have integrated Business Rules modules into their applications suites. Getting the theory and the basics right is however also in this case worthwhile before bringing tool support into focus.