« Rules are a Paradigm Shift and the ROI is 10 to 1, according to many Business Rules Forum 2005 attendees in Orlando | Main | The Rules of Business Just Changed. Again. How Fast Can You Change? THE STATE OF THE BUSINESS RULES MARKET 2006 »

Use Business Rule Analysts for Rule Engines; Use Business Analysts for Code

I'd like to wrap up my blogging for the year with a couple of thoughts that I'd like to explore further next year.

My first thought is about the risks of offshoring rule harvesting. I'll talk about that next year. My second thought is on the state of the rules market. I'll write about that in my next blog. My third thought is about the differences between a business rules analyst and a business analyst. Here it is...

The business rules analyst is focused on separating rules from code. The rule analyst walks and talks business. He or she talks about business terms like customers and products and prices and services and business strategies and rules and policies and procedures and functions and rules and responsibilities and authorities and operations and conditions and action. The rule analyst talks about business rules and business logic. The rule analyst means business.

The business analyst sees rules as code. The business analyst talks about the system. A business analyst is often a systems analyst by nature, and by training. The systems analyst talks about program fields and screen fields, tables, user interfaces, primary keys, referential integrity, and code. When they talk about conditions and actions, they're often talking about what action to you take when the user pushes this button or that button on the screen. The systems analyst talks about program rules and program logic. They talk about the data access layer, and the bits and the bytes. The systems analyst means code.

Most Subject Matter Experts I know will tell you that they are sick and tired of having IT systems analysts come in and ask them the same questions over and over again. A good business rules analyst will ask that question once, and write it down once and for all.

I know it's confusing, and I can understand why some companies that are new to business rules think all they need is a business analyst to do rule harvesting. Maybe it's the title of business rules analyst or business rule harvester.

I don't like any of those titles, because they leave out one of the keys to success with the business rules approach and business rule technology: knowledge.

Back when business rule engines were called inference engines or expert systems, we used to have knowledge engineers. The knowledge engineer would handle knowledge acquisition, knowledge representation, and knowledge engineering.

Three things you miss when you use a business analyst instead of a knowledge engineer is knowledge acquisition, knowledge representation, and of course knowledge engineering. You also miss discovering and retaining the knowledge about the rules and the knowledge behind the rules. You miss the knowledge about what rule to use when and why. You miss the knowledge the experts have and need to use in order to figure out what the rules are. The good business rules analyst, or knowledge engineer as I like to call them, elicits this invaluable knowledge from the experts, digitizes it, and memorializes so it cannot be forgotten.

If you don't use a business rules analyst (i.e. a knowledge engineer) on your business rules project, you won't capture the true business knowledge, and you won't get all the business rules. You will get lots of computer program rules, and you will increase your risk of failure.

Companies often run into trouble when they try to use business analysts instead of business rule analysts to define their business rules.

That's when they call BIZRULES. We help them get back on track with the business rules approach, methodology, and technology.

In many cases, the client's business analysts have invested a lot of time writing use cases, and everyone thinks that the business rules would be in the use cases. Eventually the client discovers that use cases are useful for designing object-oriented systems, but they're really not that useful for defining business rules. That's one problem.

Another problem is that the business analysts are often really systems analysts with a new title. They are coming at this from the systems point of view, from the code perspective, from the technology side, not from the business side.

But the biggest problem is that most companies do not know what the business rules are. There is no rulebook that tells management what the rules in the existing system are, or that tells IT what the business rules in the new system should be.

Companies decide to use rules technology because the rules change often and because they see a lot of value in enabling the business people who make the rules to actually write the rules in the system.

Once they leap into the business rules side (is that the dark side?) companies realize they need a rulebook with the rules of the business. They have specs, and lots of good documentation, but they usully don't have a rulebook that you could use to author the rules into the rule engine. So they need to go thru the rule harvesting phase of the business rules approach.

Some companies new to the business rules approach consider using business analysts (i.e. systems analysts) instead of business rule analysts (i.e. knowledge engineers) for rule harvesting.

That approach works for traditional IT-driven procedural hard-coded applications. But for leading-edge business-driven declarative rules-based applications, traditional business analysis and systems analysis techniques are probably not going to work. Knowledge engineering techniques and business rules analysis techniques, however, will work.

I believe there is a very significant difference between a business rules analyst and a systems analyst.

The rules analyst wants to define the business rules separately from the code. He or she wants to store the rules in the rules engine. Their objective is to write rules for rule engines.

The systems analyst sees rules as code. They want to embed the rules in the program code. Their job is to document the rules so they can be hard coded in whatever language the programmers are using.

There's a lot more to it than that, so I'd like to continue the discussion next year. Meanwhile, I'd like to hear your thoughts on this topic. What do you think is the difference between a rules analyst and a business analyst?

Have a happy and safe New Year's Eve. And best wishes for a great new year!


TrackBack URL for this entry:


Thanks for your note, Jenny.>> What are business rules and what are not.

Business rules are the way the business works. The decisions the business makes, and the activities that the business must do, permits, or prohibits under various conditions are examples of business rules.

Requirements are the things that computer system needs to do. Rules about screen validations (as you said above) or rules about what color to display data on the screen, for example, are really system requirements, not business rules.

>> Would you know of any sites that suggest how one can decide which layer to implement which business rules - guidelines etc for this.

Business rules can either be hard-coded and maintained by IT, or they can be stored in a business rule engine and maintained directly the business. To help you decide what layer to implement business rules in, please see my recent blog post:

What rules belong in the BRE and what rules should be hard-coded? (FAQ #2)

I hope that helps!

Just a query here.What are business rules and what are not.Every rule of a business seems like a business rule (except some screen validations like telephone number not longer than xyz characters)Say a rule which says, an employee can nominate maximum 2 dependants, would be implemented in the UI layer - 2 texboxes/rows for the 2 dependants - but it is still a business rule.Would you know of any sites that suggest how one can decide which layer to implement which business rules - guidelines etc for this.

Rolo - or Rolando - Three cheers for the Knowledge Engineers, those draconian dogmatists of the distant past. Well, I are one. :-) And nothing distresses me more than to have to explain over and over what IS a business rule and what IS NOT a business rule. Secondly, along with the rules (which really are code when looked at from a business viewpoint) there SHOULD be a reason for each rule and possibly some kind of explanation - something we old timers called documentation. Paper work. It just seems to follow a well-done job. :-)

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Locations of visitors to this page