Do you know the rules for Business Rules?

This installment in the Building BA Maturity series, picks up where the last one on Business Process left off.  This month, it’s all about Business Rules.  And as many of us know, in the domain of requirements gathering and definition, “Rules” truly rule.  Or, so says many a thinker in the area now commonly referred to as ‘decision management’.

For this article, I interview two thought leaders in the decision management industry.  But before I go there, let’s clarify what we’re talking about here.  Business Rules Management Systems or BRMSs, are tools for business people to capture the important rules that govern their business, and at the same time, they are tools that software developers rely on, because a BRMS can encapsulate an enterprise’s business rules in a very formalized way, allowing the developer to avoid hard-wiring business logic into their code.  (In fact, that’s probably the prima facie reason why BRMS’s gained prominence)  The developers just write code that “talks to” the BRMS when business logic needs to be inserted in a particular part of a program.

To put it in concrete terms, imagine a large business.  They have 1000’s of business rules governing all kinds of business decisions and millions of lines of code written and deployed to serve the enterprise’s operational needs.  If you didn’t have a BRMS of some kind, and you scanned through those millions of lines of java or .net code, you would see business rules like “IF category > 10 then status = sell” and other decision statements embedded there.  That’s not good.  Because, when the business rules change, which they do very often, it’s a major headache to rummage through those millions of lines of code, looking for every instance that someone hard coded that logic into their programs.  BRMSs solve that problem in a big way.  This is why they are so valuable in large, complex and dynamic organizations, which is where BAs often find themselves!

Bottom line is this my friends.  I believe that BAs who are comfortable with the modern language of decision capture, and perhaps adept at using one or two toolsets for capturing them, have a competitive edge in their requirements process, and also a key differentiator from other BAs who are still living going about things in, let’s say,  a less formalized or structured way.

So let’s start with the thinkers.  May I introduce to you… one of the key thought leaders in decision management, and a very in-demand presenter on said topic.  (In fact, he will be presenting at the upcoming Building Business Capability conference later this year in Fort Lauderdale).  Welcome to the series, James Taylor.

James Taylor, Decision Management Solutions

Q:  What’s the history of this field?   What were some of the milestones that got us to where we are today, with rich capabilities for rule definition and collection, multiple  methodologies and many competing platforms and vendors for decision management?

A: The roots go back decades to work on Artificial Intelligence (AI) and expert systems.  They really took off commercially as applicable tools in the banking and insurance sectors in the past 15 years or so.  The initial business drivers were:

  1. Regulations;  i.e, highly regulated business environments like consumer banking and insurance with many business policy and procedure encumbrances.
  2. High-Risk Environments; e.g., where the cost of a bad decision is very high – extending credit to risky consumers.

Parallel to the onboarding of decision management into banking and insurance, the thinking about rules and decisions matured, with folks like Ron Ross and Gladys Lamm, who began to look beyond the technology, or ahead of it actually, and focused on the requirements themselves.  Their insight was that requirements gathering and rule capture were so related that a strong methodology for capturing, defining, expressing that business logic, would constitute, if done systematically, a clear and complete set of requirements.  That view has been over-simplified into the “requirements-are-rules” maxim, which Ron Ross is working to debunk even today.

Today, decision management has spread its wings and is taking in other parts of the enterprise – notably marketing and customer service.

Q: Who has embraced decision management and who have been the forces pushing back against it?

A: Truth is, not everyone has embraced decision management as a discipline with its rightful place in the SDLC.  There’s been push back from both the business and IT sides.  Developers can be wary of systems that purport to “generate code” which modern decision systems do.  In fact, it’s one of the reasons they’re so powerful.  (more about that below with a look at one such system from Corticon.)   Business has not always embraced the paradigm either.  “What, you mean, you want us to manage all these rules and all this complexity?  Bleh!”  Business all of a sudden was being held accountable for writing decision tables and rule logic, and some of those folks were quite happy not to do that, and to throw all that gnarly rule stuff over to the IT side of the fence.

Q: Isn’t this why a Business Analyst is still a valuable asset, and perhaps even more so as these systems gain more and more of a foothold?

A:  Yes, absolutely.  A clear thinking analyst sitting squarely on the business side of the house, is the ideal person to be the keeper and protector of the rules and business logic domains.

James brought that last point home in a more succinct and pointed way:

“Business Analysts have not caught up to the implications of the new paradigm.  Rather than thinking first about processes happening in the business, then from there identifying key decisions getting made, and in turn, what rules are embedded in those decisions… they’ve clung to their old approaches of long templated BRDs and lots of Use Cases and user stories.”

Q: Them are fightin words James!  We love our Use Cases.  We live and die by them.

A: Nothing wrong with them, and in fact, they’re great tools for identifying key decisions which are embedded in Use Case steps with words like ‘validate’, ‘calculate’, ‘determine’, ‘select’ and ‘choose’.  So, used as a tool for uncovering business logic or decisions, works very well.

Q: Speaking of pictures, can you provide us a diagram of what you mean when you say a “decision management system”, or sometimes called in the industry a BRMS?

A: Yes, we use this when educating companies on where decision management sits in the organizational space. A BRMS, to be worth its salt, needs these basic components (click image for more detail):

Q: You place a clear distinction between a “rule” and a “decision”.  To layman’s ears, this sounds like semantics, but what’s the important difference here?

A: Rules, when considered singly (a rule like “red shirts get marked up 10%”) are not all that useful.  They get really useful when grouped into a coherent set of related rules, what we call a “rule set”.  (i.e., “red shirts up 10%”,  “t-shirts down 5%”, “items with shelf life of 6 months, down 50%”, etc.).  These rules all relate to pricing apparel.  This rule set could be modeled in a decision tree or table.  They often are done that way.  A decision is a higher-order entity. It sits a level above rules and rule sets.  A decision, and by extension, the implemented version of that logic known as a decision service is the business’ way of deciding on things like when to roll out a sale, and to what customer segment, etc.  For a more complete discussion of this, refer to this article on my blog which gives a richer description of the differences.

Q: There are many competing companies, consultants, claiming to have hit on best-in-class processes or methodologies for harvesting business logic, and rules; e.g., Ron Ross and Glady’s Lam’s Proteus system, IBMs “Agile Rules” approach, KPI’s method called “The Decision Model”.  It’s mind boggling.  How do you know who’s right?

A: There are distinct methodologies, but the differences just come down to different approaches to interview techniques and ways of formalizing business logic.  Some of the vendors who have developed full-blown BRMS, have closely coupled their tool with a particular methodology, like Proteus has “Rules Express”.  Others are more agnostic like Corticon and InRule for example.

– – – – – – – – – –

Closing with reference to vendors and tools is a good segue to the 2nd part of this article which gets a little more nitty-gritty into what an actual modern BRMS looks and feels like, and how BAs interact with such a system. For this article, I’m taking a look at Corticon, which I came across via a webinar.  (Full Disclosure: I have no stake in their product and I’m not advertising or promoting their tool ahead of any others.  They were just kind enough to lend their time and ideas to this article.) Corticon’s webinar  was informative because it focused mostly on the end-user (the analyst) as opposed to the technicians and developers who implement these systems, and showed how analysts would capture rules into their repository and manage them.

I spoke with Corticon’s own top-dog analyst, Mike Bleyle, who described how BAs work with a tool like Corticon and what some of the benefits are to to the BA’s requirements process. Mike has a deep technical background, but not in software development.  He studied engineering in college and worked in Applied Materials in Silicon Valley in the 90’s.  He joined Corticon in 2000.

Mike Bleyle, Corticon

First, a peak at the Corticon 5 interface.  (click graphic for larger detail)

Q: Mike, your organization leverages the metaphor of the “decision table” and the “spreadsheet”.  Why is that?

