thinking in rules

Now We're Talking the Same Language

Mike Grucella | 12/10/2013

As a pre-sales engineer it’s my job to demonstrate how InRule can help a customer solve the problem of creating, managing, and incorporating business rules into their applications. There are literally dozens of features I could talk about when I do that, but there’s one in particular that I want to focus on with you today. We call it Vocabulary and I think you’ll find it to be a really interesting option for customizing your business rules to conform to your industry-specific language and terminology.

Language for Your Industry

What do I mean by that? Well, when you’re in meetings discussing your application with the rest of your team, you’re probably talking about it in terms of how your users or customers use it. If you work for a bank, you’re talking about accounts, investment vehicles, financing, mobile banking, overdraft coverage or lines of credit. If you work for an online, direct sales company, you’re probably talking about customers, orders, products, promotions and sales. In either case, it’s a language that’s particular to your business.

Language for Your Organization

But what if you want to make it even more specific? Instead of referring to a checking account in generic terms, maybe you want to refer to your bank’s “123 Enhanced Checking.” Instead of referring to a promotion in generic terms, maybe you want to refer to the “On-line Holiday Savings Bonanza.” See the difference? Talking about your business in generic terms gets the ball moving forward when you’re creating business rules around them. However, at some point, you’re going to want to move from generic to specific. This where Vocabulary can provide a huge benefit to you. Let’s take a look at an example using our bank scenario:

Industry-Specific is Good

You’ve created a rule in irAuthor that’s going to evaluate some conditions about an account. If all of those conditions are met, then we want to make a recommendation for an account upgrade. Here’s what the rule currently looks like:

Blog_BusinessRuleVersion1

Now, all of this is well and good. Our language rule makes perfect sense for anyone who reads it, but it’s written in generic terms like Type, Holder, etc.

Organization-Specific is Better

As an alternative, you can create vocabulary that wraps that evaluation in a more relevant language that your rule authors recognize.

Blog_BusinessRuleVersion2

This is a much cleaner representation of the same rule. The “qualified for 123 Enhanced Checking upgrade”-- which is our vocabulary-- wraps the evaluation of those same conditions in a simpler implementation. Now consider the possibilities. If you have multiple rules that are evaluating whether or not an account qualifies for this upgrade, you don’t want to visit, and potentially miss, each of those rules in order to make sure each one is evaluating the same conditions. Because it’s defined in vocabulary, you have a single definition. If those conditions change, maybe you want to include an evaluation of the account value, for example, you just need to modify the vocabulary. And you can create vocabulary for any number of scenarios: calculations, expressions, assignments, even for calling other rules.

"Simplicity is the ultimate sophistication"

Leonardo da Vinci's insight that Simplicity is the ultimate sophistication” can apply to how you create your application’s business rules as well. When you take away everything else, you’re left with a clear, concise and elegant solution that’s easy to read, easy to manage and written in your own business language.


comments powered by Disqus