Rob Vens blog posts (Clear the Fog) over the past year do seem slightly obtuse in some ways, but I guess that I am trying to dig into subjects that are not entirely mainstream, and architecture is already a rather ephemeral subject. Still, my eyes are apparently not open enough, as I see more fog than clarity.
However, there is one that sits squarely within my field of interest, Why use UML for business modelling, which is probably what led me to his blog in the first place. The article digs back into the history of modelling business activities, and looks at how they have resulted in the various languages, notations and methods that are being standardised more recently. His focus on object-orientation leads him to observe a number of drawbacks with the process-oriented approach, but unfortunately he fails to conclude with any solutions, or even avenues to explore. Perhaps there might be more clues if one shared his understanding of object orientation, as he summarises it in The Essence of OO
Interestingly, Rob suggests that process-orientation has been a drawback in effectively modelling businesses - he observes that this only came about because dataflow modelling was a common practice in IT, so the engineers could get away with applying those same tools to try and model business processes. I guess that I would contend that, from the point of view of wanting to make business support systems more efficient, it is crucial to look at the data flow that has been created, but I guess this comes down to an argument between purism and pragmatism - the desire to design a perfect system versus the concern with making step improvements in what has evolved up until now.
However, there is one that sits squarely within my field of interest, Why use UML for business modelling, which is probably what led me to his blog in the first place. The article digs back into the history of modelling business activities, and looks at how they have resulted in the various languages, notations and methods that are being standardised more recently. His focus on object-orientation leads him to observe a number of drawbacks with the process-oriented approach, but unfortunately he fails to conclude with any solutions, or even avenues to explore. Perhaps there might be more clues if one shared his understanding of object orientation, as he summarises it in The Essence of OO
Interestingly, Rob suggests that process-orientation has been a drawback in effectively modelling businesses - he observes that this only came about because dataflow modelling was a common practice in IT, so the engineers could get away with applying those same tools to try and model business processes. I guess that I would contend that, from the point of view of wanting to make business support systems more efficient, it is crucial to look at the data flow that has been created, but I guess this comes down to an argument between purism and pragmatism - the desire to design a perfect system versus the concern with making step improvements in what has evolved up until now.
No comments:
Post a Comment