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.
Thanks for this question Miguel, this is in fact one of the core questions of any BRM approach. More generally you could formulate it this way: having understood that everybody is a potential rule stakeholder in the enterprise, which kinds of rules are there and which roles have to be aware of which rules? Well, the rules I am speaking about in my post are very high level rules I call business rules, simply because these are rules acting on the business itself, and not on enterprise models, organizational structures, operational entities or IT systems. At this level of description of rules, the management (so not only CxOs, but practically anybody in charge of a business unit, be it a department, a division or a whole company no matter what its size is) is responsible for the rules. In an MDA approach (note that I am not speaking about MDA or any implementation aspect), these high-level business rules are going to constitute the necessary input to produce lower level (more precise formulation, nearer to the implementation and enforcement of the rules) business rules and/or operational rules. If such a “transformation” of the business rules is done, then the same business rules that are maintained/communicated by the management (of course with the help of business analysts and rule analysts) are also communicated throughout the enterprise to operational entities and systems. If such an approach is not implemented, then business rules are only kept consistent and maintained by the management layers of the enterprise. I hope I have understood your question correctly and that my answer convinced you, if not, I would be happy to get another question.
Thanks for post Marwane. It gives a very good holistic picture of the BRM space. I’d like to know more about the practical benefits that companies can achieve by explicitly and accurately documenting business rules. One example that I came across and would like to share was in the case of financial companies that process loans. The business rules of the loan processing process are captured & embedded in their workflow systems. When automated, the system compares the customer’s specifications with the business rules & provides the right loan product for the customer. The benefit from this is increased efficiency for the organisation & also increased customer satisfaction as the products perfectly match the customer’s expectations. This was just one example. I’d like to know if IDS Scheer have a few more examples?
Thanks Marwane, your answer is really nice and I would like to see the same explanation summarized in a figure or scheme in the next post, it could be very useful for all. Also, I would like to know answers about more examples as Ganesh has asked. What’s the trade-off and real effort for a company by implementing these business rules?
PD.: my name is Ricardo Seguel not Miguel :)
You are welcome Ganesh. Sorry for answering you late, I am currently on a trip. What I am talking about here is not motivating the use of BRM techniques, instead I am discussing how certain BRM concepts and techniques look like and can be used. Interestingly, your point seems to be “what are the reasons why I should introduce Biz Rules and BRM in the first place and how could I use it?”. Interestingly, the example you gave is very similar to the one we use very often to illustrate the possible use of BRM in conjunction with BPM, since BPM is our core area of expertise. Although we are not limited at all to workflow aspects (since we rather observe the whole enterprise and its information systems), one of the main uses of BRM is to introduce agility and efficiency in business processes. How? very shortly said: efficiency means that through rules you are able to “control” what can happen or be done by your processes, so these are in fact aligned with the requirements that led to the design of these processes. Agility in this context too means broadly that you make your processes able to do several things by intelligently making decisions for themselves. You actually extract decision-making from business processes y cnstraining them to organizational, workflow, architectural, etc. aspects and outsource decision-making elements into logical units that could be modeled using ABRD rules. This is why I often speak about enterprise decision management (EDM) rather than BRM when getting into such high-level concerns. BRM becomes “simply” the methods, tools, formalisms and techniques that you use to “control” your business behavior. In your example, the benefits you cited match with those I shortly explained, you are now able to make sure that your processes do something, and that they do something that is actually useful and good for the business (measured by customer satisfaction).
One other example would be in the domain of compliance management or security. Take for example a governance guideline which specifies that a certain task not be executed or called depending on the amount of money being handled. Or some optimization rule doing some load balancing dispatching tasks to different employees depending on the amount of tasks each one of them already has. In the end, it is all about automation, decision automation, it is just that we want our systems to be able to make the decisions we want on their own. ans decision automation is everywhere in the enterprise, that explains why enterprise BRM is such a hot topic now, and not a simple buzz.
To finally answer your question, there are many standard examples shipped with the ABRD in what we call the UMG (United Motors Group) database, and I wouldn’t want to cite them all here :D But you would certainly be better off contacting our marketing department, they can help you out getting some examples. Or you can watch one of our webcasts about business rules. I would advise you to keep an eye on new posts on the blog about business rules since they also provide example when discussing BRM topics.
hope I have provided a satisfying answer! :D Feel free to react to the comments.
Regards, Marwane
Hi Ricardo, sorry for mistakingly calling you Miguel, I have many south American friends :D
Yeah, you have a good point there, I will try to retake that comment and summarize it in some simple figure that I will post with one of my upcoming posts. About the trade-off, this is really a question of management approach to BRM, of the degree of exactitude, documentation, formal modeling and desired automation that is to be achieved through using rules, and also like for every project, depends on the sector, on the vertical enterprise cuts where the business rules are needed. I fear I can’t answer such a general question, but I would be happy to provide some advice if you have a concrete case or example.
Regards, Marwane.
Sat, 07/05/2008 - 21:28
Alfrieda said:
Marwane, I have been evaluating the ABRD and the possibilities excites me. My only area of concern is closing the loop between defining the rules and deploying the rules within our business applications. According to the help files the possibility exist to deploy these rules to either a Java service or Web service. The business application can then call these services to execute the rules. Just the agility to the business I need! Do you have any guidance or experience you can share on this approach? What type of performance can I expect if my transaction volumes are high calling the services?
Regards
Alfrieda
Hi Alfrieda,
You are right, the deployment of business rules as services (java/xml or web services) is meant to close the loop between design and execution (with only one setep missing to complete the loop at 100% which is service monitoring, but this is rather the task of an SOA governance team and is not specific to your rules). We are currently working on a showcase that shows in a demo what the possibilities that are offered by this kind of functionality and will hopefully be able to present it soon. It is pretty straightforward really, because all the functionality you will need for this is already available. It becomes very powerful when you deploy complete business processes including embedded rules and let these run. About performance it is really something independent of business rules and my answre would be very generic. Performance issues are the same you get for any web service-based architecture. The performance of the rule execution itself are insignificant because the rule engines that execute rules after catching the wweb service calls are exetremely quick (although I have no concrete numbers at hand, but there are independent instances who have such benchmarks).
Regards
Marwane
