Modelling business workflow is *hard*

[timasmith]

I just cant seem to get my head around this. I've tried a few
approaches without any warm fuzzy feelings. Here is the gist of the
problem

a) Forget about simple workflow - we can all do that
b) Forget about wizards, they rarely reach the complexity level
b) We need workflow, generally defined as a state diagram, where moving
from state to state can be due to
i) User choices
ii) System configuration
iii) System response due to state
c) There could be as many as 15 states with 2-3 possible transitions
from state to state
d) Many of these states will be represented to the user through a
graphical interface
e) Workflow might be implemented with a thin or fat client and so
should be devoid of user interface references
f) Workflow definition should create a contract that implementation
must adhere to
g) Workflow should be easily extensible and/or modifiable without
breaking deployed configurations.

So far I can think of the following implementations

a) Hard code every possible workflow, assign each an identifier and
users choose which one to enact. Almost impossible with large state
diagrams.

b) Define all options and write a single hard coded client based
workflow which can traverse the entire state diagram. Not bad, but
difficult to extend due to complexity of reading the mass of code.
Difficult to inspect code and understand how you arrived at any state.

c) Users write an XML document against an XSD to represent the workflow
desired. Difficult to define in XML I expect.

d) Users write the desired workflow in a scripting language. API
changes will break this approach, requiring revalidation.

e) Users write code against a small API to compile time validate the
workflow. Not bad, API changes are obvious. Code would probably have
to be deployed to the clients.

What does everyone else think?

thanks

Tim

 

[EventHelix.com]

b) Define all options and write a single hard coded client based

workflow which can traverse the entire state diagram. Not bad, but
difficult to extend due to complexity of reading the mass of code.
Difficult to inspect code and understand how you arrived at any state.

You can implement the state machine as a hierarchical state machine.
This will let you extend the client much more easily. The following
article might help:

http://www.eventhelix.com/RealtimeMantra/HierarchicalStateMachine.htm

 

[Frans Bouma]

I just cant seem to get my head around this. I've tried a few
approaches without any warm fuzzy feelings. Here is the gist of the
problem

a) Forget about simple workflow - we can all do that
b) Forget about wizards, they rarely reach the complexity level
b) We need workflow, generally defined as a state diagram, where
moving from state to state can be due to
i) User choices
ii) System configuration
iii) System response due to state
c) There could be as many as 15 states with 2-3 possible transitions
from state to state
d) Many of these states will be represented to the user through a
graphical interface
e) Workflow might be implemented with a thin or fat client and so
should be devoid of user interface references
f) Workflow definition should create a contract that implementation
must adhere to
g) Workflow should be easily extensible and/or modifiable without
breaking deployed configurations.

So far I can think of the following implementations

a) Hard code every possible workflow, assign each an identifier and
users choose which one to enact. Almost impossible with large state
diagrams.

I don't know how you would implement a state machine but I would use a
transition table. State + event == next state. This means that you can
use generic code for running the state machine and simply have to
adjust the transition table. You then could add some more info to the
transition table to use it as well for the viewer.

After all, workflow can often be implemented as a statemachine, if not
always.

b) Define all options and write a single hard coded client based
workflow which can traverse the entire state diagram. Not bad, but
difficult to extend due to complexity of reading the mass of code.
Difficult to inspect code and understand how you arrived at any state.

c) Users write an XML document against an XSD to represent the
workflow desired. Difficult to define in XML I expect.

d) Users write the desired workflow in a scripting language. API
changes will break this approach, requiring revalidation.

e) Users write code against a small API to compile time validate the
workflow. Not bad, API changes are obvious. Code would probably have
to be deployed to the clients.

It's betacode, but you could have a look at Windows Workflow
Foundation in the beta of .NET 3.0, it contains alot of the tools/api's
you need for your app.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[??super]

text

 

[Rick Elbers]

Op 28 Jul 2006 17:01:06 -0700 schreef (e-mail address removed):

I just cant seem to get my head around this. I've tried a few
approaches without any warm fuzzy feelings. Here is the gist of the
problem

a) Forget about simple workflow - we can all do that
b) Forget about wizards, they rarely reach the complexity level
b) We need workflow, generally defined as a state diagram, where moving
from state to state can be due to
i) User choices
ii) System configuration
iii) System response due to state
c) There could be as many as 15 states with 2-3 possible transitions
from state to state

Are you considering states and activities or only states and
transitions ?

