One of the hardest things for most IT departments is change. Not only do they have to cope with the technology change that is inherent in their business, they have to cope with all sorts of other change - regulatory changes, business changes, competitive changes, requirement changes, process changes, policy changes. All this change creates a maintenance nightmare so that in many IT shops most of the time is spent not in building cool new applications but editing and "fixing" code in old systems. Business rules, one of the fastest-growing markets in application development technology, offers a way to stop worrying about change and learn to love it.

Change Is Inevitable
So why is there so much change? Well, the nature of IT inflicts a certain undercurrent of change in everything an IT department does. Systems get faster, IT standards come and go, new languages and methodologies become popular, magazines are filled with great new tools and ideas for building systems better. By and large most IT people love this kind of change - it's fun, it's often why they got into IT in the first place. This might be considered "good" change. The problem is that this is not the only kind of change. IT people, like most people, like to "finish" things and get the rewards and kudos that come with it. But constant change in the business environment can make it impossible to finish applications or at least create an environment where users feel that the system is never quite right - by the time each version goes live there are already new requirements and changes required. So what causes this kind of "bad" change?

Regulations
In any regulated industry - banking, insurance, healthcare - a key risk is changing regulations. Most state legislatures love to tinker with the rules as does the federal government. If your system has to enforce these regulations then you run the risk that the regulations will change before you get them coded or after you go live. There's always the risk of an "out of cycle" change to the law resulting from a court ruling. These might overturn regulations, interpret them more broadly than expected, or have some other impact. Not only does this change happen, it's hard to control and even harder to predict. Plus, of course, you don't have the option of ignoring it!

Business Policies
Even if your industry isn't regulated, your business has policies and procedures. These too can change, although you may have some ability to control them. If you work well with your business owners, you may be able to get them to delay changing their policies or changing them only to make them easier to implement. Of course, you may not. Even if your immediate contacts are cooperative, corporate may have something to say about it and force your collective hand. Either way, changing business policies can be a bear.

Competitive Environment
This one is a shoo-in for any company with competitors. If you're building a system that in any way manages customer interactions - decides on pricing, helps them configure orders, makes them offers, or does other self-service tasks - then changes in the ways your competitors do business can impact you. If your company finds it's being outmaneuvered by a competitor, it will have to respond and that could mean changing your system.

Customer Expectations
Even if your direct competitors don't change the way they do business, your customers can be impacted by changes to other products or services they buy. If your customer base overlaps with the customer base of another company that makes some great innovation in customer service, for instance, you may come under intense pressure to do the same thing as your customer satisfaction ratings fall. No matter how well you watch your competitors (and you do watch your competitors, don't you...) this can catch you out and force changes.

Business Rules - What Do They Do?
So if change is inevitable and nasty, what can you do about it? Well, business rules management solutions, sometimes called business rules engines, can play a key role in letting you tolerate, if not love, change. So how do they do this?

Separate Business Rules from the Plumbing
The first key thing a business rules management solution (BRMS) does is separate the business rules from the plumbing. A good BRMS will store the business rules in a repository and allow you to package them up and deploy them as components in your systems. Really good ones will track changes to the repository and help you automatically deploy new rules to existing deployed components in some controlled, sensible fashion.

This separation can be done as part of a Service Oriented Architecture (SOA) by developing and deploying rules services and calling them using standard service-oriented constructs like Web Services. It can also be done without going that far by packaging the rules as EJBs, servlets, .NET assemblies, or even COBOL code and integrating the result normally. Even if the final packaging isn't service-oriented, the business rules used to drive the rules components have still been separated from all the rest of the system.

Centralize and Manage Business Rules as a Corporate Asset
A BRMS puts the rules into a repository. Managed correctly, this lets you develop and manage the rules as a corporate asset in much the same way a well-designed data architecture lets you treat customer data as an asset to be shared. Such a central repository of business rules lets you ensure consistency across multiple systems and processes by embedding components that execute the same rules, as well as eliminate the problem of too many definitions of "bad payers" or "gold customers." If your BRMS lets you deploy your rules to all your platforms you start to get a return on being able to reuse rules across both legacy and new systems. You might build cross-sell rules as part of a web redesign, for instance, but then deploy the same rules to your mainframe to print targeted cross-sell offers on customers' monthly statements. One definition used everywhere.

