Navigation
  • The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling

Entries in Business Rules (20)

Thursday
Mar182010

Business Rules Requirements in the Real World

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 misconception about requirements and business rules.

I agree that it is necessary to know when your requirement is supporting a business decision through rules. To approach this issue, we need to meet the eternal question: what problem are we trying to solve? As messy as the requirements page in Wikipedia is, the meaning 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 usually useless 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 organize 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 indication 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 show too many business rules, or business rules that should be in a BRMS, then they will become unnecessarily complicated.

Sunday
Mar142010

The Expert Systems Debate in Business Rules

In a March 12 post, Paul Vincent commented on the ongoing debate about the use of of Expert Systems to implement business rules. I blogged on this topic in a previous posting .Expert Systems (ES) can solve individual problems extremely well. Examples include the diagnostics of conditions with different, overlapping signs and symptoms. The ES is also proficient at finding a solution when uncertainty (salience) is involved.

I think this argument is more beneficial than the tiresome arguments about RETE versus Sequential. This is because the form and content of your business rules is affected by the underlying technology. With ES, a symbolic or 'domain-specific-language' approach is required. Sequential approaches such as Visual Rules only need visual metaphors (Decision Tables or Rule Flows) to solve the problems. Dave McCoy echoed my point here.

My opinion is that, for most business logic problem domains, the aftermath of expert systems based on business rules systems has fostered a extremely complicated implementation methodology.

If you are contemplating a business rules approach to improve your operational performance, then you should consider the tradeoffs involved. Certainly, if you are unfamiliar with these technologies, you should mandate a proof of concept that involves your domain experts.

Tuesday
Apr072009

Article Featured in Business Rules Journal

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.

Saturday
Aug162008

YouTube Short on Business Rules and BPMN

I have created a short video on the role of Business Rules and Business Process Management.

The video is linked to the graphic below:

You can also view the youTube video here.


Enjoy:

Thursday
Mar062008

Introducing the Process Modeling Foundation



Introducting the process modeling foundation (PMF).

A by result of years of working with BPMN process modeling, we have created the PMF as an outline for methods that progressively adapt to project needs. The PMF directs process model construction from the earliest strategy phase to the goal: execution. In short, there are no wasted efforts.

Modeling Maturity

In process modeling, your organization likely seeks improved performance and alignment or reengineered processes. More often, it is the decisions that need improvement. There are 5 layers of a BPMN process modeling framework (PMF). In the first layer, core processes activities and flows are modeled. In the next, key decisions are identified. Understanding arises with increasing and detailed process modeling. We encourage you to start process modeling by defining core business processes.

In your joint application design sessions (JAD), firms often do 'happy days' use case scenarios, business modeling or creating workflow diagrams in Visio, or combinations of all of these. These use cases (and business cases) haphazardly discover more (or less) information than defined in the PMF. Often, a use-case approach models too-many details of the processes. This is: from the core level through work flow scenario. This approach is often too ambitious and leads to erratic and unpredictable results. Processes steps are confused with business rules. There is a tendency to cling to old, batch oriented patterns. JAD Participants get bored and frustrated.

A 'happy-day path' only considers flows that occur when the process manages no exceptions. You can use this approach by focusing on activities, gateways and flows. So, someday your team should visit 'unhappy' branches. Converting the use case or work-flow into the formal needs of a business process model in BPMN can be difficult.

As your organizations become more sophisticated in BPM, you will create process models directly in business process modeling notation (BPMN). Beyond the core business process, these JAD sessions are mostly working on process and scenario modeling in the PMF. As your experience grows, your organization will probably split the use case scenario into these levels.

Business analysts should become process analysts that build executable processes with BPMN in the process modeling framework. Until then, you need an method to transform the use case or Visio diagrams into an accurate BPMN model of these workflows. You might convert existing use-cases into BPM. Also, you might move the organization into a BPMN modeling tool.

If digitizing a process is your goal, then moving a use case into a BPMN business process model prepares the way for model execution, moving a use case through the layers of the PMF.

Page 1 ... 1 2 3 4