« Dashboards are not the future, but they are on the way there | Main | One challenge of business-owned applications (for there are many) »

A product manager for one of the leading rules products had an interesting post last week - Can we trust Business Users? Carole-Ann was focused on the need for IT to trust business people when they are editing business rules. This made me think, though, about the ways in which using business rules builds trust in the business users themselves. After all, many business users do not trust IT. They don't trust IT to deliver on time, they don't trust IT to deliver what they need (rather than what they said they wanted) and they don't trust IT to be able to make changes at the pace the business needs.

Taking a business rules approach when developing systems can help with all of these things.

• The business logic within a system - the implementation of business decisions - is often the most complex and most difficult to test element of a system. Using business rules to more effectively manage the specification of decisions increases the odds that applications will be delivered on time and so builds trust. Because business rules also allow business users to participate directly, the number of folks contributing to getting the logic right goes up and the business users can and will feel like part of the team not just victims. Getting the business to validate business rules is also much easier than asking them to validate code...
• As I have said before requirements are never complete - if only programmers would realize that and stop expecting business users to know what they need. Using business rules means that business users are collaborating directly with IT to define the business logic and that the resulting logic is much more likely to be what they need when it is done rather than being what they said they thought they needed when you started!
• Lastly business rules are a great way to really deliver on business agility. Business users can be empowered to make their own changes or at least to participate in making the changes they need as and when they need them. No big software release cycle, no getting in IT's queue. Real agility.

Posted by jtaylor in Business Rules |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/3568