Business logic in a hurry

How to get business experts to play in the IT sandbox

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;
}
else
{
  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;
}
annars
{
  om ( postförskott )
  {
    sändningkosta = 9;
  }
  annars
  {
    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.

1 2 Page 1
Page 1 of 2