Earlier this week I posted Application Development 2.0 in which I addressed what I see as some of the issues with current development practices and tried to explain why I think a declarative, business rules approach is essential. This (and some blog posts around the blogosphere) made me think about the mismatch I see when talking to Architects – most have heard of business rules, few use them. Part of the challenge, I think, is that those of us who “believe” are perceived as fringe thinkers. It is easy to see why – we must a fringe as everyone else is writing procedural logic! Beyond this, though, are serious questions about business rules:
- What are the benefits that justify the additional investment?
- Why wouldn’t I just code the rules?
- Will the rules perform, integrate and “play nice” with the rest of my system?
and so on. When asked why he believes, Chris Berg of ILOG listed Encapsulation, Simplicity, Visibility, Collaboration and Shared Execution (SOA) as the reasons to believe in BRE. In a post on my ebizQ blog recently I listed a similar set of reasons:
- The separation of decision logic from mechanical implementation gives you more flexibility to make changes with minimal or zero impact on basic systems operation.
- Business rules are more understandable to business-level people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
- Business rules are easily segmented into groups for control over functional interaction and management.
- Business rules management systems have interactive testing, execution flow, cross-reference tools, and reporting features to aid in development, testing, and documentation.
- Business rules management systems have predefined rule replacement features to handle system updates without interrupting service to application users.
- Business rules can have explicit times and dates when they should go into and out of effect.
- Rule management templates can be created to let users update, view, or create rules in a controlled manner.
- The rule engine can quickly look through large sets of rules, finding the proper ones to apply based on case-specific conditions.
Now, there are those who believe that the purpose of business rules is replacing developers with business people – development without developers. I am not one of these people as I believe the value in business rules is in allowing collaboration between two groups with different, but valid perspectives. Yet this difference of perspective often results in serious problems when developing complex systems. Business users are at the mercy of regulations, court rulings and business policies that must be enforced. They must also respond to an ever-changing business and competitive environment. This often means they can’t stabilize their requirements or explain them easily to developers – legal or business jargon does not always map well to Java code! Meanwhile the developers typically don’t understand the regulations or business environment well enough and so can’t develop necessary applications, systems and updates fast enough. As an Illustration let’s take the example of a healthcare benefits system designed to who is eligible for what. First, the business Perspective
The system needs to implement Federal and State regulations – most states have their own and these are applied sometimes to employees based on the state in which they live and sometimes to the state in which the employer is based and sometimes both. Additional rules and policies are imposed by plans, with every plan being different and often plans have different rules by state. Of course many of these rules have been the subject of court interpretations and any of them could be rescinded or altered at any moment by a legislature or court. In addition, we want to offer maximum contract flexibility for employers – we want to be able to let them make benefits contingent on almost anything that is legal and to change these rules whenever they want, though mostly in time for the main benefits election period. After that it gets complicated as we need to certify that we are enforcing all these rules and no-one on the team reads Java or understands XML etc…
IT Perspective
Well all these Federal and State regulations – sure, but how are we meant to keep up with them or read the legal jargon? If we don’t then we rely on the business to keep us informed. But they can’t explain them accurately enough for us to write code against them and none of them can read the code we right anyway making it impossible to verify it. We’ve tried developing test cases but there is an exponential growth in these as we add states and plans and anyway, often no-one knows how a case will turn out until they apply all the rules making it hard to develop test cases. If this wasn’t enough, the plans’ descriptions are full of healthcare terms and legal-speak that is outside our domain. As for this idea of allowing unlimited flexibility for the plans, that’s crazy. They have to limit the number of things that can be used to make decisions and the types of decisions that can be made so we can build some kind of configuration tool. Even then it is going to take a while to add a new plan to the system and we had better get some serious notice for any changes to the regulations…
Two perspectives, one problem, one solution – business rules. Using a business rules management system to manage the decision logic in a system means:
-
Business users don’t need to manage objects, interface to existing systems, package up and deploy working code – IT still owns this process
-
IT can write technically complex rules in a syntax that business users can validate
-
Knowledgeable users can write regulations as rules using a simple, English-like syntax
-
IT can develop templates to constrain rules that business users want to change – templates prevent problems but allow for a high degree of flexibility
-
IT can do architectural design, integration etc. ensuring that the resulting application can be supported and integrated easily
-
Business user rule maintenance frees up future development time that would be tied up with system updates
In fact, business rules offer as much to developers (perhaps) as to business people. By allowing non-technical folks to collaborate, developers will find it easier to build applications that make their users happy and so increase the rate of positive feedback. By pushing the nits of maintenance to the business users they will find more time to work on “cool” stuff.
This post was prompted by a number of posts I saw today:
- The Holy Grail – Application Development without Developers
- I Want To Believe Redux
- Business Rules Engine – I WANT TO BELIEVE
Comments on this entry are closed.
What you call “business rules” I call “programming”. The example you just gave about the healthcare company is complex enough that I think it would warrant a developer that learns the business domain well enough to code and change the code when needed.
I’m not saying there’s not a place for a configurable “rules” engine in certain situations, but I think these have to be relatively simple.
I have certainly seen companies where business rules are used as a declarative programming language used by domain-expert programmers but I still think it is unreasonable to expect a programmer to know the business domain well AND be able to read the regulations AND understand the process implications of court rulings etc etc. Many business people will be needed to do that (not 1) and so expecting the programmer to know all this and be able to code seems unreasonable to me.
If I was feeling cheeky I might point out that the huge number of failed projects, especially those with complex rules, at least suggests that a different approach would be worth trying….