The goal of a BRMS is to be able to manage business rule as a standalone artifact, owned by the business user, and
maintainable over time into production system. The implementation of a business rule application follows some
activities and tasks that are slightly different than traditional software development life cycle. The integration of
one or more business analysts as part of the development team is also less traditional. Finally the core value of such
technology is to be able to have business user maintaining the business rules in production with a minimum involvement
of IT. Technology is one side of the coin, methodology and best practices is the other.
A project management office can leverage ABRD as is to integrate it as content for their own methodology.
If the team is new to business rule application, it is best to start with a small rule set and incrementally add rules
and best practices over time. The team has to integrate the rule discovery and analysis activities in their own project
Prototyping is a major value, as it shows to the team concrete execution, and helps to drive issues, and requirements
around business rules and even business process.
The most common pitfalls in implementing business rules application include:
Harvest all the rules in documentation
Forget about the data model
Do not understand where the rules are enforced
Mix data model from the implementation point of view, versus the domain model, understood by the business
Involve IT only: never forget the business, involve business as early as possible, make them taking ownership of
Outsource business rule implementation: business rules are enterprise assets: the difference between to
insurance policy underlying rules make two insurance companies competing and bringing different values.
Forget to test the rules outside of the application
Do not involve business in the rule validation
Badly design a rule set, by not applying standard design pattern as separation of concerns.