What Analysts Need to Know about Decisioning and Business Rules: Interview with Ronald G. Ross

Featured
17431 Views
4 Comments
9 Likes

What Analysts Need to Know about Decisioning and Business Rules: Interview with Ronald G. RossWhether you’ve never heard of business rules or you are a business rules guru, you need to understand that business rules need to be a first-class citizen of the requirements world.

In this interview, Ronald G. Ross, recognized as the “father of business rules,” shares his wisdom on business rules and what every business analyst needs to know about decisioning and business rules.

Modern Analyst.com: What's the best definition for business rules?

Ronald G. Ross: Business rules are simply criteria for making decisions.

Modern Analyst.com: What kind of decisions do you mean?

Ronald G. Ross: Day-to-day, minute-to-minute decisions in running the business. Generally, the decisions are being made within some business process, which might or might not be formally organized by a model. The important thing about these operational decisions is that they are highly repetitive - they might be taking place hundreds or thousands of times per day, per hour, or even per minute. They are predictable and fairly well structured in terms of the kinds of outcomes they produce. You want such decisions to be consistent and traceable across platforms, channels and organizational units.

Modern Analyst.com: Can you give some examples?

Ronald G. Ross: Just off the top of my head - How do we price our product for this particular transaction? What credit do we give to this customer at this point in time? What resource do we assign to this task right now? Do we suspect fraud on this particular transaction? What's the best cross-sell or up-sell offering for this sale? Do we anticipate any delay on this shipment? These all represent operational decisions in day-to-day business activities.

These kinds of decisions are operational rather than strategic, high-volume rather than occasional, deterministic rather than fuzzy, and low-to-moderate complexity rather than high complexity.

Modern Analyst.com: Don't current methodologies already address how such decisions are made?

Ronald G. Ross: No, not at all. Here's a test. Go into a company, pick any decision like the ones I mentioned, and ask to see the list of the criteria - the business rules - routinely used to make the decision. You'll probably get just blank stares. Not good, of course, if you happen to be an auditor, a regulator, a manager, a business partner - or a business analyst.

So how do you get the rules? You can review policy and procedure documents, but those are usually fragmentary and inconsistent with implemented systems. You can examine the legacy systems themselves, but reverse-engineering the business intent of procedural code - to put this as delicately as possible - is non-trivial. Your best bet is probably to just go ask the subject matter experts. But those are very busy people. And what if they've already retired or gone to work for another company?!

Current situation in most companies today is woefully inadequate. The business rules represent core know-how, but very little is being done to capture or manage it.

Compare that to any game you might play. There is always a rulebook. It tells you what the rules are. If there's a change to the rules, it's single-sourced. Everyone knows how the game is to be played - if you don't, you can go look it up. That might take minutes - but certainly not days, weeks or months.

Modern Analyst.com: Is the current problem with infrastructure or with methodology?

Ronald G. Ross: Yes. Where would you like to start?

Modern Analyst.com: First, what's the problem with methodology?

Ronald G. Ross: Suppose you're doing business process models. Where's the bit that deals with criteria for making individual decisions?

There's much confusion over process models. Process models are really about doing transformations - raw materials into finished goods, inputs into outputs. Their strength lies with organizing chunks of work that might cross organizational boundaries and optimizing hand-offs. They're great at taking a beginning-to-end view, of orchestrating the work to get the end-result out the door faster and more efficiently, and at eliminating bottlenecks. But where's the focus on decisions and the business rules serving to make those decisions? Where's the focus on know-how and how it's applied? It's simply missing. Process models do very little to help your company work smarter.

Or let's look at use cases. Great at developing man-machine dialogs and developing effective patterns of interaction and the software to support it. But where's the focus on decisions and business rules? Again, missing. Many good analysts do, of course, annotate business rules, or something akin to them, along with their use cases. But these rules are at best a second-class citizen. They are generally specified for each use case individually, rather than unified and coordinated across all the use cases. They are usually expressed procedurally, rather than declaratively. There is no unified basis for testing individual rules, or sets of rules, across all the use cases that touch on them. Business rules are simply not an inherent part of the use-case mindset. By the way, you can be as agile as you want about your development approach - that's still not going to get at the rules of the business game.

Let's be sure not leave anything out here. What about data models? You might specify some integrity constraints, but with respect to business rules, those represent just the tip of the iceberg. You can write stored procedures, but that takes you back into snarly procedural code.

What about class diagrams? You don't get at decision criteria by encapsulating methods. It simply doesn't work that way.

The bottom line, as the Business Rules Manifesto puts it, is that business rules need to be a first-class citizen of the requirements world. There's really no other way to address business know-how effectively. And without doing that, there's no way to achieve smarter processes, retain knowledge, customize on a mass scale, demonstrate compliance - or surmount many of the other challenges facing businesses today.

