Sunday, April 15, 2007
Thoughts on UML and Software Architecture
Figured I would expand upon James Tarbell and his thoughts on software engineering...
The notion of a common visual language is appealing yet I am disturbed to see that too many folks are placing too much responsibility on UML in terms of what it can and cannot do. The need for not one but multiple notations becomes apparent if you ever had the headache of attempting to describe an approach within a large enterprise. Communication happens not only via normalized notations such as UML which can be analogous to the symbols used in electrical engineering but also requires pretty little cartoons done up in Powerpoint.
Not sure if JT was thinking the same thing that I have but in the engineering profession, engineers aren't forced to change their notations to suit the consumer, rather the consumer is expected to understand the notation. I do not see this as reality in any large IT shop. In terms of notation, UML may be harmful in the long run especially if you consider folks are attempting to do perversions such as model driven architecture (MDA).
Both BPMN and UML have collectively encouraged something even more dangerous in terms of getting enterprise folks to think in a cookbook like manner where everything can be solved by the application of some more-or-less simple recipes. They don't want to deal with the fact that design entails hard work, creative inspiration, talent, experience, rework, hard thinking and more hard work.
I would argue with JT that I am not an Enterprise Architect but more of a strategist and a logic carpenter. Likewise, I would also tell him that he also isn't an architect nor engineer but more of an ecologist and gardener...
| | View blog reactionsThe notion of a common visual language is appealing yet I am disturbed to see that too many folks are placing too much responsibility on UML in terms of what it can and cannot do. The need for not one but multiple notations becomes apparent if you ever had the headache of attempting to describe an approach within a large enterprise. Communication happens not only via normalized notations such as UML which can be analogous to the symbols used in electrical engineering but also requires pretty little cartoons done up in Powerpoint.
Not sure if JT was thinking the same thing that I have but in the engineering profession, engineers aren't forced to change their notations to suit the consumer, rather the consumer is expected to understand the notation. I do not see this as reality in any large IT shop. In terms of notation, UML may be harmful in the long run especially if you consider folks are attempting to do perversions such as model driven architecture (MDA).
Both BPMN and UML have collectively encouraged something even more dangerous in terms of getting enterprise folks to think in a cookbook like manner where everything can be solved by the application of some more-or-less simple recipes. They don't want to deal with the fact that design entails hard work, creative inspiration, talent, experience, rework, hard thinking and more hard work.
I would argue with JT that I am not an Enterprise Architect but more of a strategist and a logic carpenter. Likewise, I would also tell him that he also isn't an architect nor engineer but more of an ecologist and gardener...
