1) What does the business get or see from your approach? Can business people manage their rules and decisions directly or do they have to depend on a modeling expert?

2) I would simply state that everything is inextricably linked, one could say that rules and data are are more tightly linked than rules and process, given the similarity of data models and terms & facts models. I know you don’t want separate process and rule platforms, do you want to get rid of separate data platforms as well? If it is the nature of the marketplace that today there are separate process products and separate rules products, that will change when vendors realize that it makes sales sense to combine them as a product, and I think recent purchases/mergers are showing this to be happening already. Still, some customers may prefer ‘best-of-breed’ solutions and want to integrate the whole themselves. There have always been pros and cons to both approaches beyond this domain, and I can’t see anything yet that will change the minds of those who favour either approach.

Anyway, my 2 pennies/pence worth.

The best thing is we don’t need to stop at rules and processes, CEP is coming next. The most important thing though is we have to make sure that unification does not mean “limiting”, i.e. I don’t want to include something and it becomes lesser than if it was standalone - I don’t believe our current plans and designs break that. We will of course be vigilant about that level of stupidity.

What becomes interesting is as you build these new layers it enables you to see and implement further interesting behaviour, that you wouldn’t have done if the techs where standalone. For instance typically rules do not fire more than once, if their data does not change - with a process, as long as the rule is true, you may want it to execute on each iteration. It introduces new behaviour for timers and I’m sure more sugar goodness will become obvious over time. With CEP this becomes even more so, compared to StreamingSQL. I’m not saying we have all the answers, heck a lot of this is gut feeling and finger in the air stuff - but it seems to be working so far, so we’ll keep pushing this direction and hopefully something good will come from it.

The other nice thing, if you target the MVEL dialect for any written action scripts, is you build a declarative application that will in theory execute on .Net or Java - there is a Drools.NET port, via the IKVM project, although it hasn’t been updated to 4.0 yet - hopefully our current work will invigorate new interest in the community maintaining the .Net port.

Mark
http://blog.athico.com The Drools Blog

Anyone who has worked with both rules engines and bpms stares directly at the overlap every day. Finding the right amount of overlap seems to be a pretty valuable exercise.

Right now DSLs are a fad in dynamic languages. I’m going to go out on a limb and suggest that many of those are bpms combined with rules engines in disguise, and go even further out to say that the evolution of those very quickly should steer away from embedding in host-language source code. In that light, rules plus processes without a host-language hack is pretty interesting. Especially once some more water is under the bridge and we’ve learned a few lessons about when and where its appropriate to draw the line.

So I agree with you on the importance of SOA and decision services, sorry I phrased my frustrations badly in the blog. What I’m proposing does not limit any of the bulleted points you make on decisioning, in fact it enables them. But I don’t agree with your view that unifying rules and processes is like unifying the UIs and Databases, the two are very complimentary with lots of overlap - but luckily I’m willing to put my money where my mouth is, so watch this space The important thing is we need to push our understanding and vision in these areas, R&D has moved far too slowly in the rules industry and we have to push the boundaries and see what falls out.

Mark
http://blog.athico.com The Drools Blog