Much of the interest in business rules stems from the desire to be able to quickly configure components of applications without the need for programmer intervention. Commercially available business rules engines are already able to do this to varying degrees, and special purpose rules engine functionality is increasingly being built into specific applications to make them more flexible. Even so, increasing the efficiency of building applications is only one of the benefits of adopting business rules approaches. Another very important potential benefit is the ability to understand the logic that exists within applications. This is something that at first glance may seem a little remote from business rules approaches, but in reality it is very closely linked to them, both as a direct benefit and a potential trap.

Why Black Boxes Exist

Studies have shown that programmers spend an excessive amount of time reverse-engineering applications so that they can understand them in order to make changes, fix bugs and integrate data with other applications. Some studies indicate that programmers spend over 40 percent of their time in reverse-engineering, and my own personal experience suggests that this figure may be an underestimate.  The reasons why so much reverse-engineering goes on are well known: documentation is nearly always incomplete, outdated or untrustworthy. Documentation really means the specification of how an application works but which is produced after the application is built. At the point in time that an application goes live, there is no immediate need for a specification and so no return on the very large investment that is needed to produce the specification. Indeed, developers are usually so busy just before an application goes live that there are hardly ever resources available to produce adequate documentation. The result is that nearly all applications are black boxes whose inner workings are unknown.

Can Rules Help?

Business rules approaches require that rules be declared before they can be executed. This is the exact opposite of the usual way in which applications are developed. Where programmers handcraft source code, there is a complex and diverse set of ways in which the programmers learn what the program logic is supposed to do. It is rarely driven from a single specification where rules are declared, and it inevitably involves cycles of iteration in which different layers of code are built to implement each component of the application.

At a minimum, business rules approaches result in the declaration of business rules. Some business rules tools and techniques focus on this aspect alone and do not go as far as executing the rules. Yet, just understanding what rules exist and what dependencies exist between the rules is a huge advance on the typical black box application. When going into a black box and hunting around in source code it is difficult to figure out where one rule ends and another begins, and dependent rules may be located in widely different areas of source code, making them difficult or even impossible to find.

The Black Box Trap

While business rules approaches have such promise in the area of making application logic transparent, there can be an important downside. Because business rules engines, in particular, decrease the need for traditional handcrafted source code, users do not have an IT partner they may have relied on in the past for problem resolution. A business community that adopts a rules engine, declare the rules and then worries about whether everything is functioning correctly may suddenly feel very isolated. There is no dedicated programming team to call up and put on the problem. The providers of the rules engine software – whether they be in house or external – can all too easily say that the engine will do whatever the users have told it to do. The prospect of being put in such a position can strike real fear into business users and may be a reason for them avoiding rules engines.

A business rules engine must never be a black box from a user’s viewpoint. Every user must be able to see and understand its inner workings. This means more than being able to see reports of declared rules and their dependencies. It means that when a rule fires, the users must be able to follow the flow of what happens in as much detail as possible. In particular, they must be able to see what data is input to a rule, what database records a rule touches in any way and what data a rule outputs. Loss of intermediate results is always a concern and inevitably means that the rules engine becomes a black box. This can happen if rules are not really atomic because they really consist of two or more rules. A rules engine can also become a black box if rules fire that do not lead to results that are stored in a database. For instance, if a rule is a constraint the result of its evaluation may not be stored. It is then very difficult to determine what the rule did when it fired. When I have built rules engine components, I have always tried to build rule types so that every rule returns a result that is stored. In this way it is possible to track what rules have fired and what they did when they fired. 

Business rules approaches provide a strategy for getting out of the black box problem that afflicts so much of today’s IT infrastructures. However, business rules engines in particular have the potential to create a different kind of black box problem. Anyone thinking about implementing rules technology needs to ensure that they are not getting out of one kind of black box just to get into another.