I recently (re)discovered the Business Rules Manifesto that states the importance of business rules and how they should be defined/processed.
Some of my favourite articles in the manifesto:
- Rules are a first-class citizen of the requirements world.
- Rules must be explicit. No rule is ever assumed about any concept or fact.
- Rules should be expressed declaratively in natural-language sentences for the business audience.
- Business rules should be expressed in such a way that they can be validated for correctness by business people.
- Business rules should be expressed in such a way that they can be verified against each other for consistency.
- A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.
- More rules is not better. Usually fewer good rules is better.
Specially important is the first statement “rules are first-class citizens of the requirements world” . I belive this fact has been largely ignored by the majority of the software development community. When strictly necessary, business rules were not defined as such but integrated by designers in the processes that could affect them (which, of course, is error-prone since designers have to be aware of all rules and think of all processes in which the integrity of these rules could be endangered).
When I started my PhD in software modeling (in 2002! a long time ago already), my feeling was that business rules were only considered by a specific community (e.g. the business rules group ) with their own development processes and tools (and conferences), called rule engines, able to directly execute the business rules (according to another of the articles in the manifesto: “Executing rules directly — for example in a rules engine — is a better implementation strategy than transcribing the rules into some procedural form “).
In fact, Antoni Olivé and myself wrote that a better integration between the business rules and model-driven approaches was one of the research challenges in the Information Systems development area.
However, I’m feeling much more optimistic now. Thanks to the semantic web, business rules are fashionable again. This, together with the definition of several standards to specify such rules (specially, SBVR- Semantics of Business Vocabulary and Business Rules), has contributed to the creation of research groups that focus on how to combine the best OF both approaches from different perspectives (including myself but we’ll talk about this another day).
What about you? How do you deal with business rules in your development process? When/how do you define them? How do you generate/write the code to enforce them?