| There are 3 reasons I can think of based on my experience building rule engines for cross functional teams: #1) Conflict of Interest. It is not in the interest of a wage-earner to implement a system which automates away his/her job. Most engineers would love to take a day to turn simple conditional change and get paid for it. Most business people would also love to own their spreadsheets and be the owner of their logic. Each role prefers to be the gatekeeper of their respective domains as most in-the-weeds folks are paid for their time and not for their outcomes. #2) Useless Upstream, Dumb Downstream "the users are placed in a position where they must be more self-reliant". Oh the naivety! Rule engine projects try to transfer the domain knowledge and business logic from one brain to another brain. Herein lies the problem, you'll never be able to get someone upstream of you to implement the business logic because that's what they pay you to do (useless upstream). People downstream of you don't understand the business logic and cannot be trusted to build it (dumb downstream). What ends up happening is that you build the rule engine for yourself. This is a win for everyone except the rule engine implementer - see #1). If your rule engine can be updated 2x faster, decision making time should get cut in half. But in practice this does not happen. Instead, you will receive 2x the number of update requests to net out the time. This is the reason people hate building productivity tools for others - because inevitably, the business people say "hey if its so easy to update why dont you do it?" #3) Outcomes The key to a successful rule engine is sufficient tooling around the integration of rules engines and "business outcomes". When a rule engine is built with a domain specific outcome in mind, they can be very successful. Financial business logic is often written in excel for very exacting levels of specificity - spreadsheet conditional logic is a rule engine. For engineers, Visual editors provide great integration points for coding a vis-a-vis rule engine which ties into software systems. Klaviyo has done a great job of building a rules engine for marketers with a great UI with outcomes tied to both email marketing and automation. There are several such tools. You need a very high quality domain specific UI which is tied to a specific business outcome. |