This kind of reuse has a side benefit. As you use a set of rules to automate a decision in more places, you can justify further investment in making that decision smarter. So, if the same cross-sell rules get used everywhere it makes sense to invest in making those rules as smart as possible. By focusing investment and leveraging it you can justify more advanced analytics and reporting to improve the decision.

Provide Tools To Let Business Users Own Their Business Rules
The last key component is the ability to put business users in charge of their own rules. A good BRMS will let you do this with enough control, and enough restrictions, that you don't need to hyperventilate each time your users tell you they've made an update: templates, allowing your business users to fill in the blanks; controlled-value fields driven from database tables and existing systems; clear use of business terminology to avoid confusion. In fact this area is key to the whole value proposition so let's discuss it in more detail.

Putting Business Users in Charge of Their Change
So how do you give business users control of their business rules and business process? What does it really take to allow business users to do their own maintenance? Well, one of the first things to remember is that business users do not, in fact, want to maintain their systems or their business rules - they think that's your job! What they want to do is promote slow-moving products through the Web channel, personalize messages on customer statements, allow call center reps to approve requests for insurance policies, enforce new regulations or whatever - they want to run their business, not your system. If you can make maintaining your system look to them like they're running their business, they'll do it for you. If you can't, they won't. So what does this take?

A Zero-Training Environment
Well, perhaps not zero training but pretty close. They're not going to want to have to be trained on some new interface or new approach just to help you out. Instead they need to be given a familiar interface, probably a Web page that looks like the other Web-based or intranet-based applications they use already. They'll have to be able to point and click, select from lists, and do all the other things they are used to with decent systems. So the first rule of business user rule maintenance is don't use a special interface, make it familiar.

Integration with their Environment
Part and parcel of making this familiar is going to be the need to integrate it tightly with their environment. If they have a place where they see reports that might cause them to change, say, their product promotions then they should be able to change the rules right there in the same application - it does no good to separate out rule maintenance from everything else they do. It also helps a lot to reuse things they've already told you. If there's a database table with territories in it then the list of territories to use in a rule should be that list, not one that has to be maintained separately. If they write a rule to define a new customer segment then other rules that use the segment a customer is in need to reflect that. And so on.

Templates
Most business users aren't going to save using even the user-friendly rule syntaxes offered by a modern BRMS. They're going to have to have a template that controls what they can change, how they change it, what options they can use, and so on. Otherwise some fool will do something like use "<" to compare two strings without understanding how case impacts that or use a piece of data that requires expensive processing in a rule without considering the value. Templates, controlling which data can be accessed and how they can be evaluated are key to letting your users build good conditions into rules. Control over what they can change as a result of a rule being true is even more important - that let's you make sure they set the flags you created for them and don't overwrite someone's SSN.

Good templates also let you control how each rule is presented. Does an if/then structure make sense or does the user really just want to see the list of conditions? Should a look-up table or tree be used or is a set of rules okay? Are there uneditable rules that should be displayed alongside the editable ones to help users understand them. And so on.

Customized
The other thing to bear in mind here is that different users will have different environments and will have different rules to edit. The warehouse manager might want to manage restocking rules as part of her warehouse management environment while the marketing manager wants to manage his promotion rules as part of his sales tracking system. Your BRMS needs to let you define multiple sets of rules and expose them in a controlled, appropriate, and integrated way for each user community.

Auditing & Control
Last, but not least, you'll have to provide audit trails of the changes made and changes deployed and controls to make sure updates and changes are managed and restricted. Your users may not appreciate this, but you will....

Loving Change
So will a business rules management solution let you love change? Perhaps not. Will it give you more time to focus on the kind of change that's actually fun? Probably. Will it get some of your users off your back? Definitely.