This seem like an awful lot of independent states, you might indeed
consider hierarchical states as another poster advised.

d) Many of these states will be represented to the user through a
graphical interface

And require activities. No matter what exact way the activity is
monitored by the gui.

e) Workflow might be implemented with a thin or fat client and so
should be devoid of user interface references

ofcourse. But you can make the gui handle the activities and state
representations in your workflow model ...

f) Workflow definition should create a contract that implementation
must adhere to

ofcourse. How about workflow history and workflow changes in the
future ?

g) Workflow should be easily extensible and/or modifiable without
breaking deployed configurations.

How exactly is this ment. What should exactly be extendible what
modifiable and what not and to what extent ? This kind of requirements
are very expensive and should be used with extreme care imho. Make an
analysis of workflow changes in the past few years and of the expected
changes in the next few years. Then make an abstraction of your
current workflow model which encapsulates both. Then consider the
difference and
the cost versus gain of the more abstract model.

So far I can think of the following implementations

TO soon To soon. What you miss is your domain modelling and object
design. See below your message for additional comments.

a) Hard code every possible workflow, assign each an identifier and
users choose which one to enact. Almost impossible with large state
diagrams.

Ofcourse not. The idea alone beats every oo concept and every aspect
of good workflow for the worker.

b) Define all options and write a single hard coded client based
workflow which can traverse the entire state diagram. Not bad, but
difficult to extend due to complexity of reading the mass of code.
Difficult to inspect code and understand how you arrived at any state.

Also not ofcourse.

c) Users write an XML document against an XSD to represent the workflow
desired. Difficult to define in XML I expect.

Might or might not help, but its an implemenation issue..

d) Users write the desired workflow in a scripting language. API
changes will break this approach, requiring revalidation.

Same as above. Degrees of freedom for the worker ?

e) Users write code against a small API to compile time validate the
workflow. Not bad, API changes are obvious. Code would probably have
to be deployed to the clients.

What does everyone else think?

thanks

Tim

Tim I would estimate that what you miss is a few handy domain
concepts. A state is normally a state of some object. That object
encapsulates some state changes. Ergo if you do domain modelling and
object design I think a few of your problems will have dissapeared
includiing the most hard and expensive ones( extendability fi).

 

[H. S. Lahman]

Responding to Timasmith...

I just cant seem to get my head around this. I've tried a few
approaches without any warm fuzzy feelings. Here is the gist of the
problem

a) Forget about simple workflow - we can all do that
b) Forget about wizards, they rarely reach the complexity level
b) We need workflow, generally defined as a state diagram, where moving
from state to state can be due to
i) User choices
ii) System configuration
iii) System response due to state
c) There could be as many as 15 states with 2-3 possible transitions
from state to state

That is a bit scary. When state machines get that complex it is
difficult to get them to interact properly with other state machines and
it is difficult to maintain them. I would seek a way to either break up
the work flow into more manageable pieces or abstract it differently...

d) Many of these states will be represented to the user through a
graphical interface

The user view and the software view are two different things. The user
view is driven by UI design issues for user friendliness while software
view is driven by the need to solve some specific problem efficiently
(e.g., manipulate work flows). Both views will be anchored in the
problem space but they do not necessarily have to be the same.

Suppose in your situation different users will want to manipulate
different workflows. Then the problem solution needs to raise the level
of abstraction and model the fundamentals of workflows so that one can
handle the different user workflows through things like object,
relationship, and attributes instantiation and initialization.

For example, one might be able to recast the workflow state machine into
individual objects and some sort of Strategy pattern delegation:

[WorkFlowProcess]
| 0..1
|
| R1
|
| starts at
| 1 * R2 executes 1
[WorkFlowElement] ------------------- [WorkFlowRole]
| 0..* | 0..* A
| | transitions | R3
| | to +---------+----....
| | | |
+---------+ [ActivityA] [ActivityB]
R4

Here the R4 relationship captures the notion of sequence connectivity in
the workflow graph while the various [WorkFlowRole] objects represent
some fixed set of possible work flow activities that the user assigns to
[WorkFlowElements] when creating a workflow graph.

[Obviously, I don't know anything about your specific requirements so
the example is purely speculative. I am just trying to make a point
about there being different ways to abstract the fundamental problem.]

e) Workflow might be implemented with a thin or fat client and so
should be devoid of user interface references

