Business Analysis with Business Rules


Excerpted with permission from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October, 2011, 304 pp,

Continuous change is a central fact of life for business these days. The techniques you use for business analysis must be based on the assumption that business rules will change, often quite rapidly. The best business solution is one that caters to such change, always doing so in the manner friendliest to business people and Business Analysts.

What other issues should techniques for business analysis be addressing these days? In addition to continuous change:

  • Capturing, managing, and retaining business know-how.

  • Enabling more effective business governance.

  • Making compliance (with business rules – what else?!) more effortless.

None of these challenges is well served by the kinds of information systems we’ve built in the past. We need to engineer a new kind – business operation systems.

The challenge is not about fixing software engineering practices. It’s about changing them fundamentally. We think it’s way past time they were. Current practices probably miss as much as 90% of everything important in running the business(!).

What a Business Rule Is

A business rule is a criterion used to guide operational business behavior, shape operational business judgments, or make operational business decisions. Business rules are only indirectly about system design or behavior. Your business would need its business rules even if it had no software.


Everyone asks: How do you close the gap between the business and IT? We think that’s the wrong question. You want to do that, sure. But the question as posed more or less implies the solution will be organizational, whether by new styles of interaction, better project management, restructuring, or other means.

Instead, we think the key to an effective solution is architecture. Use the right architectural approach and the organizational issues will take care of themselves (one way or another). So we ask: How do you align business operations with business strategy?

To be frank, most Business Analysts lack the standing in their organizations to pull off enterprise-level solutions. We hope that situation changes (and over time, we believe it will). Experience suggests taking smaller steps is wise. (We didn’t say small steps, just smaller).

So we right-size the question to the more achievable, smaller-scale equivalent: How do you align business capabilities with strategies for solving business problems?  You'll find success at that level of alignment fruitful (and challenging) enough(!).

What a Business Capability Is

A business capability is not an application system, database, set of use cases, enterprise architecture, or any other IT artifact.  Its design and implementation might depend on some or all of those things, but that’s a different matter.

Instead, a business capability is created as a business solution to an operational business problem.  That solution and the problem it addresses have a scope (definite boundaries) that can be identified in terms of what business items make it up.  The business solution is initially developed and expressed as a business strategy – what we call a Policy Charter.

The business model you create in business analysis is the business architecture for the business capability, a blueprint enabling business people and Business Analysts to engage in a business discussion about what needs to be created, managed, operated, changed, and discontinued.  Developing a business solution using a business model does not necessarily imply software development, but if software development does ensue (and it usually does), the business model provides a solid grounding.

Our definition of business capability comes down to this:  What the business must know and be able to do to execute business strategy.
You'll notice we keep repeating business as a modifier (business solution, business problem, business capability, business model, business strategy, business rules, and so on).  We do it in practice too.  It’s a reminder that our focus is always on business things, not system or IT things.  When we say business, we mean business.

Basic Principles for Business Analysis

You can see already we’re very careful about how (and when) to ask questions. How you ask questions makes all the difference in the world. Question the questions!

Basic Principle for Business Analysis: Always seek to ask the right question in the right way of the right people at the right time.

In creating a business model we also take great care never to use ITspeak in talking with business people. IT terminology provides an easy and understandable reason for business people to drop out of business discussions. A business model is always about real-world things, represented using terms that business people would naturally use.

Basic Principle for Business Analysis: Use no term in talking with business people about the business they wouldn’t use naturally.

Avoiding all ITspeak is hard. Many familiar terms assume development of software systems. Two examples: use case and data model. Both terms originated from IT and imply a system. In developing business models you don’t need those terms(!).

Here’s a related point. ‘Users’ exist only if you’re thinking about building an IT system. We avoid the term. In the business context, business people are not ‘users’, they are the central actors in the day-to-day drama of business activity. Anyway, everybody is a ‘user’ of some system these days, so ‘user’ doesn’t much discriminate anything.

Basic Principle for Business Analysis: Never say ‘user’.

Now we confess that last one is hard. It takes practice. We still slip up once in a while ourselves.

Change Deployment Hell

A business manager at a very large health care organization recently confided to us that making a change to business rules of even moderate complexity took their organization 400 person-days over a 4-month period. That’s staggering. How could it be sustainable? Their organization, like many today, is living in change deployment hell.

The manager went on to observe that a subtle stagnation had crept into the staff’s very way of thinking about the business. He noted that they often don’t even consider business innovations they know from experience to be difficult for the existing systems to handle. He wondered out loud whether they could even think through any real business innovation effectively any more. The bottom line: They needed a new approach, not more of the same.

By the way, the people at this organization were hard-working and very engaged in their activities – they did want to deliver good quality. That wasn’t the problem. Indeed, we find most people in our field to be very professional and to have the best of motivations.

