In what respect the Workflow Way is a Blind Alley

REPLY TO DAVID CHAPPELL
(David Chappell & Associates)

I am commenting on a whitepaper by David Chappell, who explains the philosophy of Microsoft's latest version of Windows Workflow Foundation (www.davidchappell.com > Writing > White Papers > Windows Workflow Foundation > The Workflow Way: Understanding Windows Workflow Foundation), since this is a good example, how even experienced and carefully arguing technologists are stumbling over the threshold between technology and organization - across the border separating the strata of technology and organization, T- and O-stratum, respectivly.

TECHNOLOGY IS NOT SUFFICIENT

Why should we be concerned? Because, not handling properly the interplay of these two strata is at the root of the mis-alignment of IT to busisness – according to my opinion. In fact, IT and business are living in two fundamentally different, though inseparably connected strata, the T- and O-stratum, respectively. Thus, in order to achieve a seamless interaction of IT and business, we have to make sure that either respects the specific regularities of the other's stratum.

In particular, if computing technology is developing to Web-technology and, as such, is transgressing role and departmental scope to become operative in overall business (striving at so-called end-to-end applications, under the EAI/BPM/SOA-regime), technology is taken beyond the limits of T-stratum into O-stratum, and it is – therefore – exceedigly important to ensure that the basic rules governing the O-stratum are accounted for.

VOLITION UTTERANCE - VOLITION EXECUTION

Typically, software technologists, even if aware of the T/O-border's existence, do not pay proper attention to it, when designing programs and writing code. This might be due to a lack of knowledge, of how the T/O-border is appearing in code. To get control of this issue, think of programs – of their code – as manifestations of human volition utterance. Think of developers as trying hard to keep hold of humans' volition utterance, by casting it in a proper code-construct. Typically, volition-utterance is de-composed into elementary volition-acts, which in turn are re-composed by means of so-called application logic to match the original utterance.

After the elementary volition acts have been 'coded', and the application logic, assembling the corresponding code parts, has been stated in terms of straight-forward control-flow components, we are on the safe territory of T-stratum – and need not care about whatever 'deviant' features of the O-stratum. This is true, as long as we limit our attention in software manufacturing to human volition utterance, which - however - is only part of the overall volition reification, required as a pre-condition for automation by means of computing technology.

Obviously, volition reification consist of two parts: (a) volition utterance, and (b) volition execution. Now, ordinary program code can capture volition expression only, never volition execution. You may write as many sophisticated programs as you like, nothing at all will happen, as long as you do not start processors, capable of executing your programs, thus making volition execution, in itself, happen.

From this reasoning, a caveat derives: To capture volition reification properly, i.e., completely, including utterance and execution, always consider 'program & processor' as an inseparable complex. (In fact, neither a program without a processor, nor a processor without a program will make volition automation happen as a real-world event.)

THREADING

Thus, a software product, to be fully operative, cannot be restricted to program-code, it must include processor-design, as well. Of course, I am not speaking of the processor as a piece of hardware, but as a topic relevant for software development. From this point of view, the relevent feature of a processor is that it is running threads – a single pocessor is running one thread at a time.

Thus, a software developer to fully cope with human volition reification has to capture two things: volition utterance in terms of executable code, and volution execution in term of starting threads in which the code executes. In short: a full fletched software developer, besides coding, must do 'threading'. But, how does threading look like?

SINGLE-THREADED VERSUS MULTI-THREADED APPLICATIONS

If volition utterance can be executed by a single processor, running a single program from its beginning to its end, without interruption, we have the single-threaded case. The corresponding, single-threaded, program does not have, in its code-body, any explicit reference to volition execution. Its code is not addressing any processor to be started, thus no threading. Only the thread, in which the program's own execution is happening, must be kicked off. But, of course, the volition-execution act required to start this thread, is external to the program. The developer need not care about particular O-stratum features correlating with thread-starting (threading), since this is a matter of program-usage, not program-design.

