There is the world as we see it and the world that could be. Imagining how is critical. If you can’t agree on a premise, then it’s hard to move forward in any direction. One is stuck in the question “why are we doing this?” Such has been the case in a blog I have been following entitled “I Want To Believe”. In addition, at TechEd this year I met several industrious architects that implemented their own rules “engines” on the .NET platform. This Blog and these engineers I spoke with seemed to be grappling with similar questions but from slightly different angles. In general, the question is the following: “How does one identify the tipping point for justifying a BRMS?” The answer is not elusive, however it may not be the same for everyone as you would expect. Consider the following evolution of a fictitious solution.

Simple Encapsulation
Most architects can imagine the need to refactor their code and encapsulate their logic into a single location. Imagine that our fictitious architect George has completed a code review of a new but growing code base and has noticed that there were far too many “If/Then” blocks in the presentation tier. So he gathered the troops and offered that these blocks of code should be wrapped by a single library and enforced with a contract using an Interface. This pattern, along with an existing investment in a model, solved the problem of centralized management from a code perspective. The “If/Then” blocks could not be fully removed from the presentation tier, but they did not bloat as the number of rules grew.

Hot Deployment
Now that the rules were in one spot, George realized that the code in the new library was changing faster than he expected and the BAs on the team wanted to see immediate changes. This issue alone was forcing many interim builds. His solution was to place a wrapper around the library and dynamically load it at run-time—problem solved. Now a new library could be deployed at run time by doing a simple file copy.

Services
Success breeds more success. Another project George was active on needed the same solution and rule content as well. He pulled out the latest SOA framework from his toolbox, refactored the existing code and was now able to share the logic. With the service he added a logger and implemented unit testing for decision regressions. It worked as expected and performed really well.

Many Decisions Many Masters
Over time, several more applications were deployed all re-using the decisions from the SOA solution he had implemented. However, now there were 70 different end points, at least 15 different contracts, and several business analysts and developers requiring changes on a standard schedule. Of the 70 end points, many were duplicates. They had to support versioned services for various applications in production and pilot new ones.

A small team had to be spun-up to mange the “Rule Server”, manage regression and work with system administrators to deploy the supporting libraries. Business analysts were supporting the effort by providing requirements documents. Most of the support time was being taken by the requirements process and not deployment.

The Technical Business Analyst
To lighten the load of the developers, George was able to recruit a full-time analyst to take on the task of working with other business analysts. He also invested in some templates for the requirements process that he knew he could later convert to code and compile later. What he really wanted to do was provide a lighter-weight macro language that the BA could use for expressing rules, but in the end had to teach the BA basic 4GL logic and flow constructs along with object references—something he could do once but probably not replicate since its nearly impossible to find a BA with skills that reach this level of technical acumen or tolerance.

Perhaps you can imagine now many other pressure points exist such as the number of rules under management, the algorithmic complexity of the rules themselves, versioning, a simple rule expression that a BA can understand along with an environment for them, tooling for system administrators, monitoring and the like. In fact it’s the pressure points around collaboration and scaling up the dimensions of a solution that often force the tipping point. And frankly, these are not even the business arguments—these are stated from the perspective of the architect. Some wait until the pain is there while others plan ahead for success.

In short, the need for BRMS is real and present—one simply needs to see the horizon.

Here is the URL to the original “I Want To Believe” blog post.
CCB

Posted by Chris Berg in Rules for .NET. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.