Programming with the Microsoft Business Rules Framework

Business Rules are pervasive in software. In fact, in most cases, business rules are the very reason for the existence of most software today. As application architectures have become more and more sophisticated, few can disagree with the merits of separating the presentation layer from the business layer or the data layer from the business layer. Yet many applications today are still built with process logic and business rules interwoven within the same business/application layer, which can lead to applications that are brittle, hard to maintain, and resistant to change. In this article, I will explain how to decouple the business rules within your application in a manner that yields high organizational visibility and accountability; and promotes rules as a unit of reuse to help you build applications that are ready for change.

When Rod Paddock and I first started talking about ideas for this article, my goal was to share some of the techniques I have successfully implemented for exposing the Microsoft Business Rules Engine (BRE) via services. Always the wise pragmatist, Rod suggested that I first start with an introduction. If my experience delivering two talks on the subject this year at Austin Code Camp and Desert Code Camp in Phoenix are any indication, he’s probably right. Both sessions were well attended, and most attendees had heard of rule-based engines, but had not taken it much further. This intrigues me, because there is a growing developer community that really understands the benefits of dependency injection, inversion of control, and contract-first development. I think that anyone interested in such techniques should look closer at rule-based engine technology because it is a way to accomplish or, at the very least, compliment many of these techniques. So, while my initial goal of going deeper with the technology will have to wait, I hope that you will discover how valuable (and cost effective) incorporating a rule-based engine into your solution architecture and design can be.

What Are Business Rules?

The Business Rules Group, a non-commercial organization that helps to define and disambiguate the definition of business rules defines a business rule as “a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.” The Business Rules Group further defines business rules as organizational “guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere.”

To take a practical example, a business rule may read like this:

“If the customer is a preferred member, always apply a 10% discount on the total checkout price.”

Take a moment and re-read the Business Rule Group’s definition in the first paragraph above. With this perspective, the significance of this rule is profound. With very little knowledge about the business, it is evident that the company sells products or services to individuals, and elite customers who hold a membership status are entitled to receive a 10% discount on purchases. This rule is likely part of an organizational customer loyalty and marketing strategy, as the business rule is almost certainly designed to motivate customers to pay an annual premium for membership status. At a minimum this rule governs the activity of purchasing goods by influencing the behavior of preferred members to purchase higher-dollar purchases since they will be modestly discounted.

This is only one example. Think about the business rules that govern the applications you have built in the past or the project you are currently on. As developers, we wield incredible power-and responsibility-for ensuring that these business rules are elicited, developed, deployed, and maintained as accurately and efficiently as possible. As you can imagine from the example, there are a number of team roles that come into the lifecycle of a business rule, yet as developers we tend to hide these rules in the bowels of code bases that will rarely if ever be visible to other team roles, and when we are asked to change or remove a rule after the application has been deployed we naturally resist. Why!? Because change is hard unless your application is built to evolve, and if there is one area of your application that is almost guaranteed to change, it is the business rules. Business rules need to be dynamic just like the business itself. Rule-based engines allow you to harness this change by making business rules management completely transparent across all interdependent team roles while providing very high run-time performance. In addition to visibility and performance, rule-based engines support the loosely coupled integration of business rules into applications that use them.

Rule Engine Fundamentals

All rule-based engines are similar in that they allow various roles within an organization to author, save, deploy, and interact with business rules in a centralized manner that allows disparate applications to consume the rules in a managed, service-oriented manner. As such, most rule-based engines provide a rule editor, which allows you to author and save business rules; a shared rules repository for persisting and looking up rules; a high-performance rules engine for executing rules in the repository; and administrative tools for deploying, retiring, and migrating rules from one rule repository to another.

How We Got Here

Since the dawn of computing, our forefathers and contemporaries alike have been hard at work chipping away at the same problem: how to break apart the monolith by decoupling as many components as possible without sacrificing performance. Ever since the first computer, the trend has been constant. Computing has moved from sprockets and dials to assembly languages and onto procedural, object-oriented, component-oriented, and service-oriented designs, which further lubricate interaction between constituent parts of a system. Each of these evolutionary technologies has ushered in refined architectures such as 2-tier, n-tier, and service-oriented architecture.

