Showing posts with label workflow. Show all posts
Showing posts with label workflow. Show all posts

Tuesday, June 07, 2005

Workflow

Nick Malik (Microsoft) asks for feedback input on a workflow component he is working on. Are groups responsible for business processes?

If you are assuming that one instance of the workflow engine handles the entire business process, then perhaps you can afford to be prescriptive. But if you want to allow federation or interoperability between workflow engines, then you probably want to allow some flexibility about the handover from one engine (instance) to another. For example, this might mean that engine A regards the entire group as responsible for something, while engine B manages intra-group delegation and accountability. And this also seems to reflect more accurately the way management processes often work in large organizations.

Tuesday, October 19, 2004

Workflow considered harmful

Nick Malik raises a concern about workflow notations – both BPMN and UML – that they permit good and bad structures.

I don't think this is a problem. I don't want a notation to prevent me modelling something that some noble committee deems wrong or inelegant.

Most importantly, I want to be able to use these notations to describe AS-IS as well as TO-BE. If a legacy system has a poor structure, I don't want my modelling tool to turn its nose up, I want my modelling tool to roll its sleeves up and help me sort out the mess.

But what I definitely do want is a notation that helps me to reason about the structural qualities of a given solution. One of the problems I have with UML is that any structural flaws of a solution are not clearly visible.

We use different maps for different purposes. One map for car journeys, and a different map for finding minerals. UML is useful for some purposes, but it simply isn't very good for thinking about structural qualities.