There are currently 6 responses to “Please don’t just “unify” rules and process”

Why not let us know what you think by adding your own comment?

1. 1 On November 19th, 2007, Mark Proctor said:

   One of the beauties of a unified modelling environment is you get to choose how you want to model things. Just because you can model and deploy everything on a single engine session, doesn’t mean you have to - you get to model your environment how you like from a collection of fully stateless services to a single fully stateful session and all the variations in-between - all with the unified tooling, apis, deployment and management - not forgetting the advantages of unified auditing frameworks, when Mr Sarbanes Oxley comes calling. I’m not pushing one approach to solving enterprise problems over another, but I am pushing the idea to give the user a choice to make those decisions themselves. You want a rule centric view of your current model, you got it, you want a process centric view of your model, you got it, you want something in-between, you got it - it’s the users choice they know their requirements best. It’s my fault in being ambiguous with my frustrations, after all blogs are just informative rants My frustration wasn’t with SOA and decision services which is why I say “Not to mock this model, as it is actually quite useful” but more that the industry stops here, when more can be achieved. I don’t want to go to FileNet for my workflow and Ilog for my rules, meaning I have to learn and manage two ways to deploy the stuff, two different apis and two server side management systems and have my interoperability points limited to the integration that those two companies thought to provide - and suffer from impedance miss matches else where. And when you start to take a more unified view of things it starts to allow for some more interesting behaviour, that would also be valid in SOA environments too. Rules and processes are inextricably linked; you simply cannot have processes without rules of some level, while rules can do without processes there are many types of problems that are hard to solve cleanly without them (which is why many rule companies are introducing simple ruleflow capabilities).

   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

2. 2 On November 20th, 2007, Marcus said:

   The very limited analogy of looking at rules and processes together being akin to unifying UI and databases hurts your credibility quite a lot in this discussion. I could break it down objectively, but it would probably be a rant.

   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.

3. 3 On November 20th, 2007, Mark Proctor said:

   heh cool, sounds like someone gets it yes I believe there is a lot more overlap than people initially realise - not just at the user end, but also in the underlying frameworks - building, compiling, variable scoping, action execution, management, deployment, configuration etc it the same foundations for both systems. Yes rules and processes have different lifecycles, this doesn’t prevent that. What we are proposing is not a single DSL, but multiple DSLs with tight integration points and sugar to auto leverage complimentary parts when needed - in fact ruleflow groups encourage the extraction of the rule logic from the process logic and would easily allow the process and the rule logic to change at separate and different times, this is even possible in a single stateful engine. Look at the image link below, to see how ruleflow encourages rule and process separation, while still leveraging the advantages of a unified environment:
   http://labs.jboss.com/file-access/default/members/drools/images/ruleflow_numberguess.png

   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

4. 4 On November 21st, 2007, David Wright said:

   Mr. Proctor,

   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.

5. 5 On November 23rd, 2007, ILOG BRMS Blogs » Blog Archive » On Unified Rules and Processes said:

   [...] Mark Proctor and Kris Verlaenen have posted an interesting description of JBoss’s vision for unifying rules and processes. I have to say that on this debate I think I broadly side with James Taylor, who has also posted a response. [...]

6. 6 On January 9th, 2008, EDM should be a top priority for CIOs in 2008 | Smart (Enough) Systems, the blog said:

   [...] effective management are powerful tools for improving business processes. I have blogged about this before and that post generated some interesting comments. Automating and managing decisions can [...]

Leave a Reply