Stefan Tilkov's Random Stuff

Web Services Process State

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?

Comments

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.