Having met and discussed business rules with many customers over the last year, several questions arise in nearly every business rules conversation. Business rules can vary a lot by industry, but understanding the need for business rules in decision processes is common across every application. In all cases, quite a bit of time is spent focusing on vocabulary creation – something that is necessary before any business rules are written.

Vocabularies need to be recognizable to the business and must be organized in a way that reflects the natural logic of the business application. A data driven approach to selectively creating or deriving a vocabulary has been very useful and well received by customers in every industry.

So what is a vocabulary? In its most common form, a vocabulary is a "fundamental tool for communication and acquiring knowledge," according to Wikipedia. In the context of decision management, a vocabulary is a set of terms that are used to create business rules. It is part of the business rules language, along with operators that define how the terms are combined.

I'll be describing how to create vocabularies for SAS Decision Manager, but you can apply these same steps to the many vocabulary creation exercises in general.

Since business analysts know their data and what it means, they can import an existing set of recognized terms from any table that resides in a managed library to create an initial vocabulary. During the import process, there are various options for setting up the terms. First, you give your vocabulary a meaningful name and then you give your entity (the first level categorization of terms) a name.

Once the names are set, the focus is on the individual terms. Terms are directly related to the fields in the operational data input table – the source data that is being examined. By default, terms take on the name of the table column name, but it’s a best practice to use term names that make business sense rather than IT sense, given the actual “rule authors” are business analysts.

While the vocabulary is being defined, you may also want to include particular column “values” such as gender, state abbreviations, product names, type of insurance, provider name, policy name, etc. By allowing such values to be included with the import, time is saved building rules, and errors are reduced by not typing the “value” during rule creation. The data types of the terms are automatically determined.

Next, you are ready to import the vocabulary. Importing vocabularies is very efficient and takes advantage of pre-existing data dictionaries (or tables) that are driven from data governance teams within the organization. This is a welcomed capability – ensuring consistency with existing definitions.

Now, additional terms that are not in any table but would be helpful to rule execution logic can also be defined. These terms are coded manually and follow exactly the same format (with all of the options) as any of the imported terms. These execution logic terms can provide a lot of flexibility for intermediate term logic definition, like setting a value that is referenced at some point during the rule execution but is never seen on input or output.

If you discover, during the process of rule creation, that you need a new term not thought of before, you can stay in the same SAS Decision Manager interface and simply right click to add a new term to the vocabulary. This ease of navigation mimics the natural way analysts write business rules.

Vocabulary terms are mapped to a table column where the vocabulary term is linked to the actual data element (or table column name) in the operational data store. Some automatic mapping will occur if the vocabulary term name and the data element or table column name is exactly the same. This, however, is really an exception rather than the rule (no pun intended) because the strength of a vocabulary is to have meaningful terms that make business sense and that can be used more than once – in different rules and applied in different ways. Mapping is done when business rules are tested, and when they are deployment in batch. For web services, term vocabularies are related as inputs (request) and outputs (reply) variables are the result.

Over the coming months, I’ll share more "under the covers" tips about decision management. If there’s something that you’ve been wondering about regarding decision management, please comment to let me know.

And more information about business rules can be found at the SAS business rules manager page.