My own feelings about that is yes, rules writer must know the objects they manipulate. So, to answer your question, if the object model is very technical, Devs must write rules. If not, BA can do. The main point is how much technical is your model objects. If you are starting a fresh new application, you should consider designing the model objects in order to make them as close as possitble to the BA's concepts, thus making possible (and natural) for BA to write rules directly. My personnal experiences, not only with drools (exactly the same problem appears with commercial products too), is to try to provide model objects that "speak" to BA. This way I do not need a full complex DSL (which is quite heavy to maintain if you have to create a phrase for each "mapped" attribute of every object). To achive that, I often use a Facade that transform my real technical objects into more business-oriented objects used to feed the engine. But you still need some training, even if you model objects match perfectly the concepts used, at least to explain what is a rule, how it is executed (to let them answer by their own "why it is looping ?" "Why this rule does not trigger?" ...) Le 01/02/2011 17:08, cclark01 a écrit :

One of the most famous epigrams of programming<http://www.cs.yale.edu/quotes.html>collectd by Alan J. Perlis is: *When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. * I'm reminded of this in any discussion where this sales-pitch-black notion of Business Analysts writing rules by themselves is peddled with the assumption that some cleverly designed non-trivial DSL will magically provide a blue sky and smooth sailing. Of course the BAs will still have to have a clear understanding of the object model, and of course they will still have to know the basics of rule programming. They'll need good training, and (although I have never seen this) I think that they'll need a lot of baby-sitting when they start. When you write that "DSL ... gets built up over time" I think I know what you are referring to, but this is more a hint on the way a DSL might be developed, well before it is released for writing rules for production. Changing a DSL - even by just adding new phrases - is tricky due to the way DSL parsing works. All of this does not mean that it cannot be done or that you cannot do it. Mostly, it is the result of developing a DSL with the intent of demonstrating that rules can be written in a language that can be read and understood by domain experts. (Note what the experts are *not* expected to do.) According to this, I have the following checklist for a DSL developer: 1. Design a simple object model with clean linkage between related objects. 2. Know about all rule condition and consequence patterns that will need to be written. 3. Make sure that you fully understand the way DSL parsing works. 4. Decide about the way the BAs will write the rules (GUI editor or text editor). After (2), you still have the option of using spreadsheets or template-based rule authoring. If 80-90% of your prospective rules can be written by BAs that way, you may still decide to have the rest written by programmers. IMHO, none of the aforesaid is specific for Drools. Cheers Wolfgang On 1 February 2011 17:08, cclark01 <chris.clark(a)teranet.ca&gt; wrote: