Enterprise Initiatives

This blog focuses on Enterprise IT topics such as Enterprise Architecture, Portfolio Management, Change Management, Business Process Management, and recaps various technology events and news.


If you have been following my blog recently you would have seen my previous posts that discuss the benefits of the various layers of the stack (mashups, data services, business processes). Although many IT folks talk about the benefits of SOA in terms of code reuse, the real benefit is in the ability for IT to adapt their systems at the speed that the business is changing. One of the best ways to accomplish this feat is to put tools in the hands of the business to empower them to dynamically alter the business rules as they change in real time.

In the old days we built systems with rigid rules and users were forced to adopt to the "laws of the system". Today, users are king and they expect systems to adapt to the way they need to use them. In order to satisfy today's tech savvy users we must build dynamic and customizable systems. We also need to make sure that IT does not become a bottle neck and hinder the rate of change that occurs within the business. The answer is simple, abstract the business rules into its own layer within the architecture and empower your users with the appropriate permissions to make the necessary changes in a timely manner.

Let's discuss the following order process example that I used in the post about business processes.



Now what if we had different rules on what a good credit score is? What if those rules were dynamic? Do we want to hard code these rules in the system and accept change requests from the business to every time they change or would we rather abstract them and give the business a tool to change them as needed? I'll vote for the later! Here is the same business process integrated with a business rule engine (BRE).



Here is a simple example of how the business can set up rules to apply different criteria to different customers.



In this example you can see that Gold customers get special treatment and will be allowed to proceed regardless of their credit score. Other tiers have higher standards applied to them. Now let's say that due to the credit crisis the company decides to apply stricter criteria on their customers and raise the minimum at each level by 20 points. The business can simply make these changes from the business rules engine interface which is most likely done from a browser. If the company wanted to add a Platinum user type, they simply add a record to the customer type table and the appropriate rule for Platinum customers in the BRE. Done! No change request, no priority setting, no change control board, no development, no testing, no rollout!

I also used a callout to point to a business rule lookup at the fulfillment process. Let's say that our company is an eCommerce seller for many different wholesalers. We may sell books, music, appliances, clothes, etc. but we are simply the middle man and don't own the inventory. Instead we sell, take a cut, and trigger transactions to the appropriate wholesaler for distribution. Each wholesaler has a unique set of business rules for their fulfillment process. In addition, we may add and remove wholesalers several times during the year. We have a standard business process for dealing with fulfillment but different wholesalers may have different rules due to industry specific or geographic requirements (age limitations, state laws, tax rules, etc.). Once again, an appropriate business person with the proper permissions should be able to make these changes as necessary without having to deal with IT.

Business rules have their place and purpose but they also come with some baggage. Like any other layer within the architecture, business rules need to be administered, maintained, and governed. Business rules need some level of change control, backup/recovery, and auditing like any other artifact. Most BREs either provide that functionality as well or hook up with other tools that manage artifacts (CMDBs, governance tools, etc.). But business rules are only worth the hassle if the business environment is dynamic. If the rules are static in nature, it is probably not worth the effort from an architectural stand point to create an abstract business rules layer complete with the appropriate security, auditing capabilities, etc.

The higher up the stack we go the more opportunities we create for the business to become agile. Business Rules create the ultimate flexibility and agility that most of today's businesses require. Implementing a BRE in your SOA is another great step towards IT becoming an enabler instead of a cost center!

3 comments

  1. Anonymous  

    Hi Mike – I just discovered your blog and I see you’ve got plenty of rich material so I’ll look forward to keeping up with your posts. I glad you finished this article off with some note about assessing the value of customisable rules and degrees of abstraction. This can be a trap for the budding agile team – when they get bogged down in debating what if anything needs to be customisable and what degree of abstraction is just right for the application to hand.

    This is often mistaken for the concept of “future proofing” – wondering what requirements the business might want in the future – wasteful “gold plating”. I’m not suggesting this is what you’re talking about – but it’s a danger to be wary of around this subject. The customer type data might be just as comfortable as properties of an object under different circumstances. This provides agility for the development team when the Platinum requirement comes along – and only when the user decides they need to adjust this regularly is the new table needed to make it agile for the business.

    I’d also like to point out how effective ColdFusion can be in implementing the agility you describe in your article. Although I’ve been involved in running high volume enterprise solutions on ColdFusion platforms there is much apprehension related to employing it for complex systems. Its forte is certainly the ease and speed with which prototypes and full applications can be developed with sound architectural integrity. It’s a technology that can reduce the time to market and cost of administration tools or systems alongside established Java or .Net enterprise platforms. Coldfusion in fact compiles into Java and can run on all the major J2EE severs and it also has full support for integration with .Net objects.

    I’m currently working on some presentation material on this subject and will be publishing some of it on my blog in the next few months.

    Dave

  2. Mike Kavis  

    @David,

    Thanks for the feedback. The architecture I am proposing is technology agnostic. It can be implemented using Cold Fushion (as you recommend), .Net, Java, Rails, or whatever the is deemed appropriate. The real important decision is how much time and effort is dedicated to abstracting business rules. The answer depends on the pace of change within the organization. The more dynamic the business rules are within a business model, the more attention should be paid to business rules. If the business is fairly static, then it might make more sense to handle the rules through coding. The majority of businesses today lean towards the dynamic side.

  3. Mike Kavis  

    @Matt, @Donald,

    Thanks for the feedback and I am glad you like the blog. If there are any topics you would like me to cover, please feel free to drop me a note or call me on Skype.

Post a Comment



Subscribe to: Post Comments (Atom)

My favorite sayings

"If you don't know where you're going, any road will get you there"

"Before you build a better mouse trap, make sure you have some mice"