Workflow versus Dataflow – Imperative versus declarative

[Dan]

I have seen some comments to the article:
http://www.udidahan.com/2011/07/13/the-danger-of-centralized-workflows/
and I have been stimulated to create this new topic.

Quote from the article: "It starts with the very nature of workflow –
a flow chart, is procedural in nature. First do this, then that, if
this, then that, etc. As we’ve experienced first hand in our industry,
procedural programming is fine for smaller problems but isn’t powerful
enough to handle larger problems. That’s why we’ve come up with object-
oriented programming."

It is very interesting. This guy says that a flow chart is procedural
in nature. I think it is so misleading and this is one of the biggest
mistakes when thinking about flow.
Now I have to admit that the author did not use the term "data flow"
but "workflow". We have to analyze what is the difference between
"workflow" and "dataflow".

Among several definitions, I have chosen one from wikipedia:
"A workflow consists of a sequence of connected steps. It is a
depiction of a sequence of operations, declared as work of a person, a
group of persons, an organization of staff [...]".

You can find various definitions but all of them have some key point
in common. Guess which one it is? ... "sequence of operations,
declared as work of *a single entity*" (person, microprocessor,
whatever else)".

A data flow diagram on the other hand, as we know it from FBP, is not
a sequence of operations, declared as work of a *single entity*. Each
"operation" has the input and outputs clearly separated and it is
executed in a distributed manner. It means it could be executed by one
or more entities but logically each component is executed
independently than all the others. Going further, logically, each
atomic component is executed independently on all the others (because
a component is composed of subcomponents and so on until we reach the
atomic level).

I have specified *logically* because it is what we try to simulate. If
we have a single processor available then we have to map the execution
of all the components on the only processor available but this is
another related subject.

This is not just a difference in perception. It is the difference
between imperative and declarative style of programming. The
difference is the same: in imperative style you tell to a single
entity what to do. You have to sequence all the operations that will
act on the matter (variables). In declarative style you describe the
structure of the system (structure of processors and pipes that tell
how the matter flows). Then you simulate (run) this structure using
the available computing resource(s).

The author's conclusion is amazing: "That’s why we’ve come up with
object-oriented programming."
Well, I will not argue here what is OOP versus FBP. This is a large
topic.

The author continues with: "I have yet to see an object-oriented
workflow drag-and-drop engine. Yes, it works great for simple demo-
ware apps. But if you try to through your most complex and volatile
business logic at it, it will become a big tangled ball of spaghetti –
just like if you were using text rather than pictures to code it."

The author admits that an object-oriented workflow drag-and-drop
engine is hard to create or to use but it does not give us an answer
to the question why. The problem here is those guys try to do an
*object-oriented* workflow engine/editor in the first place. It is
wrong because it is OOP.

Because I don't want to divagate here I will mention what I have said
in other occasions: OOP has a lot of problems among which the biggest
one is common to all imperative languages (functional languages are
included too): the callee has to return the result to the caller
instead of passing the result along to the component that really needs
it (asynchronously). Calling methods is not like passing messages.

I would like to know your opinions on the subject “imperative versus
declarative”. It seems this is a subject that is so misleading among
programmers. Because it is an important topic I have created a new
post.

Regards,
Dan Pologea

[Dan]

Making it short: the FBP component IS the processor.

[Paul Morrison]

Dan, I absolutely agree with you that the caller/callee model is
inadequate for the real world, but I wouldn't make too much of the
first few lines that you quote from the Wikipedia article - further on
it says, "More abstractly, a workflow is a pattern of activity enabled
by a systematic organization of resources, defined roles and mass,
energy and information flows, ", and it gives examples such as, "In
machine shops, particularly job shops and flow shops, the flow of a
part through the various processing stations is a work flow." I have
always seen an FBP diagram as applying equally to departments
exchanging information, or even to companies, nations, etc. As Wayne
Stevens said, FBP provides a consistent application view from very
high level to very low level! And, as you say, the statements you
quoted about OOP are totally off-base - although, if OOP had actually
implemented the message-passing approach that the early designers
talked about, maybe we would have had an FBP world decades earlier!
Smalltalk started the whole misperception as it talks about "sending
messages", but they are really linearized calls...

[Aristophanes]

(continued after fat fingering)

When the master component has sent all of the tasks it sends the
application to a component that puts all of this stuff together. The
various departments send their completed documents to the "put it all
together" component when they are done. In the meantime the master
has gone on to the next mortgage application.

Does this make sense or am I hopelessly naive?

[Aristophanes]

Crap! I hate computers. Google just lost the first part of this
message. Points. (1) The article is talking about the workflows in
Microsoft's Windows Workflow Foundation. (2) Procedural vs OO is a
red herring. (3) By calling rather than message passing WWF and its
ilk are doing the equivalent of blocked writes. The upshot is that is
that WWF have to have all of scheduling in the code. (4) A lot of the
stuff that is in those workflow flowcharts should be in tables. (5)
It is critical that documents (information packets) have unique
originals with references being passed.

The flow chart is from a mortgage application processor. I suggested
that in FBP the master would receive a mortgage application, create
documents for each task area (financing, inspection, title work, etc)
and send them to the various tasks.

[Paul Morrison]

IMHO Aristophanes, that is beautiful! You might also have to have an
overseer task that tells you which task areas for a given mortgage
have been completed - but not in which order to do them - so that a
human supervisor can see how many of the mortgage tasks have
completed, and see if there is a hold-up somewhere. Someone (human or
machine) could even assign more processing power (human or machine) if
there is congestion somewhere... The basic logic you describe is much
like what happens in an FBP network or subnet...