That's really an OOD architectural decision. The basic problem solution
for functional requirements at the OOA level does not care about things
like fat vs. thin clients. However, you are going to have to make that
decision before you get to OOP.

f) Workflow definition should create a contract that implementation
must adhere to
g) Workflow should be easily extensible and/or modifiable without
breaking deployed configurations.

So far I can think of the following implementations

a) Hard code every possible workflow, assign each an identifier and
users choose which one to enact. Almost impossible with large state
diagrams.

Yech. The problem solution definitely needs to be at a higher level of
abstraction than that. You should look for way to encode invariants
while relegating detailed differences to parametric data. [My blog has
some examples in category of Invariants and Parametric Polymorphism that
may be of interest.]

b) Define all options and write a single hard coded client based
workflow which can traverse the entire state diagram. Not bad, but
difficult to extend due to complexity of reading the mass of code.
Difficult to inspect code and understand how you arrived at any state.

But such traversal is less difficult if the state diagram is recast into
a tree or network. IOW managing traversal is easier if one things of
workflows in terms of graphs rather than state machines because one can
employ standard traversal algorithms.

c) Users write an XML document against an XSD to represent the workflow
desired. Difficult to define in XML I expect.

I take it that the user does define a unique workflow. The
initialization of that workflow is really a UI issue. There are many
ways to represent the work flow. Regardless of what representation you
use in the UI, all you need is an unambiguous mapping to whatever
representation you use in the problem solution. XML may or may not be
the best way to do that; it really depends on what one needs to
represent and how one handles identity.

d) Users write the desired workflow in a scripting language. API
changes will break this approach, requiring revalidation.

Yech**2. The goal is to make life easy for the users, not turn them
into programmers. Use basic UI design to define a view that the user
will find most convenient. Then solve the real problem the user wants
solved at an appropriate level of abstraction. Finally, ensure that
there is an unambiguous mapping between those views and write an
interface between the UI logic and the solution logic in the client that
provides that mapping.

e) Users write code against a small API to compile time validate the
workflow. Not bad, API changes are obvious. Code would probably have
to be deployed to the clients.

Same as d.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
(e-mail address removed) for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

 

[AndyW]

What does everyone else think?

thanks

Tim

Why not try using DFDs

 

[Chiappone]

I just cant seem to get my head around this. I've tried a few
approaches without any warm fuzzy feelings. Here is the gist of the
problem

a) Forget about simple workflow - we can all do that
b) Forget about wizards, they rarely reach the complexity level
b) We need workflow, generally defined as a state diagram, where moving
from state to state can be due to
i) User choices
ii) System configuration
iii) System response due to state
c) There could be as many as 15 states with 2-3 possible transitions
from state to state
d) Many of these states will be represented to the user through a
graphical interface
e) Workflow might be implemented with a thin or fat client and so
should be devoid of user interface references
f) Workflow definition should create a contract that implementation
must adhere to
g) Workflow should be easily extensible and/or modifiable without
breaking deployed configurations.

So far I can think of the following implementations

a) Hard code every possible workflow, assign each an identifier and
users choose which one to enact. Almost impossible with large state
diagrams.

b) Define all options and write a single hard coded client based
workflow which can traverse the entire state diagram. Not bad, but
difficult to extend due to complexity of reading the mass of code.
Difficult to inspect code and understand how you arrived at any state.

c) Users write an XML document against an XSD to represent the workflow
desired. Difficult to define in XML I expect.

d) Users write the desired workflow in a scripting language. API
changes will break this approach, requiring revalidation.

e) Users write code against a small API to compile time validate the
workflow. Not bad, API changes are obvious. Code would probably have
to be deployed to the clients.

What does everyone else think?

thanks

Tim

Well I can't read all the posts right now, so I sorry if I say here
something already said above.

I am working with Businessware Vitria right now. Unfortunatelly, there
is a few professionals to help on it.
If you are working on a project that can handle an expensive software,
I think you should try it.

 

[Chris Uppal]

So far I can think of the following implementations

a) Hard code every possible workflow, [...]

Or a small domain-specific language ?

I'd take a look at some of the scores of pre-existing workflow engines for
ideas and common practices. E.g. this page lists >20, and it restricts
itself to freeware engines in Java -- which by no means exhausts the space of
possible implementations.

http://java-source.net/open-source/workflow-engines

(Server was /very/ slow responding as I type this in, but it was OK
yesterday...)

-- chris