This article is a continues the previous article about business rules and vocabularies. Just as business processes and data form an important asset for any organization, they form the central asset for a rule-enabled organization, too. The knowledge accumulated by companies, their experience in the market, in taking and propagating decisions throughout the whole organizational structure, can be partly represented by rules, complementing business documents, knowledge bases, manuals, and business data models...
But the one thing rules can do that other techniques can’t, is the automation of the decision-making process. The reason why companies gather knowledge is to gain advantage on the market through that knowledge. In order to do this, the automatable decision-making processes have to be modelled, validated, communicated and set to production. This is usually done by having the management produce guidelines that are propagated through the company and employees have to take care of acting according to these procedures. This knowledge is not formal, commonly agreed on, subjective, and hardly manageable in efficient fashion, because keeping this knowledge up to date despite changes in manual fashion is one hell of a job. Business knowledge is hard to put a hand on it is everywhere, in every document, on every mouth, and most of all, in every head. People have to bring themselves to put this knowledge down and agree on it.
Rules can automate such processes, no matter whether the actions triggered or requested by rules are executed by humans or IT-systems. You just need to clearly describe the decisions to be taken, and the events or conditions upon which these decisions are taken. A Business Rules Management System (from now on referred to as BRMS) has to offer the necessary functionalities to model these aspects.
There is one necessary condition to achieve this: a common understanding of the information on which decisions are based, and which are used by business rules. We will see how business vocabularies constitute a simple and powerful way of getting to such an agreement.
As we have explained in Part One of these series, the concepts of Terms and Facts that compose the Vocabulary are one important element of mainstream approaches to achieving common understanding. In the upcoming OMG standard for business rules, SBVR, terms and facts are core to the specification. If you’re interested to know more about SBVR, keep in touch with my posts because I will write a few things about it. If you can’t wait, help yourself here. In ARIS concepts are modelled among others in data models such as UML class diagrams, technical term models or in old good Entity Relationship Diagrams (EDM).
A perfectly adapted model type to capture terms and facts is the Vocabulary model, available in the ARIS Business Rules Designer. Terms are modelled as entities and facts are modelled as relationships between entities. The naming changes, but the concepts are quite the same. The one question you have probably asked yourself right now is: “can I use my enterprise data models in order to model vocabularies”. The answer is: “Yes, you can, and you should”. Enterprise repositories such as ARIS are all about information reuse.
It is very easy to create vocabularies from existing data models. Another thing is, ABRD vocabularies stay synchronized with data models they have been created from. You can combine as much models as you want to form a single vocabulary. One thing is not to be forgotten though. Vocabularies should be kept as simple as possible, because the bigger the vocabulary, the harder it is to manage. There are several techniques to scope the vocabulary right, and I will try to explain this in one of the next posts. I will also concentrate on some of the initial parts of the business rule management lifecycle and explain how you can realize them using the ABRD.
Glossary:
- [SBVR] Semantic Business Vocabulary and Rules.
- [BRMS] Business Rules Management System.
- [ABRD] Aris Business Rules Designer.
