Article:		Give Your Business Logic a Framework with Drools
Subject:		Business Users
Date:		2005-08-04 08:01:47
From:		vikdavid
Good introductory article, Paul. But regarding: -- the power and the flexibility of our rule engine allows us to quickly develop the business logic -- Rules Engine summaries make lots of use of pitches like that. Trouble is the "us" part. Who's "us"? I just can't see a business user using a tool to write business rules, clicking save, and having the changes go live into production. I think it's much "easier" for biz users to fire up MS-Outlook, write up the rule and send it to an IT manager/developer. You mention tools, but in my experience, even if the tool makes writing biz rules easiER, business analysts will still prefer the outlook/email way. To them, *THAT* is just as easy as it gets (or phone, or conversation in a meeting). My fear is that rules engines will become another ball and chain for developers. Write rules in an XML file. Deploy into container (the rete engine) to run to see if it 'works'. To make life easier, developers will be using the tool that the biz users were supposed to. Just my $0.02.

Showing messages 1 through 3 of 3.

• Business Users
  2005-08-04 08:24:20  paul_browne [View]
  
  
  I wrote these articles based on experience as a Java / J2EE developer , so 'us' is very much from that viewpoint. Given that 'Java-only' developers must implement business rules anyway , using the Drools framework offers gains in time , flexibility, resuability , testability and easier maintenence.
  <BR/>
  Like all frameworks, the choice of using a Rules Engine or not will vary by project , organisation and skillsets available.
  <BR/>
  The aim of the article was not to entice business users to use Drools (I don't think that many of them read O'Reilly!) , but if that is the way you would like to use Drools , one tool that may help is the Drools-Excel Integration (http://www.drools.org/Decision+Tables) .
  <BR/>
  Paul Browne (http://red-piranha.blogspot.com/)
• Business Users
  2005-08-04 14:04:25  vikdavid [View]
  
  
  Ok, I was impressed by the Drools-Excel link. On a previous project, we did exactly this: took business rules written in MS-Excel by the biz users, wrote some scripts to convert Excel->XML, and our program worked with the XML 'rules' at runtime. Very nice that the drools people provide a standard way to do this.
  
  I'm stressing the business users because IMHO rules engines are supposed to make biz rules more maintainable. And one way I've see that work is if you can actually take what a business analyst gives you (eg: an Excel file) and convert it to a format that the program can use (eg: XML), with little or no programmer intervention. BUT if the programmer is just writing the rule in XML instead of Java, then... like you said, it's a skillset thing and that leads to other problems (a topic for a long blog entry ;-).
  
  http://blog.vikdavid.com/
• Business Users
  2005-08-05 00:21:11  paul_browne [View]
  
  

  I've also been very impressed by the Drools project in general.
  

  
  I wouldn't see Drools as 'program-in-XML-instead-of-Java' - the underlying approach is very different: With Drools you state what you know to be true , with Java you say exactly what you want done. The Drools approach can lead to more simple code (none of those messy , tangled , if..then statements).
  

  
  In an 'ideal world' not only could business analysts write rules (if they wanted to) , but other Analysts could use RAD Tools to develop the user interface (the market Visual Basic aimed at). The productivity gain comes from not waiting for a developer to translate requirements into code , with the possibility of making mistakes.
  

  
  In reality , there will always be requirements that need a Developer (such as writing rules against a Database). As ever , the balance of work between Developer and Analyst will depend on project, organisation and skillsets.
  

  
  Paul Browne
  

  
  http://red-piranha.blogspot.com/