cclark01 | 1 Feb 2011 17:08
Picon
Favicon

Who writes your rules? Dev vs. BA


My company is looking to use Guvnor in a new application we're writing.  Part
of the appeal is the idea that Business Analysts will be able to go and
write rules by themselves.  However, in doing a small proof-of-concept, it
appears that you need intimate knowledge of the object model in order to
write any meaningful rules.

I've read up on DSL and it looks like that might help things, but it also
sounds like DSL is the kind of thing that gets built up over time.

So... what's your experience?  Do BA's or Developers write the rules in your
applications?  Does the complexity of the object model play a role in who
can write rules, or is it just a matter of training?
If you've created a DSL, how easy/quick was it?  If not, any particular
reason why not?

I'm looking for some "real life" experiences so that we can have appropriate
expectations going into the project.

Thanks,
Chris
--

-- 
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Who-writes-your-rules-Dev-vs-BA-tp2398166p2398166.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

(Continue reading)

Vincent Legendre | 1 Feb 2011 18:04
Favicon

Re: Who writes your rules? Dev vs. BA

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 :
> My company is looking to use Guvnor in a new application we're writing.  Part
> of the appeal is the idea that Business Analysts will be able to go and
> write rules by themselves.  However, in doing a small proof-of-concept, it
> appears that you need intimate knowledge of the object model in order to
> write any meaningful rules.
>
(Continue reading)

vasilievip | 1 Feb 2011 22:13
Favicon

Re: Who writes your rules? Dev vs. BA


I agree too that it depends on complexity of model and rules itself.
Publishing rules to BA may result in BA's learning on how to develop
programs (in fact BA is not the right person to write parseDate or some
similar function).

We tried to tailor Guvnor but result is that we use it only as repository
and not as authoring tool (I hope we will tailor DSL and this will be
changed..). Amount of rules may be up to 1k in one package - I'm not sure if
Guvnor will be user friendly in this case,but using drl you can have 10
files with 100 rules in each (maybe autogenerated from template). Developers
don't like Guvnor UI and prefer Eclipse plugin. Also we met an issue with
our code repository and Guvnor - so we are building repository import xml
for Guvnor from subversion - this helps to manage versions properly (tied to
builds). 

So there are several points to look at. I think if you really need to have
BA's writing rules - you must solve this problem, in other case - junit +
drl (+flow maybe) is the best fit.
--

-- 
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Who-writes-your-rules-Dev-vs-BA-tp2398166p2400829.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Wolfgang Laun | 2 Feb 2011 08:55
Picon

Re: Who writes your rules? Dev vs. BA

One of the most famous epigrams of programming 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 <at> teranet.ca> wrote:

My company is looking to use Guvnor in a new application we're writing.  Part
of the appeal is the idea that Business Analysts will be able to go and
write rules by themselves.  However, in doing a small proof-of-concept, it
appears that you need intimate knowledge of the object model in order to
write any meaningful rules.

I've read up on DSL and it looks like that might help things, but it also
sounds like DSL is the kind of thing that gets built up over time.

So... what's your experience?  Do BA's or Developers write the rules in your
applications?  Does the complexity of the object model play a role in who
can write rules, or is it just a matter of training?
If you've created a DSL, how easy/quick was it?  If not, any particular
reason why not?

I'm looking for some "real life" experiences so that we can have appropriate
expectations going into the project.

Thanks,
Chris
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Who-writes-your-rules-Dev-vs-BA-tp2398166p2398166.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Vincent Legendre | 3 Feb 2011 12:26
Favicon

Re: Who writes your rules? Dev vs. BA

Just to bounce on DSL considerations

For me DSL as they are provided in guided editor are not suitable for 
real-life projects, because :
   - parsing is too simple, and then force the rule writer to have a 
good idea of how it work, and what is behind the DSL phrase they use.
   - the guided editor do not have a kind of contextual filtering for 
phrases, so all the phrases come in sequence in the dialog box. This 
quickly become unpraticable for large object models
In some way, I think that coding all rules with DSL is reserved to 
Developers, but can produce rules that could be read (and validated) by 
BA. Note that this could be a good way to produce rules (one Dev coding, 
one BA validating)

So I try to make BA use directly the guided editor, which provide a way 
to edit rules using objects, then their attributes, and finally their 
values. This is the kind of contextual way of presenting concepts that 
is lacking in DSL (like what can be done by JRules BOM). I only use a 
very limited set of DSL phrase for special predicates or actions if I 
can't easily add a method in my BO.

Some other remarks. Someone told that DSL are convenient for having 10 
files exploded in 100 rules. I think that in this case, spreadsheets are 
far much adapted. I agree with Wolfgang that really often, 80% - 90% of 
rules can be written using tables, enabling BA to handle almost all 
their rules.

_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Gmane