“When a Loan Application comes in, make the application available to all of our Credit Officers who have sufficient Lending Authority to process the loan, and who haven’t already met their quota of applications for the week. Of course if everybody has already met their quotas for the week, then let everyone have an opportunity to work on the new application.One more thing, only a few of our Credit Officers can approve loans over $100,000, so don’t route low value loans to them unless they are the only available credit officers.
And don’t let anyone claim more than 3 applications at a time. Our Credit Officers are compensated for the number of loans that they process, and some of them will claim all the applications that they can in hopes of earning more money.”
This really sounds like a realistic task assignment to me. My point here is that it's impossible to capture this kind of logic in the business process diagram. It reinforces the message about process development that I've been giving for a long time. Analysts provide a description of a business process. Typically that is a diagram plus free text documentation like e.g. this kind of task assignment rules. Then it is up to the process developer to come up with an executable process that looks exactly like the business analyst's diagram, but this time it is an executable process. Iterative development can then be realised on the executable process. I don't believe that round tripping between analyst and implementation models is feasible for the majority of BPM use cases, especially if those turn out to be very different.
The second post that I refer to is Bruce Silver's BPMN to Requester: Get Outta My Pool. In that post, Bruce points out that BPMN swimlanes are in fact inspired by BPEL's partner links and that experienced business analyst have a hard time understanding those basics. In fact, I think the business analysts are right. Analyst models should not be constrained with executable details. If we want to create a notation that can serve analysts and process developers, then it should be nothing more but boxes and arrows. All the extra semantics that are added to diagrams only are targetted to either the analysts or to the developer. But those extra semantical decorations and concepts never make (the same) sense to both target audiences.
This really shows the scheziphrenic nature of BPMN. On the one hand BPMN aims to be a free modelling notation for business analysts. And on the other hand, it tries to map one on one to an executable service orchestration language like BPEL.
The task assignment example is indeed a valid one. But... would you want to do it with a 'processflow' (or a dsl based on an executable graph) or a rulesengine. I'd go for the latter but then again, that's just me
ReplyDeleteI'd go for latter too.
ReplyDeleteIt seems easier to add an eventual new requirement that says "unless there's more than X applications in the backlog then allow every officer claim 5 applications instead"
if it walks like a rule and talks like a rule... it must be a rule !
ReplyDeletemore seriously: your comments show that rules and process technology make it easier for business people to understand and discuss about executable processes and rules.
but the other way is not true. if a stakeholder can express rules in plain english, then it's typically not obvious how to implement them. this is true for both processes and rules.
my first guess would be to start looking at a rule engine for those requirements. but with my current (read: limited) knowledge of rule engines, i still have some big question marks in my head about how to shape these rule-sounding english sentences into drools rules that the drools rules engine can understand and performs well with.
The first time I read this post I thought that you'd left the workflow team and wanted to write rules instead :-)
ReplyDeleteSeriously , the example is very close to one that I use when talking about business rules. (If it makes you feel better I have loads of business rules examples that you'd say are really workflow!)
So that leaves us with two questions:
1) How can we combine the task assignment mechanism with Rules?
I think this would be easy to do, write a bit of Java code to pass the values into a rule engine (such as JBoss Drools) - good example at http://wiki.jboss.org/wiki/JbpmAndDrools, which talks about decision nodes but easy to modify for tasks
2) How do we write the Task assignment rules in a 'clear english'?
Couple of choices, but for this example I'd consider using an excel based decision table as a lot of the rules will be similar (e.g. all using loan value, if loan value greater than 100k go to person a , less than 20 go to person c etc).
Must tag this post and come up with a more comprehensive example in the future ....
Paul
Paul,
ReplyDeleteI would be interested to see John's example developed in rules.
John's example didn't say "if (condition) then assign it to that person". It specified rules on when you are elegible to take on a task.
The main thing that I don't yet see as an enthousiast rules beginner is how to avoid loading all of the employees as facts. Can that be avoided without changing the requirements ? Or would you think loading the whole identity store in a working memory is that feasible and scalable ?
I think that trying to draw a diagram in order to capture this logic is incorrect because diagrams typically are used for documenting coarse-grained components while your logic is pretty fine grained.
ReplyDeleteI would have inserted this logic into the process by a black box called `assigning loan to credit officer` and I would have delegated the implementation of this task to a developer to implement it as it sees fit (business rules, POJOs, etc...).
I find that it is important to choose the correct granularity when drawing process diagrams if only for the reason that trying to keep the documentation in synch with the code works well if the documentation is kept at a high level.
I have been visiting various blogs for my term papers writing research. I have found your blog to be quite useful. Keep updating your blog with valuable information... Regards
ReplyDeleteI see how technologically advanced devices have already started to change the way we live.
ReplyDeleteI am done in here after saying thanks for sharing and let other ones share too!