Modern Analyst.com: What business analysis techniques are needed?

Ronald G. Ross: You need to add decision analysis techniques to your analysis toolkit. You need to understand how to identify and analyze decisions. You need to know how to capture the business rules used to make the decisions. You need to understand how those business rules are best expressed and organized for visualization. You need to understand how to organize and manage the results.

Let me make several points about this. First, doesn't it seem odd to you that very little attention is given to the engineering of decision tables in our industry? Yet in real-life, decision tables are everywhere. Think income taxes, for example. I expect an explosion of rekindled interest in decision tables over the next several years. For the life of me, I can't explain why this valuable tool - whose theory and application actually predates software engineering - is so obscure today. Frankly, I think software engineering methodologies have taken us down some blind alleys.

Second, I expect we'll see some very interesting new approaches for modeling decisions themselves. It will be interesting to see how this plays out - not all the techniques will prove complete and effective - but some will surely excel. Meaningful criteria do exist for evaluating and categorizing decisions so that subsequent analysis can be intelligently targeted and well structured.

Third, it's clear you'll want metrics around decisions, including simulations of alternative sets of business rules to assess differential results. That brings us to predictive analytics, and whole new areas of opportunity. That's happening even as we speak.

Modern Analyst.com: How can decisions be categorized?

Ronald G. Ross: It really depends on where you want to focus. One way is whether or not the decision involves the actions of people, as opposed to evaluation or creation of knowledge. People can violate business rules. How you respond to such violations is right at the heart of making systems smarter. I talk about that a lot in the new edition just out of my book, Business Rule Concepts.
Another has to do with whether you are most interested in doing things correctly, or in achieving correct results. The former takes you toward business process modeling and to the business rules that help orchestrate processes. The latter takes you toward decisions as a focal point in its own right.

Yet another is whether a decision pertains to resource allocation. Generally, you'd like to apply business rules in as close to real time as possible, so errors and violations don't compound themselves downstream in the business process. But with resource allocation, generally the longer you can wait the better. That way results can be optimized.

You can also ask questions about whether the relationship of cases to appropriate conclusions is one-to-one, and if not, how that affects the analysis.

Modern Analyst.com: You mentioned decision tables. Can all business rules be organized into decision tables?

Ronald G. Ross: No, not by a long shot. Your business has hundreds or thousands of one-off rules. You shouldn't use decision tables for those. That's not clever at all.

Modern Analyst.com: What are some examples of one-off rules?

Ronald G. Ross: A customer that has ordered a product must have an assigned agent. An auditor must not audit any manager who lives in the same city. A high-risk customer must not place an order on credit.

Modern Analyst.com: What to you need to express one-off rules effectively?

Ronald G. Ross: A business-friendly, vocabulary-based language. We've developed RuleSpeak for that purpose. It's a pragmatic set of guidelines for writing business rules using structured natural language. RuleSpeak is not just about better writing; it's about writing business rules well.

Modern Analyst.com: Besides methodology, you mentioned there is also an infrastructure problem in supporting business rules and decisions. What does that involve?

Ronald G. Ross: Let me answer the question first for the business itself, then for IT architecture.

To start with, business analysts need to stop thinking of business rules as simply another form of software requirement. There's a huge difference. When a project is over, software requirements, in theory, are satisfied and go away. For business rules, in contrast, that's just the beginning of their life. The business rules, and the vocabulary on which they are based, become central to the problem of affecting continuous change. They need to remain right at the fingertips of both business people and business analysts. They must be accessible and well-managed. Above all, you want traceability from original sources (business policies, agreements, contracts, laws, regulations and so on) into the points of operational deployment. You want to know who created what rules for what purpose at what time. I call all that "corporate memory'. Without traceability, you can have no accountability, and without accountability, you can have no transparency. And you can forget about rapid change altogether.

Can business rules be managed as a business proposition using tools and repositories aimed at software development and IT developers? The answer to that question is an emphatic no. You need a new breed of tool, which I call a general rulebook system (GRBS), a term I coined for Business Rule Concepts. The point is that the life cycle of business rules and the life cycle of software releases are different. They serve audiences with very different agendas, and have a very different natural pace. They need to be radically decoupled.

The second aspect of infrastructure that needs to be addressed is the run-time evaluation of rules in IT architectures. Procedural languages are simply not good for that, especially at the scale we now require. Instead, you need business rule management systems (BRMS) - often called rule engines. Think of a BRMS as being to rules more or less like a DBMS is to data. Would you even consider writing your own DBMS these days? No! Yet many organizations today are still doing the equivalent for run-time evaluation of business rules. It's simply inappropriate for IT organizations to continue doing that any longer.

