Business Rules & the Software Reuse Debate
Published by Rajgo February 22nd, 2007 in Business Rules, BPM, BRMS, Rule Engine, BRE, Business Rule Engine, Business Rules Management System, Business Rules Codex, ProgrammingI have been discovering some old articles recently. Here is one where Bruce Silver says Don’t Bank on Business Process Reuse.
Why Business Rules are better than Code
Talking of Business Decisions and Business policies, Reuse is certainly possible and very much in demand. I have written earlier about why Business Rules are a better paradigm than code to represent business policies.
That is because Business Policies are never the result of random efforts. They are generally well thought out and structured. Now, where things get cluttered is with implementation.
You would need one hell of a super-programmer to implement all the complex business policies in a structured, clean, maintainable, understandable, bug free and easy-to-change fashion.
Some Usecases for Reuse
When it comes to reuse, it helps to better define what we understand by reuse before we proceed. Reuse could mean any of the following
- Business Policies/Rules required for a business requirement could be similar to an existing policy. For example, multiple Investors in a Mortgage Firm might have different but similar eligibility requirements.
- A Business System being set up in another geographical region might require policies that are similar to the ones employed in another geographical region. For example, the Claims processing rules in the U.K could be similar to the ones being used in Australia.
- The same set of business rules/policy/decisioning service could be used by different application. For example, a Credit Decisioning Service will be used by multiple applications.
Why Business Rules will Deliver
So, having seen what reuse could mean, why are Business Rules a better at making reuse possible. Here is why.
Business Rules are written independent of the application(s). This immediately means that Business Rules evolution, change management can be separated from the Applications Life Cycle.
Business Rules can be written independent of the Data Model. This automatically frees them from any implementation clutches and enables reuse
Business Rule Capture, Business Rule Implementation, Testing, and point of use/integration can all be completely independent of each other.
Business Rules can be classified and captured by functional area. For example, Pricing Rules, Credit Decisioning Rules, Europe 2006 Eligibility Rules, and so on. Add to this the fact that they can be packaged as independent units, reuse becomes far more simpler
Now, when you want to duplicate functional capability in another geographical region, and would like a similar set of rules like the one in your corporate office, you can take the rules and modify them to suit your requirements.
Final Words ..
My take on the reuse debate is this.
- Code/Component Reuse - Possible, and not very complicated
- Solution Reuse - Difficult, Tough
- Business Process Reuse - Very Very Difficult
- Business Architecture Reuse - Very Very Difficult
- Business Policy, Business Decision Reuse - Very Easy with Business Rules Management Systems
4 Responses to “Business Rules & the Software Reuse Debate”
- 1 Pingback on Mar 13th, 2007 at 2:23 pm
I would have to disagree on several levels. I’ve seen plenty of cases where Business Policy was arbitrary and basically random. Just because the same kind of process is used across a business, often times those processes are owned by different divisions. This means sharing isn’t possible due to political issues. I believe that Business rules can be better, but the following has to be met.
1. the business people have to go through training and learn how to think logically.
2. the developers have to take time to understand rule engines, first order logic, rule languages and pattern matching
3. there has to be a clear and concise process for managing rules and the business has to actually follow the process
4. the business has to make a clear decision on which business processes are externalized to business rules and which processes remain in the code. Not all processes belong in a business rule
If you take out any of the 4 requirements, business rules will lead to a gigantic disaster. The biggest problem with using business rules is finding an experience developer, which is considerably harder than finding a good developer. In fact, for most cases I would say using a business rule engine is the wrong choice. I say this because most cases the developers have zero experience, the business people don’t know what they want, the development cycle is too short and there’s no functional requirements.
Under those conditions, coding the business process in code is a better choice. Trying to add a BRE and BRMS to a chaotic sitution makes the situation worse. Since most situations are chaotic, using a rule engine is the wrong choice. by most, i mean more than 50%.
peter lin
Hi Peter,
I am not sure there is any technology that is immune from abuse. Having said that, I can certainly agree with your points. They are all valid.
Here are some points, some additional, some which I have said earlier, to emphasize on business rules technology.
The Business People have to learn to be able to state their rules precisely. But not necessarily to be able to write them as Business Rules to begin with. That will happen later with more experience and maturity.
Business Rules/policies have a business intent, and if programmers find them to be weird and strange, I do not find it surprising. It is this complexity that makes it difficult to write in code.
If you have rules that change rarely, then I see no reason why they should be externalized. But, for rules that change often, externalizing then makes a lot of sense.
Then of course, there is a question of visibility. I was looking at one system recently where most of the rules are written as stored procs. There is no way in the world you can even show any of this to any business manager, even if you want to.
In many cases, business exceptions are discovered later which have to go back into your rules. Here, business rules certainly offers a far cleaner approach.
Rete Rules certainly have a steep learning curve, and developers have to take time to understand how the rule engine works. But I do not see this problem with using Rule Flows. Of course, there are certain rules where you need inferencing. Here, there is no other way.
The case for externalizing and managing business policies using a BRMS is clear. The organization must make the effort to clearly identify what rules to externalize and what not to. Even without a BRMS, I would still advise organizations to undertake this effort, as this will help to understand their own systems.
good points. from my experience, the hardest part about using rules isn’t the technology. It’s the business itself. In many situations the business logic is locked in a stored proc. What’s worse is that you’ll never be able to externalize it due to political reasons. It’s not that you can’t externalize it. It’s the monumental political barriers that prevent it from happening.
large institutions often have dba, data modelers, architects, leads and developers. What goes into the database often is under tight control by the DBA. Getting the business logic out of the database often is close to impossible. If someone tries to apply a BRE to that situation, the problem gets worse. Now, the business logic is in 2 places, stored procs and business rules. Since the dba team won’t let go of the stored procs, there’s no way for the other teams to know what is in those stored procs. Trying to model the business rules correctly becomes an exercise in futility.
at that point, pitching BRMS or BRE is a lost cause. Even if a sales guy convinces the head CTO to use a BRE, it’s never going to fly. I think the solution to the human issue is for the industry to do a better job of educating the public. when i say education, I mean clearly stating the all the negatives along with the benefits. Alot of sales people in the BRMS industry haven’t been up front about the problems. in fact, recently i was on a conference call with a sales guy from a BRMS vendor and he basically claimed everything is possible. Clearly, everything isn’t possible. making such ludicrous claims is bad for the industry.
although rule flows are simpler than understanding inferencing, I would only trust an experience developer to write rules in a rule language. for all other cases, the user should use a constrained editor, which provides just enough flexibility to express rules with low risk. As murphy’s law says, “what can go wrong, will go wrong.” If you give the biz users more freedom and power than they need, you’ll end up getting paged at 3am on saturday night to fix the problem they created.