Something else: How to smoothly start your first business rules project
The first project with a Business Rules Management System (BRMS) is something special: Everything seems to be different – different tooling, different tasks, different team play. You do not need to be a psychologist to expect friction and teething troubles. Hence, I pumped the colleagues in the project teams of Innovations for information and here are their top tips for a smooth start:
1. Roles, responsibility, and co-operation
The Alpha and Omega is a sensitive preparation of all people involved: After all, the domain experts should not panic just because they will be responsible for the rules. And, of course, the IT experts should not retire just because hardly any Java code needs to be written. In order to avoid the panic as well as the retirement, it makes sound sense to document the new responsibilities and tasks. By the way, a visual BRMS, like Visual Rules, facilitates the communication between domain experts and IT experts: A visualized business rule is tangible and hence simplifies the mutual understanding.
2. Take-off and first rules
Typically, several colleagues cooperate in a business rules project. Thus, if you do not want to waste precious time, you should agree on the modus operandi as soon as possible. First and foremost, you need to answer the following questions:
1. Who is responsible for which task?
2. Which documents are needed?
3. Who takes over the quality control?
Usually, the domain experts know best how to describe the overall structure and the details of the business rules. How to construct the general overview of the domain, that is, how to model the so-called structure rule is by the way explained in detail in our paper “Best Practices Business Rules Management” (Java Magazin 5 / 2010). If the domain experts take over the rule modeling, the quality control should be carried out by the IT experts – and vice versa – since it is good practice that no one evaluates the own work. Moreover, as the business rules are not free-wheeling, the technical interfaces are ideally defined right at the beginning of the project. The IT experts typically know best how access to data bases are organized and which services are to be connected in order to be modelable in the rules – however, it is even better if the domain experts also have a basic understanding of these technical issues.
3. Few rules and large projects
How often have you become desperate to understand badly commented source code? That’s awful, isn’t it? For business rules projects, especially for large ones, it’s the same: If they are not properly commented, after a while, you won’t be able to understand anything. And then it may be even faster to start all over again from scratch – what a waste of time and resources! Hence, bear in mind that you provide a brief summary for each rule model. By the way, you can put them in the comment field in the header of a Visual Rules model. Such a summary will help you to remember what the rules are about and why they are modeled the way they are. Let’s face it: Once the project is running, the documentation tasks are typically neglected… hence, you need to regularly schedule it: You should then document who changed what, when, and why. And you should also carefully record the results of your performance tests. These are the tips of our project teams… Which additional tips do you have for a successful project start?