Whether 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. 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.