A: For both SMEs with less of a technical bent but comfortable in Excel, as well as for technical minded analysts or developers who are not averse to ‘decision trees’, this metaphor works for everyone and is powerful enough to cover all cases of decision logic capture and expression, and technically, we found this metaphor is very compatible with our rule validation and analysis engine as well.

Q:  Do you find that BAs with a technical background excel in this environment, or are they perhaps hampered by their knowledge of implementation structures and back-ends?

A: It depends.  The technical BA, or the BA with a strong background in development, is often wary of any “code generation” engine.  On the other hand, they find the notion of “modeling” the objects quite natural, because they’ve used tools like Entity Relationship Diagrams and data object models.

Q: To that last point, what’s important about “models”.  What do you mean by that?

A: We talk about Corticon as “model driven rule development”, meaning as you develop your rules, you are really defining a business vocabulary at the same time.   In the screenshot you’re using above, there’s a “Customer” object which has attributes like “smoker” “age”, etc.  The key thing here is that models provide a layer of “abstraction” on the enterprise.  It lets a rule modeler focus on the business concepts at hand and not get caught up in implementation details; i.e., not think like a developer in terms of actual classes and objects.  At the same time, the good news is, a BRMS like Corticon allows the business user to focus on these high-level concepts or objects and sort of specify the “what’s” in the system and say what these whats need to conform to, and automatically, the system is turning the rule declarations into actual runtime code; meaning, the act of specifying the rules, is at the same implementing them.

Q: So which comes first, the object vocabulary or the rules themselves?

A: Really, both come along at the same time.  Rule writing and vocabulary development is an iterative process.  You get a rule, and it refers to something that then expands your vocabulary.  New vocabulary suggests possible rules. At Corticon, in our own customer training, we like to use the analogy of building with Legos.  If you remember when you were a kid, they just came out of the box and you kind of had to make it all up as you went along.  These days, they sell kits, with clearly defined things to build like “train stations” or “airports”.  As a modeler’s vocabulary is developed they can then model their business rules, akin to building that “train station” or “airport”.  And, as they go further, they can then get creative and build new rules and combine others together, sort of like the original Lego idea of “use your imagination”.  The tool facilitates both types of activity.

Q: At what point, does an enterprise really need, or should consider going with a BRMS?  For example, one company I know was managing millions of product SKUs with special pricing rules and finally realized Excel wasn’t doing the trick any more.  So,  size or scale is one criteria.  What else?

A: I like to say it comes down to these four major factors:

  1. Volatility (When business rules change often.)
  2. Complexity (When the rules are just very complex. Think IRS level complexity.)
  3. Volume (When the rules are just too many to manage, like your SKUs example.)
  4. Governance (When the rules lie within the domain of a SME, or they should.)

Q: Mike, what do you think are the key skills that Business Analysts need, to be really good decision management meisters?

A: Detail oriented for sure.  And you just have to be curious, and ask lots of questions.  “What if…” questions are ideal.  The tool itself will help you.  As you can see in the screenshot above, Corticon will highlight gaps in the rules, and suggest places your rules are either incomplete or in conflict with each other.

The bottom line is, we BAs need to take the kernel of information we get from the business, which is never the whole story, and then expand our boundaries, and capture the whole story by uncovering all those nascent rules and decisions, and only then do we have enough to really develop a solution.

Q: How does the BA’s requirements gathering process change, if at all, with a system like Corticon?

A: We try to help BAs in the upstream part of the process, by letting them test with real data.  Something that in the traditional model, only happens much later in the cycle, after the BA has thrown their requirements over the proverbial “wall”.  In this context, rules can be iteratively developed early in the process, and throughout the development lifecycle, and easily modified with little to no overhead costs of refactoring. The code generation engine just updates some web services. Our goal at Corticon is not just to provide a new way of coding logic, but to fundamentally change when the implementation occurs.

Q: Any other final words of advice for your BA brethren?

A: Don’t be intimidated by IT guys.  This is a team sport.  Never be afraid of asking questions.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.