Earlier this month I started a series on decision modeling for Rules Architects by describing how a decision model in DecisionsFirst Modeler engages the business and extends traceability and impact analysis. Wrapping up this week I’m going to talk about the importance of agile development and how traditional rules approaches force a waterfall approach.
Techniques for capturing and documenting business rules have been around a long time. Many of these pre-date modern BRMSs and were developed before decision modeling established itself as a best practice for describing decision making. These rules-first approaches all have something in common: They begin by capturing all the rules in a business or a business area and documenting them consistently. Only once all the rules are documented can a second stage begin to see which rules should go into the BRMS, at which point the rules are translated from the documentation format to the BRMS format.
A problem with the rules-first approaches is that they drive a waterfall approach. If you have to gather all the rules first, then you have to complete your requirements phase before you can begin design and build. Rules Architects know that this is not going to fly any more – organizations don’t like to wait that long before seeing some results, time to market is too important, and many business partners no longer believe that this kind of project will ever deliver anything no matter how long they wait.
A decisions-first approach based on decision models works seamlessly with an agile, iterative project methodology. The first iteration describes the critical decision(s) and draws a high level model to scope the decision service and shows what data is needed. An immediate skeleton can now be built in the BRMS to support testing.
This high level model then is expanded to identify the key sub-decisions. Using DecisionsFirst Modeler, new diagrams can be developed that take these key sub-decisions and model them in turn. The ability to reuse objects across diagrams and create multiple views lets you rapidly develop a decision model for each area. As decisions are identified and described, an implementation component (a decision table, decision tree or ruleset for instance) can be created I the BRMS and linked.
The rules for each atomic decision can be captured directly in the BRMS, taking maximum advantage of the BRMS’s ability to validate, verify and govern the rules as they are entered. Each iteration can be deployed delivering value incrementally. Each subsequent iteration can reuse and depend on previous iterations, minimizing rework. Once the whole scope is implemented, subsequent iterations can focus on refinement and improvement, using the decision model as a map of the implementation.
A modern BRMS makes it quick and easy to edit and manage the rules. There’s no need for a big waterfall analysis phase. A decision model provides the framework and approach rules architects need to deliver an agile business rules solution.
You can see the DecisionsFirst Modeler – BRMS integrations in action in these demonstrations:
- DecisionsFirst Modeler and IBM Operational Decision Manager
- DecisionsFirst Modeler and RedHat JBoss BRMS
You can learn more DecisionsFirst Modeler and our other product partnerships here.
Read the rest of the series:
