Prev | Next |
Modeling Business Rules
In any business action or process, the start, progress and end result are usually determined by reference to a set of rules. These rules can be very simple, such as 'the client must present documentary evidence of being at least 18 years old', or very complex, such as the actuarial rules that determine what a tailored insurance policy will and will not cover.
Whether the rules of your business are simple or complex, there are two sets of considerations to take into account:
- How to manage the rules - How are they initially identified? Where are they held? Are the rules easily maintained and updated? How are they refined and tested?
- How to use the rules - How easy is it to identify which rules apply in a specific context? How easily can any specific rule be recognized and applied? How are the rules executed in the process - can they be integrated with the process? Can execution of the rules be automated in the process?
Both sets of considerations can be easily managed by modeling your business processes in Enterprise Architect, and using the Business Rule Model facility. Business Rule modeling captures the rules that govern a business, and their relationships with the entities and specific tasks within the organization or system.
Managing Rules
Broadly, modeling your business processes can clarify:
- Your business requirements (from which many business rules are ultimately derived)
- The use cases - and the scenarios in each use case - to satisfy those requirements, and
- The exact processes, stages, objects, actions and data structures that support those use cases, represented by Classes
This process will also clarify which of your current business rules are applicable to which points in each process, and what refinements or new business rules are required. You can then map your business rules to existing or new Classes, using two specific Business Rules models; the:
- Business Domain model, in which you group the business objects (represented by Classes) involved in a process or application, and develop a Rule Flow that defines the tasks (as Rule Task elements) associated with the process as a whole or specific objects in the process
- Business Rules model, in which you create a specific Business Rule element for each business rule and associate it with the Rule Task to which the rule applies
When you have defined all the tasks, their sequences, and the rules that apply to each one, you can compose the rules per task to define the values and conditions of the rules and how they take effect in the task. You can then validate the rules for the task to ensure that they are logical.
A valuable resource that you have created in this process is a database of business rules associated directly with the tasks and procedures they apply to, easily explored (according to the naming and/or numbering convention you have used) with the Model Search and other navigation and display facilities, and documented through the document or web reporting facilities. You can also record further information on each rule using internal or external notes, Tagged Values and Linked Documents.
Using Business Rules
Having set up the business rules database, your users can access the models or their documentation as a reference. As explained above, the context of any given rule, or the rules applicable to a context, can be quickly established using the search, navigation or Traceability facilities.
However, you can use Enterprise Architect to model and create applications and user interfaces that can apply the business rules you have defined, and a further facility of Business Rule modeling is to generate the behavioral code for the rules in a specific task. You can merge this into your code to prompt for or even automate the correct use of the business rules in performing a task.
Advantages of modeling Business Rules
Whether you create a database of rules, or applications that apply the rules, you have a modular solution to a business process requirement. This provides an advantage in localization. Business Rules can vary between locations; for example, car hire operates in roughly the same way in most countries, but the legal driving age differs between the countries, as do the models of car available for hire. You can easily create different localized rule modules and switch the appropriate one for the current location into the common model.
Notes
Learn more