Growing numbers of organizations have adopted commercial or open-sourced BRMS. Five or ten years from now, we'll look back and wonder why it took so long to happen.

Modern Analyst.com: What kind of success do organizations have with BRMS?

Ronald G. Ross: Every year in the 12-year history of the International Business Rule Forum Conference, I've heard one compelling story after another about spectacular innovations and achievements with BRMS. At this point, these tools have a rock-solid, well-documented track record of success.

To illustrate, let me cite the case of a medium-sized financial services company that specializes in detection of credit card fraud. Like a nasty virus, fraud scenarios constantly evolve. The company's business process kicks out suspicious transactions to fraud specialists for manual inspection. Because these fraud specialists are an expensive and largely non-scalable resource, the company tries to keep the volume of kick-outs relatively constant. So both to detect new kinds of fraud, and to maintain a balanced load, the company continually refines the selection criteria.

Here's a sample scenario to illustrate how things go. The bad guys pick up and move shop from Idaho to Manhattan. If the selection criteria remained only by zip code - that's an oversimplification, of course, but let's say that's it for the sake of discussion - they would get an immediate order-of-magnitude increase in the volume of kick-outs. They must add additional selection criteria such as the location of the store, type of store, frequency of use, size of transaction, etc. The elapsed time to deploy such refinements in selection criteria had been 30-60 days; after introducing a BRMS, the elapsed time was reduced to 3-6 days. That's an order of magnitude improvement! Would you say their business had become more agile? You bet!

Modern Analyst.com: What about the costs associated with bringing in the BRMS?

Ronald G. Ross: Listen to this. They told us that they had more than recouped the cost of the rule engine from their savings on this very first deployment alone! And that was without adopting any new, rule-friendly methodology. Actually, that's why they brought us in - they figured they could do far better if they did have one. They were already planning to move aggressively toward re-engineering some other decisions.

The important take-away is this. The company did not simply try to improve their existing software development practices. They did not try simply to sift out and faithfully applying the "best practices" of the past 35 years of software development. They understood that wasn't going to work any more.

Companies today want order-of-magnitude savings and improvements. That's going to require deliberate changes in tools, in methods, and in mindsets - a new focus on business rules, decisioning and related technologies. Business analysts need to take the lead in ushering their companies toward this new way of doing business smarter.

About Ronald G. Ross

Ronald G. RossRonald G. Ross is recognized as the “father of business rules.” He serves as Executive Editor of www.BRCommunity.com and its flagship publication, Business Rules Journal, and as Co-Chair of the Business Rule Forum Conference. Mr. Ross is the author of eight professional books, including the Business Rule Concepts (2009) and Principles of the Business Rule Approach, Addison-Wesley (2003).

At his company Business Rule Solutions, Mr. Ross engages in seminars, consulting services, publications, the Proteus® methodology, and RuleSpeak®. He gives popular public seminars through Attaining Edge and IRM UK.


Like this article:
  9 members liked this article
Featured
17431 Views
4 Comments
9 Likes

COMMENTS

zarfman posted on Wednesday, November 11, 2009 3:52 PM

Greetings:

This is Zarfman again. My cognitive abilities must be declining with age. I find this article confusing. This is probably due to my finance and accounting background and to some degree semantics.

Someone wrote - In this interview, Ronald G. Ross, recognized as the “father of business rules,” shares his wisdom on business rules and what every business analyst needs to know about decisioning and business rules.

Zarfman writes – I find it hard to believe that Ronald G. Ross, is the father of business rules. What is this claim based on, what software, what system and when was this done? Who is the recognizing authority? I shared this information with several of my colleges, they all scoffed at the assertion.

In fact on Ross’s web site he admits thinking about business rules in the 1980’s and started talking publicly about his ideas in 1994. In fact that’s about 20 years or more after business rules were already well known.

Accordingly, I don’t see business rules as anything particularly new. In fact one of the first inventory control systems I ever saw was written in FORTRAN. In the late 1960s banks were using COBOL to handle their check processing and banking operations. Both of these applications had lots of business rules and these rules were implemented. If these business rules had not been implemented the bank regulators and auditors would have had a field day.

I would suggest that the writers’ and promulgators’ of the rules are the fathers of the rules, not those who implement them in some form or fashion. In 1913 the 16th amendment gave us federal income tax. Both individuals and businesses ignore this at their peril. For many years there have been a myriad of federal, state and local rules that businesses must adhere to.

Moreover, in the 1960s and 1970s the need to understand business rules became brutally apparent when various firms started doing business with the Federal Government. The Feds have very specific rules on allowable vs. un-allowable costs regarding federal contracts. I saw several of our competitors go out of business because they included un-allowable costs in their invoices. The Government auditors said you owe us money. These firms said we don’t have it. The Feds shut them down.