If, on the other hand, the thread, in which an application is starting, is handing over control to one or more additional threads, i.e., if an application is multi-threaded, the starting of additional threads (threading) is managed by progam code. In this case, the developer is writing program code that explicitly addresses at least one thread and processor. Now, starting threads, corresponding to volition-execution acts, is no longer external to the application and its developers. It's now part of their responsibility.

This means, that in the multi-threaded case, developers are not merely dealing with volition utterance, but also with the execution-component of human volition, in terms of thread-starting (threading). Thus, writing program-code for multi-threaded applications implies that coding volition-utterance is complemented by something like coding threading, i.e., something like organizing volition-execution. Multi-threaded software development, inevitably, penetrates O-stratum territory.

WORKFLOW TECHNOLOGY IS ABOUT THREAD MANAGEMENT

The issue is, that today's developers do not pay attention to their operating in the O-stratum. They do hardly account for the specific rules of the O-stratum. To me, it seems that here we are at the root of the mis-alignment misery. What kind of rules are these? And why is it detrimental to ignore them?

The answer is, that in a multi-threaded application we deal with two or more volition execution acts, refering to the same problem (whose solution is to be supported by the intended application). In general, if there are several volition acts addressing the same problem, there is some conflict potential, calling for organization to grant coordinated volition execution in favour of uninterrupted workflow.

PROPER AND IMPROPER THREAD-MANAGEMENT

In fact, the written and un-written rules, governing the O-stratum, are all about the coordinated interplay of volition utterance and execution, which a priori are potentially diverse. Effectively, O-stratum rules give rise to a subtle balance between governed (dirigistic) cooperation and self-organized collaboration, a balance fundamental to corporate identity and success.

If developers write multi-threaded programs, interspersing 'coding' with 'threading', without paying due attention to O-stratum rules, chances are that balance of dirigistic cooperation and self-organized collaboration is perturbed. In fact, by means of coded volition-execution, i.e., hard-coded threading, it's only possible to automate dirigistic cooperation, never self-organized collaboration, to the effect, that inevitably collaboration will be repressed in favour of more cooperation of assembly-line character.

The lesson to be learned is: If writing multi-threaded applications, always treat the code-parts, starting a new thread, with the greatest care possible by asking explicitly, whose volition is going to be executed by the thread under consideration, and how this volition is related to volition-execution by all other threads of the application, including the principal thread, which starts the application as a whole.

WINDOWS WORKFLOW FOUNDATION - ASSESSMENT

If you now look at Windows Workflow Foundation, Microsoft's flagship developer-tool for writing multi-threaded enterprise applications (counterpart of Oracle's BPM-Suite), you will find that even in the latest version, WF4, there is no support at all for such a practice. In fact, the workflow designer of WF4 handles threads like any other 'activity', simply as a technological component.

While in WF4, there is a separate technology for threating (workflow, workflow-coding language XAML, and workflow-runtime), the rules for workflow-coding are much the same as those for activity coding: just ordinary programming rules - though 'coding' thread-starting properly must take into account O-stratum rules and, therefore is basically different from ordinary T-stratum coding.

In summary it can be stated that WF4 is deficient, because of its lack of any technology to account for O-stratum compliant threading.

GETTING THE WHOLE PICTURE

Coming back to David Chappell's whitepaper, I am asking myself, why does he not address this severe shortcoming of WF4? Why is he speaking, instead, of "the beauty of the workflow way"?

Of course, it's a rhetoric question, since David gave me his answer, some years ago, during one of his shining talks at the 'World-Trade Center' at Zurich-Oerlikon. In a personal discussion, when I brought up an organizational (O-stratum) issue, he conceded: Well, you are considering the whole picture, while I am speaking here about technology.

Today, in regard of David's WF4 whitepaper and my above reasoning, I would respond: You may well restrict your reasoning to technology, but you will miss the whole picture ...

... so urgently required to assess the quality of multi-threaded enterprise applications and their impact on productivity and creativity.