Speeding up your projects & defeating complexity with Business Rules
Published by Rajgo November 27th, 2006 in Business Rules, Business Rule Engine, Business Rules Management System, Business AgilityI came across this post from this brand new blog on using the Business Rules aproach to defeat IT system complexity.
The post itself is a long and nice post documenting all the advantages of a BRMS that I have been talking about including visibility, ease of change. It is a good read!
But, there was this line that caught my eye .
Following the Business Rules Approach does not save money up front, but is only felt on the long term.
In other words, if you are consultant, and have been tasked with building the aforementioned DVD rental system, taking Business Rules Approach (especially if you’ve never done it before), will not improve your time to completion, and will likely increase the amount of time it takes to implement the system.
Now, I am not sure I agree with the fact that the business rules approach will mean more time towards completion or even the same time. The first project using a Business Rules approach may take time because it is new technology. Even that is a may be and depends on the complexity of the business rules involved.
Talking about the mortgage loan scenario that the author takes up in his post, I would say that capturing the pages and pages of eligibility criteria and underwriting rules using a Business Rules Management system will take far less time for a business analyst or a analyst, developer combination than attempting to implement it in code.
Using a Business Rules approach makes it easier to test the rules independently. Also, many rules would be just too complicated to implement in code.
I even wrote a customer story on this sometime back.
To summarize why I think the business rules approach will be faster in those projects where a lot of business rules will have to be captured and enforced by the system
- BRMS allows you to capture & categorize rules. So, working with large sets of rules becomes immediately easier.
- BRMS allow you to see the rules directly, even debug them. So, mistakes will be limited
- Once taught how to do so, a business analyst can create the rules without an underlying object model and test it, and then IT can map the business terms used in the rules to a programming model. You will make less errors this way.
- BRMS offer many different rule formats that allow for capturing different kinds of rules (If The independent, decision tables, flow rules etc). Rules are represented in a most natural way.
- Using a BRMS allows you to concurrently build your rules and the application. Rule development & system development can actually go in parallel.
Of course, business rules can be reused, so over time, the effort to implement a similar project will be dramatically lesser. And of course, rules can be changed easily and rule engines can be used to output rule execution audit information.
For example, I have seen that to add a new investor in a mortgage company, it take 2-3 weeks Only.
The post author also comes to a similar conclusion as seen from this excerpt.
Of course all of these costs would be recuperated several times over once demands emerge to change the rules, or analyze the rules behavior.
The use of business rules to manage “Change Time” is key but it must be remembered that most of the life of a system is in Change time….
Check out http://www.edmblog.com/weblog/2005/09/get_set_for_cha.html and http://www.edmblog.com/weblog/2006/03/chchchchanging.html.
I wrote the original blog entry, and based it on my own experiences architecting the framework to support dozens of promotions and campaigns at a large Canadian telecom/satellite provider. You might say I learned about the BRA the hard way.
While I agree that it is certainly possible to meet the same timetables with the BRA, and even eventually reduce the time to completion. My target audience when writing this blog entry are people who are not entirely familiar with the BRA. As such, I want to manage their expectations when implementing the BRA for the first time, as I believe the majority of the value of the BRA still exists even when project timelines are pushed out. In other words, I would not like to see the BRA neophyte scared away for the first time because their project schedules got delayed a bit, so I decided to emphasize the post-implementation benefits.
Quite frankly, when talking about IT costs, I feel that talking about the post-implementation benefits is more relevant since this is where most project costs are tied to. Unfortunately, the post-implementation world has not caught the popular imagination in the same way that direct project costs have. There are a lot of IT consultants out there will brag about how great their projects went, and how happy the client was when they “completed” it. Most of these projects are just “greenfield” projects whose true complexity is not well understood until support has to open the hood to fix or change them.
To conclude, I feel your criticisms are 100% valid, and in the name of fairness will post a shorter follow-up piece on my blog to clarify this.