This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Web Services Process State

Stefan Tilkov,

Radovan elaborates on what he means by “Process State”, using a software product release cycle as an example. I really like this analogy, since it’s easy to relate to it :-)

I believe the essence of what he’s saying is in this paragraph:

Instead, I focused on capturing various communication channels, put them into process (release cycle) context, and let people and applications communicate via a ‘process-aware data broker’. All the ‘message exchange’ is captured and general rules/constrains/policies defined are over them.

I think this deserves a bit more detail for this to really become clear. Based on earlier discussions I think what he’s getting at is that it’s the deliverables that are important, not the detailed steps used to create them. Thus, a process state in his definition — when it’s completed — would actually be (or be composed of) all those deliverables. And these deliverables have to appear in a certain order, have dependencies to each other, are created automatically or manually … Correct?

On April 20, 2004 12:11 AM, Neil Earnshaw said:

Your last paragraph makes it sound a lot like Jim Highsmith’s Workstate Life Cycle Management in Adaptive Software Development, chapter 9.

From p 237: The key to scaling up extreme projects is to apply increasing rigour to the result, that is, to the workstate rather than to the workflow.

On April 20, 2004 8:43 AM, Stefan Tilkov said:

Indeed, that seems very similar (thanks for the reference). The question, to me, is whether this is a general principle that could be applied to any sort of process - and the more I think about it, the more I tend to agree with Radovan that trying to define a rigorous process, including all possible exceptional states, is extremely hard to do once you start addressing real world problems.