A perfectly valid question, and Karthik Hariharan asks this question and further discusses it here. Here is his argument in effect.

Development teams often have to write custom wrappers for their platform

Mapping English sentences to objects can often become a nightmare that requires a dedicated team of professionals whose sole purpose is to make sure the business objects have the supporting structure to be related via Business Rules.

And as many other developers have recently stated, changing business rules through non-programmers can create system instabilities that often make it to production systems due to the lack of good testing capabilities within the BRE.

I would agree with many of the points actually, as I have seen and heard of so many BRE failures in my career.

The main issue seems to be with data models and with involving business personnel into rule development and maintenance.

I have covered these discussions in detail in my Seven Tips for your first Business Rules Project.

Here is my advice (from my 7 Tips post) on how to think about data models and business users for your business rules project.

Never forget your data models. Rules finally apply on Business Information

Keep this in mind always. Business Rules Management Systems are also software that work in your application.

If you have stable data models, like say MISMO or your own in-house object model, then go ahead and write your rules directly on your data model.

If your data model is also evolving and you want to allow your rules and data models to evolve independently, then,

1. Identify your Business terms and capture them using the BRMS. In QuickRules, for example, you can capture business terms as Definitions.
2. Write your rules on these business terms.
3. As and when you believe your data model is ready, you can map it to these business terms and your integration is done.
4. Many times you require special functions. Many vendors including QuickRules.NET provide a lot of pre-packaged functions to get around this problem
5. You can keep on re-mapping them as and when you want to test for a milestone or whatever.

Get business scenario test cases. Get the business to give them to you.

You are writing executable business policies. Remember that! You MUST do this!

1. Get Test cases for the business decision that you are trying to automate.
2. If you can, you could even get test cases for each ruleset, which will be best.
3. You can do one better. Capture the test cases as Excel, and teach your business analysts how to test using their data.
4. This is an absolute MUST. DO not rely only on application level testing. That is late in the cycle. Test early and upstream, not downstream.

Business Rule Design. Keep your Business users in mind when writing the rules.

Once you understand your business policies and how they apply, it is time to start your Business Rule design using formats offered by your BRMS.

1. Identify and group your rules logically by use case. Keep them modular! Sets of logically related rules are referred to as Rulesets. Identify rulesets first.
2. Then identify how you would apply the policies in a Ruleset to arrive at the decision that the ruleset applies for. You MUST be able to state it!!
3. You can capture this rule sequence either using a Flow Rule (sequential & graphical) or as a Rete Ruleset (where the rule execution sequence is determined using the Rete algorithm.
4. First do Step 2#. You can always change it as you learn more !
5. Then identify and write the If Then Rules, Decision Tables etc.

NOTE
Business Rules represent your business policies. Your Business owns them. When you write them, keep in mind that the people who need to see them are not techies.

In all organizations, business rule implementation always begins with IT. With experience and maturity, you can hand over rule development, and maintenance over to your business analysts. But that mostly will not happen if this is your first business rules project.