I had decided to ride my motorcycle to the Business Rules Forum in Las Vegas, a 10-hour hop from the house.  I was filling the bike in Beatty, Nevada, when a stranger stepped up from a shiny sports car and said, "Nice bike.  Basic transportation."  "Eh — thanks," I replied.  I was caught a little flat footed and didn't quite know how to respond.  I had never thought about my bike as being "basic" transportation; after all, it had a satellite radio and a GPS!  However, it did get me thinking, "What really is basic transportation?  What is the minimum requirement for something to be called 'basic transportation'?"  With a two-hour ride into Las Vegas and a straight road this would be good food for thought.

I could argue that a 200 CC dual sport is good basic transportation, but what is the common thread that qualifies transportation to be basic?  Is it reliability? ... low cost? ... comfort (or the lack of comfort)? ... horsepower, or speed?  After 100 miles on the road I came to the conclusion that the common thread is none of these attributes.  The common thread, as it turns out, is not the implementation, but rather the upfront planning that went into the design.  I decided that each bike design does represent basic transportation in filling a specific role.  It is difficult to build any one bike to fit all needs.  If you are going on a long-distance ride, a touring bike is the ticket; for a short hop to and around town, a cruiser is a must-have; and adventure riding demands a good dual sport. 

Our architecture team had a similar conversation last year.  The team was mulling over the questions, "What is the most basic architecture for business logic implementation?  How can we improve our current implementation?"  We were contemplating these questions because our partners on the business side had embraced developing business requirements using a business rules approach.  They had developed a definition for each term and had used only defined terms when writing rules.  Terms that were stored in a database were mapped to the table and column in the design, which left nothing to chance when the requirements were passed to IT.  Associated Fact Model and Process Models were also developed as part of the requirements package.  The resulting delivery to IT was a very clear set of rules divided into logical rule groups and in sequential order, fact models that described the basic business knowledge, and process models that described the work flow.  This business partner truly understood their business and the logic of their rules.  They managed well over 1000 rules in this way and their upfront work was reducing our implementation costs.

 As part of our SOA architecture we had specified a rule engine.  We had a vision of "rules as service" and using the rule engine would be the core component.  The job of the rule engine, in part, was to help meet the business goal of "agile rule management."  Our thought at the time was that this kind of interface would aid in rule change and rule management.  As it turned out, the business involvement in maintaining a business-side repository provided a much better interface in managing rules.  The amount of meta-data needed to accompany each rule could not even begin to be captured in the interface offered by the rule engine.  During this process the business became very interested in and knowledgeable about their business and just wanted the rules (logic) implemented.  They didn't want to be involved in the gritty implementation details and really didn't care how the logic was ultimately implemented. 

So, as the team pondered how we could improve our current implementation, a senior architect asked, "Do we really need a rules engine?"  The three compelling reasons of our decision to buy the rule engine were to provide:

1. Agility in the change process
2. A tool that would sort out the logical order of the rule execution
3. An engine for the 'Rule Service'

After much careful analysis, discussion, and debate, the architecture team concluded that the detailed specification provided by the business eliminated the current need for a rules engine in our architecture.

Alas, we began to look at other architectures for rule implementation.  The SOA environment we had implemented with onboard frameworks provided a host of ways to implement rules while keeping the principles of the business rules approach intact.  New objects called "rule objects" were introduced into the model.  The new objects carried the same name as the implemented rule group defined by the business in their rule repository.  The interaction of the rule groups was managed by process objects and controlled by an Enterprise Service Bus (ESB).  This new approach provided enhanced performance improvements without sacrificing agility or impacting the time required for rule changes.

The change in architecture also yielded a large savings in vendor-related maintenance costs, upgrade issues, and vendor management.  The design change did not impact the business.

A great design is often a simple one.  However, whether simple or complex, the design must be complete in order to be cost-effective when it comes to implementation.  Our business partner taught us this.  Whether designing good basic motorcycles or software specifications, the process has remarkable similarities.  The value is in the design and not in the implementation.

# # #