Granted, today we have more sophisticated hardware and software techniques for implementing these business rules. And this is to be expected.

If I have somehow misinterpreted this assertion let me know.

Regards,

Zarfman
zarfman
Ron Ross posted on Tuesday, November 17, 2009 7:38 PM
Zarfman,

It's a really big world out there. You are correct that 'rules' have a long history -- probably as old as the human race. And of course, there are rule-based approaches to a wide variety of problems, including expert systems just to name one. A lot of really, really smart people have worked in the field.

The area of 'business rules', relativey speaking, is a rather small one. It did not grow out of any technology space (rather odd in business computing), or any academic theory (originally). Instead, it began in the late 1980s when a group of IT professionals (including yours truly and Barb von Halle, among others) -- forerunners of today's business analysts -- began to see that procedural approaches to business problems simply are not agile (to use today's term).

We set out on a journey,almost squarely into the wind of mainstream IT practices until just recently, to bring some sanity into the requirements space. Your background in accounting and finance puts you in an excellent position to understand what we needed to do. Accounting, taxation ... what could be more rule-based than that?

You didn't say, or perhaps I missed it, whether you have background in IT ... the kind that supports medium- to large-sized business. Even today, the large majority of IT professionals still don't get "rules for business" -- business rules. They write use cases and/or an odd array of requirements specs that never express rules of the business in native form, which is to say in declarative sentences or structures (e.g., decision tables). Truly bizarre.

Anyway, a goup of us set out in the late 1980s to try to set things right. We've produced some great work over the years, including The Business Motivation Model and the Semantics of Business Vocabulary and Business Rules (SBVR). If you're interested in this small-world history, you might enjoy: “A Brief History of the Business Rule Approach,” Business Rules Journal. Available at www.BRCommunity.com. You will not find the term "business rule" in any literature before that time -- that is, the mid- to late-1980s. (That's what makes it a relatively small, new world.)

I've had the great pleasure to be involved extensively and without interruption with this work all the while. I've been Chair of the annual Business Rules Forum Conference, now in its 14th year. Twenty years is probably just the amount of time it takes for a major paradigm shift to occur in professional practices. It's no silver bullet. But it finally seems to be happening.

Ron Ross
Co-Founder & Principal, Business Rule Solutons, LLC
Executive Editor, Business Rules Journal, BRCommunity.com
rross
zarfman posted on Friday, November 20, 2009 11:09 PM
Ron:

I can be persuaded that you and or one of your colleges jointly or severally coined the phrase business rules. Accordingly, you could be termed the father of the PHRASE/TERM business rules.

We may have to agree to disagree or not, as to you being the father of business rules per se. As I recall we tended to name them after the originator and promulgators of the rules. Such as; GAAP, FASB, TAX RULES, IRS RULINGS, GAS and last but not least the AICPA. I strongly believe business rules must be written by skilled practitioners of the business art or science. Not by IT or any other non-practitioner.

As to your question regarding my IT background. I first became acquainted with computers in the aerospace industry. I was part of a small engineering team that designed computer controlled missile systems check out and launch equipment. Later in my career I designed computer based flight control systems where system stability is paramount because people can die if you analysis is faulty.

As one moves up in engineering management one gets exposed to costs, budgets etc.
I managed convince the company I was working for to pay for my MBA studies, later I took a year or so off the get the required accounting courses, sat for my CPA exam and the rest is history. Before I would accept any position, i.e., CFO, VP finance etc, part of the deal was that IT had to report to me. These IT groups ranged in size from 10 to 150 people. These are just the highlights, I could add more but you’re probably already bored.

Per your suggestion I visited your web site BRcommunity.com. It looks to be very interesting. To view an entire article I found I had to register, which I did. I was under the impression I would get some sort of response that would allow me to activate my account. Unfortunately, when I try to log on it rejects my user name ((zarfman) and password. I tried registering with a different user name but same e-mail address. The system said someone already had my e-mail address. So I think I’m in the system. I would appreciate any help you could give me.

Regards,

zarfman
zarfman
Ron Ross posted on Tuesday, November 24, 2009 12:21 PM
Zarfman,

We do agree very strongly on this: "... business rules must be written by skilled practitioners of the business art or science. Not by IT or any other non-practitioner". Working to make that possible is what "business rules" (meaning the business rules *approach*) is all about.

Ron

P.S. In the end, were you able to find the article "A Brief History of the Business Rule Approach" on BRCommunity? Do have a look ... Should shed a lot of light on the discussion.

Co-Founder & Principal, Business Rule Solutons, LLC
Executive Editor, Business Rules Journal, BRCommunity.com
rross
Only registered users may post comments.

 



Upcoming Live Webinars

 




Copyright 2006-2024 by Modern Analyst Media LLC