Monday, January 01, 2007

Rules with no code - Michael Neale

Often you hear/read/see adds for tools (rules or workflow) that claim breathlessly "look ma ! no code" - "rules with out code" - giving control back to the business etc.

(if you haven't, then you obviously have a good marketing detector, and are able to mentally filter out marketing messages). Some products live up to this impossible claim more then others (and some a despicable lies, of course never in the rules community !).

An impossible claim? What did you say?

I say "impossible" in the sense of the definition of "Code" as it appears in the adds. If you take code to mean "ascii or UTF-8 files written in a textual programming languages with file extensions like .java, .c, .rb, .py, in an IDE or programmer focused editor" then I would say its not impossible. But what is "code" really? Lets presume it means a programming language (as opposed to "The Davinci Code"). What is a programming language? Basically symbolic instructions for a machine to understand that makes it do something (I am sure many folks can come up with better definitions). Who said these instructions had to take ascii form? a visual graph (a la jBPM, a JRules decision tree or a Corticon "rule sheet" for instance) could be thought of as "code" itself.

To some this may be irritating semantics, but to less technical people its important to understand what they are getting into. So I should clarify, even when you are using "no code" you are still using "a code" - its just a higher level sort. In many cases this is a Good Thing ! But people do need to still think logically, without ambiguity or woolly headed-ness - machines just will not tolerate it !

I have seen great demos of tools by Corticon (they use clever techniques with a visual decision table metaphor, but its more then a decision table), and I hear good things about Haley Adviser for natural language. I saw great demonstrations of Rule Burst's document based rule management, JRules supports multiple textual and visual rule metaphors with a myriad of smart editors. All really great tools of course, but in their own way, still "a code" is being authored, its just a code (programming language) that is higher level, and close to the domain and perhaps in a more natural or visual form then "ordinary code". You can't wave your hand at these tools and magically have consistent rules (maybe you can in the latest versions ;). You still need to be logical - the tools will do a lot of the heavy lifting, but precision is still required from you, the user, in your logic and intent, and design decisions.

To burst a few bubbles, no one will EVER have true free form natural language for rules. For starters, we don't have exhaustive technology to make computers understand natural language without a very very narrow scope. But MORE SIGNIFICANTLY, even if we did, we would still not have NL rules. Why? because our human languages are deeply flawed, in terms of logic. So even if we technically could have NL rules, other then a few spectacular (and possibly dangerous) failures they would be abandoned in favour of a controlled language of some form.

Have you ever given detailed instructions to a builder for your house renovations, yet still been disappointed? (ask Mark !). Natural language is not a language of logic, or accurate specification of instructions.

As a kid I used to earn pocket money by typing up papers for my father (who is a lawyer) and became familiar with various styles of legal language, legislation (as well as my fathers handwriting, which was much harder). They are worded in a very very formal way, yet fail to come even close to the accuracy of logic that symbolic programming languages provide (and they are not readable other then by experts) - most legislation needs to be tested in courts to be workable, it needs Explanatory Memorandums to patch up the gaping holes etc. This is not what people want when they talk about natural language rules, or "rules with no code".

In summary, whatever your tool of choice, you will still be using "a code" of sorts, and you will not be able to provide the vague sort of instructions to a rule document authoring system that you used to email to assistants, and hope it to work. That is not to devalue these tools at all, its just reality.

And happy new year ! Welcome to the world of tomorrow !



  1. Hi Michael,

    There are a couple of hypes in BR. One of them is "no code". These hypes may attract people's attention but surely will hurt BR in long run.

    On the other hand, low level code is not acceptable for non-programmers. I'm looking farward to seeing the product you are developing.

    Happy new year!


  2. Good stuff. A rule set consumed by a rules engine is code. It may be procedural or, as in Rete engines, it may be based on set-based pattern matching (like SQL or XSLT). However, it is absolutely a form of code, and a rule developer is a programmer who needs to learn the language and work out the best techniques and patterns for solving real-world problems.

    I work in a BPM/integration environment where we typically use rules engines in the context of encoding ‘business rules’. I sometimes try to communicate the true nature of rule sets by stating that the rules we execute through a rules engine ARE NOT the business rules. They may be closely aligned to business rules. There may, in some cases, even be a one-to-one correspondence between an identified business rule and an executable rule or rule set. However, executable rules are not business rules. They are code artefacts. This implies that there will always be a technical design and elaboration stage between the capture and definition of business rules (by business analysts and users) and the design and implementation of executable rules by a rules developer. It may, in some cases, be possible to automate the generation of executable rules or, more commonly, to parameterise executable rules in such a way that changes to business rules can be made by business analysts/users and reflected in executable rules without further intervention from developers. In my experience, though, this is often not the case, or has only limited applicability.

    The hype is often misleading. The central value proposition of rules engines lies in being able to more closely align our code with business requirements and to externalise executable rules in order to make maintenance and change easier to handle. Good toolsets that help to manage the divide between business rules (often expressed in NL) and executable rule sets are central to exploiting rules engine technologies.

  3. This comment has been removed by the author.

  4. I agree but that does not mean that you cannot make some of the rules manageable without code. I think business rules can help IT avoid write-only code and that you can develop rules so that business users can maintain them. I don't think you can do "rules without code", nor do I think it is even necessarily worthwhile to try. I do think rule maintenance without programmers is worthwhile though.
    P.S. Blaze Advisor, Fair Isaac's product, supports all these various metaphors too (decision tables, decision trees, scorecards, templates).

  5. Hi Micheal,

    I am developing a tool to write rule files (drl files).I have done that to some extent.Now i am doing the reverse engineering of the tool..i.e., reading the drl plan is to convert it in to an xml file and read the rules from xml..coz i thought tht would be easy and i don't see any examples or demos for drldumper or drl parser or xmldumper..can you advice me on this....high priority


  6. All good comments. I certainly agree with James comments about "write-only-code". There is no escape from thinking logically, at least until we have true "sci fi" type AI ;) but we can absolutely do a lot more with rules then just with code.