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!
BIZRULES® RuleMap™ is an interactive rulebook that models business rules and simulates business logic. This logical model lets you see how your business rules really work. It lets you visualize the Reasoning Chain™ that leads to smart conclusions and right decisions. 
We use this tool to document your business rules independent of any BRE - yet it can be implemented using any BRE. Again, this is a logical model of your business rules. It can be used as the rulebook or specs for authoring the rules in any BRE.