Friday, December 30, 2005

The Rules of Business Just Changed. Again. How Fast Can You Change? THE STATE OF THE BUSINESS RULES MARKET 2006

By Rolando Hernandez, CEO, BIZRULES. 12/30/2005


Business rules automation is starting to revolutionize business.

In the next year or two, business rules automation is going to, pardon the pun, change the rules of the game. It is going to literally and figuratively rewrite the rules of business.

If your competitor uses rule engines, that means they can change their business rules on-the-fly without having to recode and recompile. They can change their rules instantly, you know with zero time-to-market, as the business changes, as the world changes, as customers change, as regulations change... If they can keep up with change, they can stay in the game.

If your company doesn't use rule engines, that means you have to go through IT to change your business rules. You have to get a programmer to change the code, test it, debug it, recompile it, test it, debug it, recompile it, etc. It's going to take you a while to change the rules. It might take a few weeks or more likely a few months to change the business rules in the systems, as the business changes, as the market changes, as customers change, as regulations change... If you can't keep up with change, you're out of the game. You lose.

They win.


In the long run (2006-2010), Business Rules Management will prove to be just as valuable to the enterprise as Business Rules Automation.

Knowledge Management (knowledge acquisition, knowledge retention, knowledge engineering) and Knowledge Automation will also prove to be just as valuable to the enterprise as Business Rules Management and Business Rules Automation.


Once awareness of the value of business rules management and the ROI of business rules automation reaches the board room, the enterprise will reach the stage where they are ready to establish the Business Rules Center of Excellence.

As enterprises start to realize significant ROI with individual (departmental)business rules automation applications, they will want to build & deploy more applications in other business areas and business functions.

Then they will begin to look for enterprise-wide opportunities to leverage rule engines. As the number of rule-based applications expands across the enterprise, they will focus more and more on standards, best pratices, and formal proven methodologies for building declarative rule-based applications.


Just like enterprises latched on to Six Sigma as the approach or solution to quality, smart enterprises will treat business rules as the approach or solution for time to market, downsizing, compliance, and offshoring.

  • Time to market (rules enable faster business change)
  • Downsizing (rules harvesting and knowledge acquisition captures and retains knowledge before it is lost)
  • Compliance (rules automation automates controls that prevent and detect risks)
  • Offshore systems development costs will be reduced and minimized by enabling business users to write and change their own business rules instead of a programmer


Yes, you read that correctly. Just as the enterprise looked to offshoring as the solution for rising systems development costs, the enterprise will look to business rules automation and business rules management as the solution to rising offshore development costs and time.

By enabling business executives to manage and change the business rules in the applications, they eliminate the code/test/debug/recode cycle. They don't have to go to IT (onshore or offshore) for change - they can change the rules themselves.

So the need for programmers, both onshore and offshore, will be reduced as the enterprise deploys business rule applications.


Yes, you read that correctly. Just as the enterprise looked to offshoring call centers as the solution to rising customer service costs, the enterprise will look to business rules automation and knowledge automation (expert systems) as the solution to rising offshore development costs and improving customer service delivery.

The great thing about democracy and commerce and competition is the relentless drive to improve productivity, reduce costs, and improve service delivery.

Thus, just as many programmers overseas and here will be replaced by business rule engines, many call center operators here and overseas will be replaced by Artificial Intelligence rule engines and knowledge-based expert systems that will give the right answer every time, 24/7.

AI-based self-service customer support websites will emerge, and people will love them. They will get the right answer every time. No more different answers depending on what agent you talked to. No more waiting on hold forever. Expert answers. Instant gratification.

(c) copyright Rolando Hernandez 2005


Thursday, December 29, 2005

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!