We can do better than that, smarter than that – we can and we should. Ask yourself this fundamental question: Do you really want to continue embedding the business rules you need to run the business in application programs?!

We would assume you don’t. You want pragmatic, proven approaches for identifying and externalizing business rules from all other artifacts produced in business or system analysis. In short, we treat business rules as a first-class citizen. We think everybody should.

Can you really engineer business rules separately from requirements for application software? Absolutely. It’s a proven fact.

Business Rules vs. Requirements

Let’s be very clear that business rules and requirements are not the same thing. When you set out to create a software system, business rules can imply requirements – but that’s a different matter.

Here’s a major difference: Requirements evolve before deployment of a system; business rules evolve after deployment of a system. That affects everything.

To bring the distinction into perspective, consider data for a moment. Would you consider actual business data – not the data definitions but the actual data itself – to be part of requirements? No!

The life cycle of data and the life cycle of requirements are simply not the same. The life cycle of requirements, no matter what methodology you use, more or less ends with official software release. For data, in contrast, that’s just the beginning of life. The data persists. More importantly it changes over time. That’s the very essence of doing business. It’s so obvious we take it for granted.

Real Life Begins at Deployment

The very same is true for business rules. Official software release is just the beginning of their life. They persist. More importantly they change, sometimes rapidly, because a business constantly needs to adjust its business parameters.

Basic Principle for Business Analysis: Always remember the business rules live on.

The distinction between the software development life cycle and the life cycle of business rules is sometimes hard for those in IT to grasp. Indeed, if you’re looking through the lens of software development methods, you’re almost certain to be confused. When you look at business rules from the business point of view, however, seeing the distinction is far easier.

Eventually all companies will appreciate the distinction. Then the need for managing rulebooks as a separate resource (just like databases) will be obvious. We call that activity rulebook management. Leading companies are already doing it.

Order-of-Magnitude Improvement in Business Agility

Today’s information systems aren’t agile – even when agile software methods are used to develop them. Companies need business agility and in most cases, IT simply isn’t delivering it.

We believe you should aim for nothing less than order-of-magnitude improvement in business agility. Is that possible? Absolutely! Here’s a brief case study.

Order-of-Magnitude Improvement: Case Study

A medium-sized financial services company we visited specializes in detection of credit card fraud. Suspicious transactions are kicked out to fraud specialists for manual inspection. These fraud specialists are an expensive and largely non-scalable resource.

Suppose the bad guys pick up and move shop from Idaho to Manhattan. Transactions deemed suspicious only by zip code suddenly yield a 10x increase in volume. To keep the volume of kick-outs relatively constant, additional selection criteria (e.g., location of store, type of store, frequency of use, size of transaction, etc.) must be introduced.

Before using business rules, the elapsed time to deploy revised selection criteria was 30-60 days. By then smart bad guys are already operating somewhere else. Using business rules, the company decreased the elapsed time to 3-6 days. Would you say their business had become more agile?
You bet! That’s an order-of-magnitude improvement.


Our world is fast-changing, highly-regulated, and knowledge-intensive. Business operations are highly complex and becoming more so by the day. Business Analysts didn’t invent the complexity – they are simply the ones who must come to grips with it.

Success requires the right thinking tools to structure the analysis of business complexity. Business Analysts must be able to bring those tools to the table apply them with business people.

Basic Principle for Business Analysis: Be the master of thinking tools to address business complexity.

Is there any other way? We don’t see any. One thing for sure – doing more of the same, just faster, is not going to work. Existing IT techniques have simply maxed out. As Kathleen Barret, CEO of the IIBA says, we need to take it to the next level.

We concede the problem is big one. It’s all around us everywhere we look. It’s like what an ant crawling up an elephant’s leg can’t see. The elephant is just too big. We don’t concede, however, there’s no solution. We’ve proven there is. But first you must see the elephant!

Authors :

Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of and as Chair of the Business Rules Forum Conference. He is the author of eight professional books, most recently Business Rule Concepts (2009). Mr. Ross speaks and gives popular public seminars across the globe. His blog:

Gladys S.W. Lam is a world-renowned authority on business analysis and applied business rule techniques. She is Co-founder and Principal of Business Rule Solutions, LLC, the most recognized company world-wide for business rule methodology, consulting services, and training. Ms. Lam serves as Publisher of and as Executive Director of the Building Business Capabilities Conference. She is a recognized expert on project management and is highly active in consulting, mentoring, and training.

Like this article:
  16 members liked this article


