We have probably all experienced this scenario: At the end of a project, the customer comes up with more new demands for the system that have not been previously created or were only incompletely formulated. Depending on the extent of necessary adjustments, these new requirements may exceed the planned budget and cause those involved to be at loggerheads about who is to bear the cost.

One reason why projects often gradually veer off track is because business experts are not effectively involved. To use a metaphor implied in this subtext: Programmers and architects meet in the IT sandbox to build a castle together, thereby forgetting the business expert on the swing. And because the business expert isn't allowed to play in the sandbox, he doesn't like the sandcastle. This is rather unfortunate if the business expert paid for the outing. So let's consider how we can get business experts involved in our sandcastles without muddying up the end result.

Identify hot spots

The most important safeguard against the risk of specification creep, the emergence of more and more demands at the end of a project, is comprehensive specification of the project's subject matter. We can't blame the business experts for not imbibing in documentation and specification along with their mother's milk, so we need a clear idea how to extract from them the information necessary to our project. In addition, different goals can conflict when writing the specification. Time and effort well spent with the specification may reduce the risk of extra costs at the end of a project, but it is an investment of its own right and must be accounted for. Pure monetary investment is not the only issue; the parties involved in the process produce their own challenges: the cell of technology-resistant employees, the able-minded consultant mainly interested in invoice-vindication, an extremely cooperative but perhaps incompetent project leader. Let's at least nail down that cell of technology-resistant employees by adopting the ancient Arabian proverb, "If the camel once get his nose in the tent, his body will follow".

Figure 1. Conflict of goals between specification benefit and cost

Specification intensity

Not all parts of a system are equally susceptible to specification creep. It is therefore essential to identify those parts of the system that present a high risk of extra cost due to inadequate documentation. One important index for this is specification intensity, which I casually define as the ratio of time and effort spent on the specification versus that invested in implementation. A system's specification-intensive part is one that requires a relatively large amount of programming for relatively little documentation.

Let's use the following requirement as an example: "Port existing data and procedures to the new XYZ database server, improve performance." This requirement could comprehensively describe a project phase lasting several weeks. But what about the requirement, "If the customer buys 10 items, shipping is free"? This requirement has a high specification intensity, every word corresponding almost 1:1 to some code.

Typical examples for specification-intensive components are:

  • Rate and premium calculations for highly individualized products
  • Application processing in public facilities, insurance companies, and banks
  • Complex selections of specific records from a data model
  • Workflow and process descriptions

Information loss and delayed feedback

Another indicator of a risky area is the number of hops a requirement must take before being implemented as source code. By hop, I mean a transfer of information between people or media. The best case is three hops: from the head of the business expert to the specification, from the specification to the head of the developer, from the head of the developer to the source code. Each hop runs a double risk: the danger of information loss and delays in feedback increase with each hop. In short: the farther away a business expert is from the programmer, the worse things are. What counts is not just the spatial distance, but more importantly, the technical, linguistic, or human distance.

Figure 2. The more hops between brain and implementation, the greater the risk for misunderstandings. Click on thumbnail to view full-sized image.

We should thus analyze the potential system for specification-intensive parts and for large distances between the business experts doing the describing and the developers doing the programming. In those project sections, we want the business experts to be involved in construction as much as possible, because every change in the specification is directly reflected in the source code, and the possibility of misunderstanding is at its greatest.

If these parts of a specification get bogged down in source code, the business expert will find it difficult to "just make a few quick changes." The client, usually not particularly keen on documentation, will often undertake a closer inspection of the specification-intensive parts at the project's end—quite possibly for the first time—during the start-up phase for the system's production use. And he normally tends to expect that simple, uncomplicated changes are also simple and uncomplicated to implement.

That's all well and good. But how can we help the business expert jump in and succeed in a game that we have been playing well for many years? We need a sandbox where business experts can specify and build their domain-specific logic, without caving in our fine IT sandcastle. We need a development environment for business logic that is suitable for business experts and has material artifacts that seamlessly fit into our architecture.

Even if the business expert doesn't make the specification herself, such a simplified development environment serves well as a common "communications platform." Sometimes it is necessary to verify and ensure that a specification has actually been implemented 1:1 as requested. Often, the client has her heart set on sensitive calculations and workflows, calculations that carry a risk of financial and legal consequences if an unexpected result occurs.

If, for example, a bank wants to automatically check whether all parties to a transaction are creditworthy, even the smallest of errors in implementing the specification may cause grave problems. Imagine you are the responsible project manager; would you like to admit that, yes, an unsecured loan for an embarrassingly high amount was approved due to a tiny dangling else, and that, alas, the bug will be fixed in the coming release?

Proposing a dedicated development environment for domain experts

A solution to our sandbox problem would directly generate executables from the customer specification. In consequence, that would mean using a formal specification language. That language should be understandable enough to the common business-expert user and/or managing directors, at least for information purposes, but powerful enough to be able to describe all requirements in detail. The approach of using such a domain-specific language may sound familiar to you. Does the term model-driven development ring a bell? See Resources for more information.

Let's imagine the following specification IDE:

  • Thanks to an intuitive and easy UI, a business-expert user can use the IDE without much training
  • The resulting specification format is so beautiful and self-explanatory that you feel the urge to print it out and use it as wallpaper
  • You can thoroughly test the specification in an isolated test environment
  • When all is said and done, it generates source code that neither James Gosling nor Bjarne Stroustrup could have written better

Fortunately, we're not alone in devising these good ideas. A small, but fine suite of tools called business rules systems attempts to satisfy these criteria. Alternative terms in this context are rule technology, rule engines, business rules technology, and business rules management systems. These tools assist in easily formulating business logic, business rules, and their application to the data and structures of a software system.

Why use such a business rules system and not one of the popular specification environments à la Unified Modeling Language (UML) and model-driven architecture (MDA)? Well, I have tried such environments and have come to the conclusion that UML is fine for most developers, but a hardship to any domain expert. Popular UML/MDA development environments claim to be able to comprehensively describe a system from top to bottom. The power of the "language" of such an application is tremendous. Thus, the business-expert user finds no sandbox where he can model his rules in such a tool, and yes, this may even be a real challenge to a well-trained computer scientist.

Letting the business expert play along...

This section describes the typical problems that arise during the implementation of a simple, concrete specification and how a business rules system (or some similar approach) may justify the effort necessary to include such an approach in an architecture.

A mini use case

Imagine the following case: As part of specifying an Internet shopping portal, we have identified the calculation of shipping costs for a given order as specification-intensive and we want to place it directly in the customer's hands for specification. Let's assume we have an Order class in this system that possesses the properties Shipping, Cod, and Total. In the finished system, Shipping should, according to the customer specification, result from a given combination of Total and Cod.

In Java, this class could look something like this:


package com.biz.money;

public class Order { double total; boolean cod;

public double getTotal() { return total; } public void setTotal( double total ) { this.total = total; } public boolean getCod() { return cod; } public void setCod( boolean cod ) { this.cod = cod; }

public double getShipping() { double shipping; // Here we want the grand Shipping Cost Calculation Logic (SCCL) return shipping; } }

Decoupling business logic

The customer specifies the following shipping calculation: If the total cost of all ordered items is more than US00, we do not charge for shipping. Between 00 and 00, we charge , with COD at . In all other cases, shipping is 0 plus an extra for COD orders.

In Java, the resulting implementation may look like follows:

 if (total > 200)
  shipping = 0;
else if (100 < total <= 200)
  shipping = cod?9:5;
  shipping = cod?10:15;

The above few lines constitute the shipping cost calculation logic, which I refer to as SCCL. And even in this simple form, the code already makes some assumptions about the later implementation: total, cod, and shipping must be primitive instances of their respective types.

Worse, once we add the above lines to the class Order, we mix up the class's infrastructural code with the SCCL. Whenever the specification changes, we must search for the appropriate code fragment. And when we change it, as good developers, we must also check and test the infrastructural logic again.

A simple, yet practicable solution would extract the above few lines into a static method of a BusinessLogic class, into which we could sum up further business-related code. That would decouple the SCCL from the Order code, while maintaining a navigable link to Order.getShipping().

A more sophisticated approach would, of course, invoke the artifacts of a business rules system from within the method Order.getShipping(). My point is that it feels good to decouple the more infrastructural code from the business-related code, and it makes sense.

Introducing a common language

When cooperating with business experts, we may overstrain them with the above code snippet. Imagine your business experts are representatives of a Swedish reindeer breeder association; you wouldn't expect them to be comfortable with the acronym COD nor with the semantics of the conditional operator x?y:z. You may prefer to provide Swedish aliases and a simpler language to model with:

 om ( belopp > 200 )
  sändningkosta = 0;
  om ( postförskott )
    sändningkosta = 9;
    sändningkosta = 5;
// etc.

Okay, a developer not familiar with the Swedish language will be at a loss. I am too. But an exclusively Swedish non-technician may, for the first time in this article, understand something.

Basically, the logic remains the same—it only introduces some internationalized aliases for the identifiers and keywords used within the original code. By keeping a simple dictionary, we may transform the code from the above Swedenjava representation to a regular Java code snippet and vice versa.

Hence, a good approach allows you to use words and symbols familiar to the domain expert, and keeps the firmly linked domain-specific language firmly linked to the technical identifiers and constructs within the implementation. By installing the domain expert lingo into the development process, we introduce a sort of "common language interface" for specification purposes.

Page 2 of 2

Iron out implementation-level details

Let's assume we have isolated the SCCL code from the rest of the Order class. But what if we now want to apply the same logic to a different environment? To an environment other than the original Order class? Imagine we refactor the Order class and change the type of the properties shipping and total from double to java.math.BigDecimal. All of a sudden, the code derived from the SCCL would involve calling some methods specific to java.math.BigDecimal:

 if ( total.compareTo( BigDecimal.valueOf( 200 ) == -1 ) )
  // ...

Bugger. Does -1 now mean that total is less than, less than or equal to, or greater than or equal to 200? And did you know that the method BigDecimal.equals only compares the raw, unscaled integer part of the BigDecimal instance? No? Then you may be in for a treat when comparing 1.5 and 1.50—which is, strictly speaking, 15 scaled by 1 and 150 scaled by 2, and thus unequal. Business logic like that is bad news.

To keep the condition total > 200 as clear as possible, we need an interpreter or code generator that irons out equivalent applications of an operator to a variable type or another. Take, for example, a script language like Groovy. Groovy uses the Java Reflection API to correctly apply any operator at runtime. Such a language may enable you to specify a logic that can be applied to multiple environments; it would iron out the implementation-level details of the actual Java type of total.

Every business rules modeling tool offers its own suite of possibilities to model logic: decision tables, a graphical modeling language, or some other lingo. It does so to keep the business logic free of any implementation details.

Test, debug, and document business logic

Once our business logic is completely independent from a specific (Java) implementation, we can use a completely different development environment for testing, debugging, and documentation purposes.

For example, we want to debug modeled logic using some dummy input—not as a Java program, but within a simplified debugging environment. To secure the fruits of debugging, we want to formulate JUnit-like regression tests. I daresay the possibilities of testing and debugging business logic on an abstract level is the most important feature of a business rules system. It allows the domain expert to develop within the boundaries set by a given environment (e.g., "total" and "cod," as in the SCCL example) and within his domain expertise.

The screenshot below shows a sample debugger session within a graphical business logic modeling tool. The displayed logic is similar to the SCCL example.

Figure 3. A business logic debugger helps troubleshooting. Click on thumbnail to view full-sized image.

Managing and monitoring rules

A further aspect covered by business rules systems is the ability to manage and monitor a set of rules at modeling-time or at runtime. The system may (among other tasks):

  • Create comprehensive statistics about the rule execution
  • Allow the definition of principals and authorizations
  • Allow transaction management
  • Hot-swap/hot-deploy rules

Here, such functionality depends on the necessities of a given project and how much complexity is required.

One of the most requested and complicated features of a business rules system is support for versioning the business logic. Versioning? While the surrounding system may stay the same (the above Order class), the shipping cost logic may change. Here several questions arise: When should the modified version of the SCCL become operative? Which version of the SCCL was applied for a given order in the past? What shall we do if a given customer has negotiated an individual agreement concerning shipping costs? And so on.

The management of versions and variants of logic (where a variant would be "shipping costs as agreed with customer x") is what I would call the frontier of the business rules system market. While most tools try to tackle the challenge with some approach or another, I haven't seen a convincing off-the-shelf solution for versioning yet.

A quick market survey

You can classify the business rules systems basically into two categories: tools that support rules in the sense of the Rete algorithm (Rete-class tools) and business rules modeling tools (modeling-class tools). Rete-class tools have an engine that can sort out how to apply a set of arbitrary rules on a given data model. Java Specification Request 94 (Java Rule Engine API), for example, is about Rete-class tools. The buzzword complex event modeling is used within the context of these tools. Typical "strict" rule engines are Jess and Drools. Yes, you may cover the aforementioned challenges using a Rete-class tool, but it usually has a strong inherent complexity not easily mastered by either the integrating developer or business expert.

The modeling class of tools is more clearly like the development environment we have drafted in the sections before. Such a tool will consist of a more or less comfortable set of editors, produce some sort of executable artifacts, and provide a runtime environment. Within the modeling class, we can distinguish between tools that use a dedicated server for deployment, like ILOG JRules, and tools that create code for integration at build/compilation-time, like visual rules.


Business rules systems may offer the possibility of more closely integrating business experts in the software development process. With such a system, you can set up a sandbox for business experts within which domain-specific logic can be modeled. Through the use of a code generator or some interpreter facility, the logic stands on equal footing next to normally programmed components. A business rules system adds many interesting features to easy logic modeling, such as testing, automated documenting, and debugging a modeled rule.

The introduction of a business rules system initially takes some time and effort. It is therefore imperative to determine at the run-up to a software project where the use of a business rules system is worthwhile. Indicators for worthwhile use are the criteria of high specification intensity and the spatial, technical, or project-related distance between business experts and programmers.

The benefit of a business rules system lies in an improved (because formalized) communication between the development department and other departments, reducing the risk of misunderstandings and undesirable developments in a software project. Another nifty feature: Even after release, the business expert can influence certain aspects of the completed system within the sandbox created for him. Once introduced in a project, the benefits of such a system act as a central theme throughout the entire development cycle. Experience shows that word about the "easy" approach to modeling (or visual rules graphic modeling) quickly spreads throughout the departments involved in the project and is well accepted. Remember the Arabian proverb with the camel mentioned above? You'll quickly have him in the tent...

Samuel Michaelis works as a principal software engineer at Innovations Softwaretechnologie, a software company located near Lake Constance in the wild, wild south of Germany. He wrote his first assembler program 13 years ago and has never quite recovered from that experience. Today he is knee-deep into Java as a Sun Certified Enterprise Architect and as part of the team developing the business rules modeling tool visual rules.

Learn more about this topic