Enterprise Initiatives

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!