Roadmap: How to Adopt Agile Business Rule Development Practice |  |
This roadmap describes how to adopt the Agile Business Rule Development Practice for your own need.
Main Description
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 plan. 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. ### Common Pitfalls 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 the rules. 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.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. EPF Copyright.