| From How to Build a Business Rules Engine (2004, Elsevier): --- ... users who have actually participated in business rule implementation projects can experience distinct unease that is sometimes manifested as resistance. This reaction occurs as a result of what can be called the Black Box Problem... ... users who eagerly adopted a business rules automation solution would also run a shadow set of spreadsheets that replicated the rules they input into the system... ... users had varying degrees of uncertainty about whether they had written the rules correctly... choosing the wrong [database] column... order of operations... order in which rules fired... ... users may not be able to fully articulate and define the rules they use in their business process, and hence cannot include them in the rules they define in the business rules engine... ... a danger that the designer may, perhaps unwittingly, include inflexible hard-coded rules in the rules engine itself... If the users are constrained by functions to only be able to do things in a certain way, they again feel that the business rules automation software is behaving like a black box that they cannot control. This is a particularly devastating criticism for software that is designed to provide users with the flexibility to write their own rules... ... With a rules engine, the users are placed in a position where they must be more self-reliant... there is usually no IT support available in the same way as there would be for a traditional systems development project... ... Failure to appreciate this problem and to add the required functionality can destroy the investment made in building a rules engine... |
It's always added complexity with adversarial purposes.