The Business Rules movement has begun the transition from being a niche approach to entering the mainstream of organizations’ project techniques. Where once organizations saw only business processes and requirements, they now also see business rules. In fact, it’s tempting to see everything as business rules. In the midst of the movement’s first encounter with fame and fortune, it’s a good time to ask what the real value proposition is for business rules and whether everything that is potentially a rule should be treated as a business rule.
It is often said that the intent of implementing a business rules approach is to make it possible for the business user to be able to control their own rules. For this to happen, business users must be able to design executable business level specifications and business rules are a key part of this. In most organizations, operational business personnel don’t see this as a primary responsibility and they don’t have the skillset necessary to do this task. Instead, these business users supply to business analysts a set of goals and characteristics of the solution and expect the business analysts to design a complete business solution.
However, the business analyst is stymied in their efforts by the need for IT to transform the solution that they conceptualized into an IT algorithm. Anyone who has written a specification and then later struggled to understand the IT implementation of that same specification knows that this is the critical juncture where the business intent is lost. The business rules movement is all about addressing that disconnect and making it possible for the business analyst to develop a business rules specification and have it loaded into an IT execution environment without it being changed in any way.
What distinguishes business rules from other types of rules is that business rules are built upon a business vocabulary foundation that corresponds directly to concepts that subject matter experts are already accustomed to manipulating. In other words, what makes a business rule special isn’t anything structural about the rule itself. What makes a business rule unique is that it is free of references to non-business domain concepts.
Another sign of the success of the business rules movements is that the marketplace is awash with tools that purport to support rules. These tools run the gamut from business integration platforms, to ETL tools, to office automation applications and finally to business rules engines. While there’s no reason to question that they support some form of rules, it is reasonable to question whether or not these products support business rules. After all, not all rule-based processing is isolated within the business domain. In fact it’s quite common to see rules purely in the IT domain.
The answer isn’t straightforward because there are many cases where business rules could be implemented in these products. The key issue is whether it is appropriate to use these tools for business rules. And if it isn’t then are there any non-business rules that might be appropriate to use them for. The question of appropriateness gets at the core of the business rules movement.
Earlier we discussed that the core issue the business rules movement is focused on is addressing the empowerment of domain experts to create executable business specifications. But defining the boundary of those business specifications can sometimes seem like picking next year’s hot color. After all, when we see something like the following rule we want to have some clear way of saying that it is or isn’t a business rule:
If Mortgage Origination System = BigMortgageSystem and
Conformance Evaluation = Processed
Then
Conformance Step Indicator = Initialized
The answer is that we can’t determine whether or not this is a business rule simply by reading the conditions and actions of the rule. After all, these conditions and actions are identical to what we see in a business or non-business rule. What drives the determination that a rule is a business rule is that all of the terms being reasoned on and the action taken as a result of the conditions in the rule being met, are all concepts that the domain expert would expect to see.
That doesn’t mean that rules aren’t valuable to solve other kinds of problems. In fact that is exactly why rules are embedded in many other tools in the marketplace. These tools typically aim to apply rules to the transformation and enrichment tasks that are purely within the IT realm. These tasks involve things like creating values that are meaningful in the business domain by applying a set of rules against a series of implementation specific fields. This type of work isn’t business rules work because the motivation for this kind of rule is to convert the IT view of the world into a view that corresponds to how the business analyst sees the world. But this is important work since this work creates the basis upon which the vocabulary of business rules is built. But business rules shouldn’t be implemented in these tools because the tools don’t provide a comprehensive capability for developing the business vocabulary that is essential for allowing business specifications to be created, nor do they provide a pathway for integration with other components of the business specification such as business processes.
In the end, what makes something a business rules is that it is written in terms of the concepts a business analyst or business domain expert normally works with. A business rules solution provides the capability of expressing this, along with the ability to integrate with other elements of the business specification including business processes. Mixing business rules with non-business rules is something to avoid because it undermines the business analyst’s ability to specify and control those rules. And by undermining the business analysts control we undermine the ability to achieve the business flexibility and responsiveness that the business rules movement is all about.
