Decision Management & BPM
Business Rules Cafe
By James Taylor, CEO, Decision Management Solutions
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 the majority of time is spent not 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, its reliance on technology, inflicts a certain under-current 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 that. 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?
In any regulated industry – banking, insurance, health care – a key risk is changing regulations. Most state legislatures love to tinker with the rules as does the federal government. If your system needs to enforce these regulations then you run the risk that the regulations will change before you get them coded or after you go live. In addition there is 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 is hard to control and even harder to predict. Plus, of course, you don’t really have the option of ignoring it!
Even if your industry is not regulated, your business has policies and procedures. These too can change, although you may have some ability to control them. If you are working well with your business owners, you may be able to get them to delay changes to their policies or change them to make them easier to implement. Of course, you may not too. Even if your immediate contacts are cooperative, corporate may have something to say about it and so force your collective hand. Either way, changing business policies can be a bear.
This one is a shoo-in for any company with competitors. If you are building a system that manages customer interactions in any way – decides on pricing, helps them configure orders or do other self-service tasks, makes them offers etc – then changes in the ways your competitors do business can impact you. If your company finds itself being out maneuvered by a competitor it will have to respond and that could mean changes to your system.
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 who makes some great innovation in customer service, for instance, you may come under intense pressure to do the same 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 our 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 “plumbing”
Well 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 with automatic deployment of 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 it not service-oriented, the business rules used to drive the rules components have still been separated out 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 allows you to develop and manage the rules as a corporate asset in much the same way as a well-designed data architecture lets you treat customer data as an asset to be shared. Such a central repository of business rules allows you to 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 also start to get a return on being able to re-use rules across both legacy and new systems. You might build cross-sell rules as part of a web re-design, 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 re-use has a side benefit. As you use a set of rules to automate a decision in more places, you can justify more investment in making that decision smarter. Thus, 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 I 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 hyper-ventilate each time your users tell you they have 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 so key to the whole value proposition, 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 customers’ 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 are running their business, they will 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 are 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 other web-based or intranet-based applications they use already. They will need 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 tightly integrate this 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 re-use things they have already told you. If there is a database table with territories in then the list of territories to select 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 which segment a customer is in need to reflect that. And so on.
Most business users are not going to safe using even the user-friendly rule syntaxes offered by a modern BRMS. They are going to need to have a template that controls what they can change, how they can 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 access and how it 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 ok? Are there un-editable rules that should be displayed alongside the editable ones to help users understand them. And so on.
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 re-stocking 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 and control
Last, but not least, you will need to provide audit trails on 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….
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.
About the Author
James Taylor is a blogger at ebizQ. Taylor works closely with customers and partners to help them deploy decision management applications to automate, manage, and optimize business processes according to their unique business requirements.
Taylor is widely considered a leading expert and visionary in enterprise decision management and authors a popular ebizQ blog on the subject at http://www.ebizq.net/blogs/decision_management/.
Taylor is often cited in research reports and articles, regularly contributes thought provoking content to publications and frequently presents at trade shows and conferences.
A graduate of the City University, London and the University of Reading in England, Taylor has degrees in Geophysics and Business Systems.More by James Taylor