A major goal of the business rules movement is to capture business rules in ways that express the business logic of the rules, rather than describing the mechanics used to execute them. As Chris Date has put it, business rules should be about "what, not how." A significant problem with this goal is that many IT professionals - perhaps the majority - tend to have mind-sets that think in terms of the "how" of implementing business rules. This seems to be based primarily on the experiences of individuals as programmers, and a view that creating source code by hand is the only way to get things done in practice. Source code is, of course, procedural. That is to say it is a sequence of instructions that a computer will execute, e.g., "first do A, then B, then C and if D is true then do E, otherwise do F."

While procedural source code seems natural to anyone involved in programming, it is very difficult to look at it and determine where one business rule begins and ends. In fact, quite a bit of most source code is concerned with doing things that have nothing to do with business logic, such as setting up an environment for a program to run in. Even if business rules can be discerned, it is difficult to understand what their business significance is, unless the source code is well documented (which is rare). Perhaps as a reaction to all of this there has been a general condemnation of things that are "procedural" in the business rules movement. Yet, these are serious grounds to question whether "procedure" really should stigmatized as something that is in natural opposition to business rules.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access