I was reading this post by Jeremy Miller and came across this golden nugget of wisdom that seems to be very applicable:

"Oh, and the people out there swearing up and down that giving the business end users a screen to configure a business rules engine themselves will save the day?  BS.  Drawing workflow's with pictures is coding -- with every bit of the risk and danger that coding brings.  Only now you're making noncoders code in the production system.  Think about that last sentence. "

Bingo!  Allow me to elaborate on this:

• There are no unit tests surrounding the changes, which imply legacy “code”.
• No verification step.  QA is completely out of the loop, I doubt they would appreciate that.
• Engineers will need to be brought in to fix problems when something unexpected happens.  This is a reactionary situation which causes people to work over time and under stress, both of which I know I like to avoid.
• There is no formal change control surrounding the process.  This sounds bad, breaking the law kind of bad.
• Who wants to code through Visio or some one off custom UI anyway?  Last I checked Visio didn’t have a debugger, and if Visio doesn’t have a debugger certainly your one off custom UI won’t.  Good luck tracking a problem down without full disclosure to the system code and infrastructure.

These issues are not just merely applicable to business rules engines; they are also applicable to highly customizable applications with lots of admin screens.  Do you really want end users to be able to go in and add/remove workflows, user accounts, test points?  Do they really need these features?  Probably not, and this could potentially open up all kinds of data integrity issues.  Who really wants to restore a database from tape because some user made a change they didn’t truly understand?  This is why it’s important to have someone own the change process, like a development team or business rules expert.  Someone needs to be accountable for the integrity of the system.

On top of all this we need to take into account all of the extra work that will need to be done just to create the hellish user interface to the back end of the system.  Add documentation, testing, and training to the mix and you just doubled or tripled your system cost, and what have we gained?  We gained: lots of extra work, bugs, and data integrity issues.

Having the system be highly end user configurable makes the business feel more comfortable because they believe they’ll have ultimate control and flexibility.  Probably a far better solution (and more cost effective) would be to work on your trust issues with the business.  Put them at ease about the system by making them feel like they are part of a cooperative team rather than just a customer.  When release 1 hits they need to know the development will still be there to add additional features and fix any issues that crop up in a timely and predictable fashion.