I’ve been working on a financial services project that has a LOT of complex business rules that are changing to meet regulatory compliance as well as business needs. Over the past couple of months I’ve made a few system flows, but I’ve discovered that the decision table is my best friend for this project.
When I started on the project, I reviewed existing documentation and discovered that the business logic was spread across multiple documents or simply hidden away in people’s brains. I started pulling it together into workbooks with multiple tabs containing decision tables as well as lists of valid values that help explain the contents of the decision tables. As I use these workbooks in elicitation meetings and workshops, I’m discovering that they are helping with more than just ensuring complete and correct business rules.
- Simplify business logic – Putting business rules into a decision table format can help you discover redundancies and simplify your documentation, which will hopefully help the development team create better code faster.
- Identify where business logic should live – One thing I’ve discovered is that when I’m modeling complex business logic, it sometimes makes sense to break it up into related chunks instead of creating one enormously complex table. This leads to useful conversations about technical design. Which application/service should own which pieces of the logic? What design choices provide better scalability?
- Jump start testing – If the decision tables are explained and provided to the testing team, they can develop test scripts directly from the tables. In fact, the testing team should review the tables BEFORE they are finalized, because they often have important insights on exception processes that you might have overlooked.
Below is a generic version of a decision table used to validate a specific type of credit request. This is a binary decision; either the credit request will be evaluated or it fails with an error message to the requestor. I prefer to use the dash symbol to indicate that a particular condition is irrelevant to a rule in the table. It helps keep the table from being too cluttered.
