Mark Proctor, he of Drools fame, posted today on his vision for unifying rules and processes. Not content with describing me as “large” and “infamous” in a previous post, now he has to get my blood pressure up with this new post! Seriously, though, I am going to disagree with Mark’s basic premise.
For starters, the reason for focusing on stateless decision services is that such a model is a good fit with how companies handle decision-making in operational systems. Decisions:
- Are not always tightly coupled with processes
- Often change on a very different cycle than the processes that use them
- Often have a very different complexity level
- Are managed/understood by users quite differently
While it may, intellectually, be interesting to consider them both forms of declarative programming, I am not sure such a collapsed view of the world is useful. After all, if I must be able to unify rules and process, why not unify user interface and database too? Why propose only a partial platform? Why not just endorse the Oracle-platform-for-everything approach?
If the “superficial” level of integration he mocks is not enough, are we to assume he dislikes SOA as an architectural approach? Surely the level of integration between business processes and services implicit in the decision service approach is the same as that between services in SOA? Would he argue that we need a unified model across all services? Isn’t that what we already tried when we built monolithic applications? I believe that both business process management and decision management are part of what is needed to build composite applications on a service-oriented framework. Collapsing the two seems both unnecessary, in a composite world, and unhelpful.
I don’t disagree that many processes could benefit from the inclusion in the process engine of a more robust rules capability. I just don’t think this replaces the need for decision services managed and developed independently from the process. As Jim Sinur, said when he was at Gartner “Rules that are encased inside business processes are stealing business opportunities that depend on speed of change”.
This is a regular topic on my various blogs so here are some other links with my POV:
- Business Rules, Business Decisions, Intelligent Processes, Enterprise Decision Management
- Why you SHOULD loosely couple processes and rules
- BPM in 2007 and beyond
- Don’t over-synchronize processes and rules
- Live from Business Rules Forum – Business Process Management with Business Rules and Business Intelligence
- Separating rules and process (Sandy Kemsley)
What do you think?
Comments on this entry are closed.
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
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.
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
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.