Re: Re: Decision Trees and the Strategy Design Pattern

To clarify, the data is the process definitions, or the rules that govern what happens under which circumstances. The code is spread between the workflow engine and process state tracking. That's definitely a helpful way of looking at it, although writing an engine to parse a custom rule-set is (I believe anyway) a very serious undertaking. But maybe that's why you're suggesting a compromise between a full workflow engine and hardcoding behavior? That feels right to me, especially since I strongly advocate the "build one to throw away" school of thought, and this is a first brush at something that will likely be reworked at some point.

I liked this quote from that IBM document: "Effective workflow processes have three basic components: data, process logic, and a directory of participants." (pg. 2)

Thanks diotalevi.

Comment on Re: Re: Decision Trees and the Strategy Design Pattern

Replies are listed 'Best First'.
Re^3: Decision Trees and the Strategy Design Pattern by diotalevi (Canon) on Dec 26, 2002 at 21:40 UTC
Yes well... for my paid work (which rarely involves perl) I have an fully functional Domino installation to fall back on where our directories are integrated with our Oracle HR databases. When I'm writing a workflow-enabled Domino application the who-when question is mostly separate from the how-what questions. So an Authorization to Spend/Buy/Sign form has a whole bunch of functionality related to it's function as a form. It's sort of like really smart paper - it does lots of fancy stuff but in the end it only goes where people send it. When I add in Lotus Workflow then I describe the connections between the various states, what the person must do (a check list), what decisions the person must make, any timing related issues, etc. All of that is contingent on having a good directory. So it can tell that Ricky Ricardo/IT/SomeCompany is Marvin Martian/DSP/SomeCompany's manager, the team Marvin is on, etc etc. A basic implementation would have to use roles or titles or some way to flexibly define the workflow participants. In no uncertain terms let me stress that you don't ever put people's names into a process. You put things like "Workflow Development", "Corporate Auditor", "Global Purchasing Manager". The idea is that these labels are determined by your HR-bound directory so you maintain your process just by keeping your HR records up to date. Let me know if you want more information - this is my day off and I'm tired of typing this just now. Update: Oh yes, I suggested a comprimize because a real workflow implementation is a decidedly non-trivial task and requires first-hand experience to get right. Fun Fun Fun in the Fluffy Chair	[reply]

Replies are listed 'Best First'.

Re^3: Decision Trees and the Strategy Design Pattern
by diotalevi (Canon) on Dec 26, 2002 at 21:40 UTC

Yes well... for my paid work (which rarely involves perl) I have an fully functional Domino installation to fall back on where our directories are integrated with our Oracle HR databases. When I'm writing a workflow-enabled Domino application the who-when question is mostly separate from the how-what questions. So an Authorization to Spend/Buy/Sign form has a whole bunch of functionality related to it's function as a form. It's sort of like really smart paper - it does lots of fancy stuff but in the end it only goes where people send it.

When I add in Lotus Workflow then I describe the connections between the various states, what the person must do (a check list), what decisions the person must make, any timing related issues, etc. All of that is contingent on having a good directory. So it can tell that Ricky Ricardo/IT/SomeCompany is Marvin Martian/DSP/SomeCompany's manager, the team Marvin is on, etc etc. A basic implementation would have to use roles or titles or some way to flexibly define the workflow participants. In no uncertain terms let me stress that you don't ever put people's names into a process. You put things like "Workflow Development", "Corporate Auditor", "Global Purchasing Manager". The idea is that these labels are determined by your HR-bound directory so you maintain your process just by keeping your HR records up to date. Let me know if you want more information - this is my day off and I'm tired of typing this just now.

Update: Oh yes, I suggested a comprimize because a real workflow implementation is a decidedly non-trivial task and requires first-hand experience to get right.

Fun Fun Fun in the Fluffy Chair

[reply]