Bert Vester posted on Wednesday, October 12, 2011 1:43 AM
I have been a Business Consultant for the finance industry for well over 20 years now and before that I worked in the industry for about 10 years as a credit officer and a branch manager. I have always felt that my business experience in this particular branch of industry provides added value to my customers that I would not be able to deliver to customers in other industries.
Nowadays there seems to be a general belief that anyone can become a Business Analyst as a career step for IT people. BA's today never seem to come from the business side anymore.
In my view this is simply not right and that is the reason why I am sceptical about the apparent presumption that it is not really vital to have a sound understanding of aspects like what a particular business is about, why processes are structured the way they are, how a user looks at his tools, how a proposed change will affect which processes and what the success factors are within the business culture.

In short, to me it is just as important that a BA knows the business and understands what he is doing from a business perspective.

I applaud the vision behind this article, but I do feel the knowledge/experience/ understanding aspects should have been given more attention.
Ron Ross posted on Wednesday, October 12, 2011 5:03 PM
@Bertv -

In our thinking, Business Analysts don't need to know the answers, but they do need to know how to ask the right questions about the business ... and more importantly, they need to know that they *do* need to ask them.

You have to have business people in the room. There's no substitute. In our experience, when you organize discussion of business solutions around the right 'thinking tools', business people 'get' it. They may not know how to represent the answers properly, but that's what Business Analysts should be able to do (in non-IT form).

In defense of IT professionals, they do have abstraction skills that many business people lack (for whatever reason). But by no means does that alone make them good BAs. Some business-sde people on the other hand do have the necessary abstraction skills (like yourself apparently). Often, those make the best BAs of all.

Bert Vester posted on Monday, October 17, 2011 1:16 AM
Well, I agree, nobody can know all the answers. After all, what then would be the use of asking questions?
I don't want to engage in a semantic discussion, but I think the challenge for a BA is to get the right answers, i.e. the answers behind the answers, the answers that will give genuine insight into the issue that needs to be solved, the business requirements, any additional prerequisites, potential solutions and acceptance criteria. It is a bit of a paradox, but a key-user really has to buy in to your project even if you are trying to help him do his work better. You know you got it nailed when he starts telling you stuff you didn't know to ask for.

That requires professional respect and trust on the side of the 'business' and that trust is not just built on the fact that you know a lot about IT or that you are intelligent or that you are able to formulate your questions well. I think that this trust comes from the fact that you as a BA can relate to his, the users', day to day activities, that you understand his business processes and the cross-links with other processes.

This is why I regret that BA is so often confused with BIA, business information analyst, whose work is described in the BiSL. I have found in my current work environment with a large bank in the Netherlands that many BAs think there is nothing beyond their own discipline.
In my team of BAs there is even an antagonistic attitude towards the suggestion that you cannot capture all aspects of a solution in Use Cases, that there is true value in looking for the bigger picture, that not all solutions have to be IT based and that it is wise to document processes.

I thank you for your response and for the chance to discuss some ideas with you.

Best regards,
Bert Vester,
Utrecht, the Netherlands.
Ron Ross posted on Tuesday, October 18, 2011 3:11 PM
@Bert - It is not only wise, but necessary for effective BAs to realize [as you say] that:

* You cannot capture all aspects of a solution in use cases.
* There is true value in looking for the bigger [business] picture.
* Not all solutions have to be IT-based [in part or in whole]
* It is wise to document processes.

To that I'll add a few more things:

* Respect the knowledge of business people [You said as much.]
* Understand how to use strategy with business leads as a analysis tool.
* Realize there is no single magic-bullet model that addresses all needs.
* Appreciate the importance of expressing business rules and using them as an analysis tool.

One last thing ... although in practice we don't use what I call the "S" word [semantics]. why is it a dirty word? Every single bit of verbal or written communication *is* a matter of semantics, like it or not. We're just talking about what words mean. What could possibly be more basic? A great many problems with requirements can be traced to problems of definitions. It's another essential skill for effective BAs.
zarfman posted on Monday, October 24, 2011 10:52 PM

I consider this one of the better articles you have written.

You wrote: To be frank, most Business Analysts lack the standing in their organizations to pull off enterprise-level solutions. We hope that situation changes (and over time, we believe it will). Experience suggests taking smaller steps is wise. (We didn’t say small steps, just smaller).

Zarfman writes: In my experience the lack of standing and lack of understanding are common at lower levels in the enterprise.

Zarfman writes: What I'm about to suggest may be considered a form of heresy. I suggest that the Actor do the analysis. Actors hopefully understand the business problem better that anyone else. The basic concepts of interface design, programming and DBMS systems are not difficult to understand. I do admit that while the basic concepts are not difficult. Complexity and lack of competence rears it's ugly head quickly. I doubt one out of ten DBA's know the difference between the Codd and Date 1NF.

You wrote: One last thing ... although in practice we don't use what I call the "S" word [semantics]...

Zarfman writes: I am violent agreement with your with your comment on semantics. Let us consider strategy. When viewed from the military standpoint strategy is said to be composed of four components grand strategy, strategy, operations, and tactics.


Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC