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.
No comments:
Post a Comment