Skip to main content
If you are building a tax system, use a business rules engine. Please!

Another interesting piece in Computerworld today - Buggy App Causes Tax Problems in Wisconsin. This sounds like the classic piece of government tax software - lots of problems. The system "was designed to automatically process sales and use taxes and to determine how much revenue is distributed to Wisconsin's 58 counties and two professional sports districts". As I was reading it, though, some great comments leapt out at me:

She attributed the bulk of the problems to "design flaws" in the system as delivered by CGI-AMS in December 2002.
In an e-mail, a CGI-AMS spokeswoman said that "the system was designed according to the original specifications. We are committed to working with the DOR to resolve outstanding issues" without charge.

Well this is a classic. The state says it is all caused by design flaws while the developer says it was designed to meet the specifications. Of course, both of these could be correct! Just becuase a system is designed to meet the specifications written at the start does not mean it will not have design flaws by the time it gets into production. This is why business rules management systems make such good sense for these kinds of system - they allow you to evolve the system quickly as requirements change. Building in business agility in this way helps prevent this kind of he-said, she-said stuff.

Since the installation, the system has been plagued by software defects that caused calculation and programming errors along with processing backlogs.

See above. These are the classic errors caused by coding the wrong business rules. Now the question you have to ask is whether it is reasonable to ask programmers to write Java to implement tax rules they don't understand or to ask government officials to QA Java that they don't understand to make sure it matches the tax rules? I don't think it is and hence would argue that you should always use a business rules approach for this kind of thing.

In addition, the report said that incomplete information was entered into the system, causing it to misread tax obligations and miscalculate retailer discounting computations.

Last comment. Business rules have another great feature - they are really good at checking for incomplete information! They can build very effective rules-driven user interfaces to capture the right data the first time.

So if you are reading this and building a tax system - use a business rules approach. Please...

related posts