Bhaskar Sharma of HCL wrote me a little while ago and asked about business rules and the software development life cycle (SDLC). He said that, as of now, they use a normal SDLC approach in which rules are either hard coded or manually written in an xml file with lot of supporting code. He had come across business rules management systems (BRMS) or business rules engines (BRE) (and there are not the same thing) and said that initially there was a poor reception to proposing their use. In particular he asked for my comments on 7 areas of confusion. He and I agreed I would answer these here on my blog so that you could all share and enjoy (and comment). Here they are, his text in italics with my responses. Thanks to Mark Eastwood from our professional services group for his help. For some basic thoughts on why to use business rules, check out this FAQ posting.
In general, many aspects of a traditional SDLC do apply when using business rules. There is “infrastructure” required that must be developed by IT such as glue code and definition of complex rules or rule templates. Once IT has completed this development, users have a way to make changes to the system without going through the usual SDLC, but building the environment to do this requires a proper software process. You do need this second, shorter and simpler process that goes from business requirement to the business user making and testing the change Users can also be allowed to push these into production but most IT departments still want at least a partial release cycle.
This is a little like using a database in the sense that designing the schema is a fairly complex IT process while using a UI to add rows within the constraints of the schema is a user-centric task. Adding a rule is somewhat like adding a row to a table or modifying a particular column of a particular row.
So Bhaskar's questions
- How's my application going to interact with the rule engine
There are as many ways to do this as there are platforms! Most business rules vendors' products (including Fair Isaac's Blaze Advisor), allow you to package up all the rules that go into a business decision and then deploy them as a service, an EJB, a COBOL program, a .NET assembly or whatever makes sense in your environment. Indeed Blaze Advisor let's you do all of these from the same rules. The important thing to remember is that you are defining logical decision services that provide decisions for other services in your application. You don't need to use SOA to do this but you do need to think about the business decisions you are automating. - For a application of moderate size e.g. 40 man months, will it be beneficial to go for a BRE
Yes. If it meets at least one of 5 basic conditions - there are a lot of rules, the rules change often, the rules are complex, the rules require deep domain expertise to understand, or the business has explicitly requested control over the rules. Small projects work (I know of happy customers with 30-50 rules) and large ones work (75,000 rules+). - How does it impact maintainability and enhancements in the future
We have customers who have made 30-40 significant changes to their rules and made those changes to their production systems without using any IT resources. We have customers who have reduced application maintenance teams from 50 to 5. Maintenance reductions of up to 80% are well documented and Gartner has said that adopting rules can result in a 5-40% reduction in maintenance costs. Business rules allows for more rapid, more agile changes with less IT resources. There are some case studies on the blog. - What will be the performance impact as we are adding an extra layer with xml behind it.
It seems to me that you are worried that an XML repository will slow things down. However the rules are compiled into memory and interpreted much like Java source is compiled into byte code and then interpreted by the JVM. Some applications will run faster, other’s maybe not, but rarely slower. Part of this is the efficiency of the algorithms like Rete III for selecting rules when there are many possible rules. Business rules can frequently knock down the number of rules by an order of magnitude or more making it more efficient to execute and to maintain. - How costly it is and for how big an application should I go for it
It doesn’t have to be too costly - relatively small rule services can be built very quickly and cheaply and provide a nice ROI. There are some open source rules products and commercial products that are cheaper, but even the best products can be adopted for $50,000 - $100,000 for small projects. - Do I need to write some extra code or buy something else to test the application built on top of BRE.
Business Rules Management Systems generally contain extensive testing and debugging tools and these are becoming progressively more extensive, handling scenarios and regression test for instance. Some customers write a custom test harness and some use nUnit very effectively for testing. - What is the learning curve of an developer and again, taking this into consideration, for how big (in terms of man month) applications should we go for it
The training classes are short, but that’s not the question. Its like many other things such as the first time someone developed with .NET or Java - it depends, but its not overnight. Maybe 2 or 3 months, given that you realize there are different levels of proficiency. Projects of any moderate size (40 man months for instance), typically find that they recover the learning time in shortened development provided they get some support. Subsequent projects show a real return. Also, not every developer will be focused on rules, some will still work on "code".
That's it, hope that helps. There some more on rules and RUP and on rules and agile as well as a conversation with Scott Ambler about agile.