The industry, in building scalable systems that are also maintainable, has widely accepted as best practice to separate the data layer from the business layers. The user interface and business layers have evolved as well, making the logical separation of user interfaces and business layer physical with the advent of distributed component technologies. Even platform and vendor coupling has proven to be undesirable, and today components can communicate with one another using messaging standards sanctioned by non-proprietary standards bodies such as W3C and Oasis.

With business rules being such a critical part of any application architecture, there are likely great opportunities for decoupling business rules from the main application or process layer. Often, the idea with decoupling is that the less one component or service knows about the other, the more free each component or service is to change and evolve. The same is true for business rules, and this is the heart of the case for using a rule-based engine.

Why Use a Rule-based Engine?

A rule-based engine isolates business rules from the application making the rules eminently reusable. Since business rules are (or should be) organizationally universal-as opposed to application specific-rule-based engines can provide unprecedented reuse (another goal of decoupling) of business rules. In addition, business rules that are visible to mere mortals (non-developers) are much better understood and this transparency introduces higher accountability within teams. In software development, a team is not just comprised of developers and architects. While these roles are very important, software product development includes stakeholders, line-of-business managers, business analysts, and quality assurance analysts to name just a few.

A recent report in CIO Magazine found that up to 70% of CIO budgets are spent on maintenance. Even conservatively, if you assume that half of the maintenance costs are attributed to business rules maintenance; it is likely that upward of 35% of IT budgets are spent managing business rules. A recent report by IDC supports these numbers. According to IDC, three-year net ROI for organizations deploying rule-based engines is in excess of 100% through 25%-80% reductions in development costs. The report goes on to cite increases in profitability and decision-making outcome of up to 50%.

The reason for the increase in productivity and ROI is simple. Separating business rules from programming code allows non-programmers to maintain business logic without writing code. Even for the most talented developers, writing code is expensive and error prone (if you have any doubts about this assertion, please see Test-Driven Development). The ability for interdependent team roles to have a hand in business rule management naturally reduces the time, risk, and effort inherent to programming changes to business rules in a vacuum. Shared business rule management leads to reduced development schedules and lower maintenance costs.

In addition, extracting business rules and making them available to the wider team promotes visibility and understanding of business policies and procedures, which serves to promote consistent decision making which leads to profitability. Fair Isaac, a leading rule-based engine vendor corroborates these assertions, reporting that in interviewing hundreds of customers throughout the world, “a 25% compression of development time is quite common, along with cost savings for developing new applications of up to 80% and maintenance of applications of up to 75%”.

Another great benefit to isolating business rules is that it makes them eminently testable. This is a core value that any Test-Driven Developer holds dear, and a business rules engine can be thought of as a way to provide a different kind of dependency injection to your applications.

By: Rick Garibay

With over 13 years’ experience delivering solutions on the Microsoft platform across industry sectors such as finance, transportation, hospitality and gaming, Rick is a developer, architect, speaker and author on distributed technologies and is the General Manager of the Connected Systems Development Practice at Neudesic.

Rick specializes in distributed technologies such as Microsoft .NET, Windows Communication Foundation, Workflow Foundation, and Windows Azure to deliver business value and drive revenue while reducing operational costs.

Rick serves as a member of the Microsoft Application Platform Partner Advisory Council and is an advisor to Microsoft in a number of capacities including long-time membership on the Business Platform and Azure Technology Advisors group. As a five-time Microsoft Connected Systems MVP, Rick is an active speaker, writer and passionate community advocate in the national .NET community. Rick is the Co-Founder of the Phoenix Connected Systems User Group, celebrating four years in operation.

Recent presentations include talks at the Microsoft SOA and Business Process Conference in Redmond, WA, Microsoft TechEd, DevConnections, .NET Rocks, Desert Code Camp, and numerous Microsoft events throughout North America. Rick is a frequent contributor to industry publications such as CODE Magazine, and is the co-author of Windows Server AppFabric Cookbook by Packt Press.

When not immersed in the work he loves, Rick enjoys mountain biking and spending time with his wife, Christie and two children, Sarah and Ricky.

Emergent Development

Scott W. Ambler presents some compelling facts about the inevitability of change in our software applications: http://www.agilemodeling.com/essays/examiningBRUF.htm