[epf-dev] Mechanisms and other terms

[Christoph Steindl <steindl@xxxxxxxxxxxx>]

I've followed the discussion about architectural mechanisms. Let me 
throw in my 5 cents.

The goal is software that fills a need of the user.
On the way to the goal, we (as the developers) need to cope with the 
complexity.
If the complexity is overwhelming / doesn't easily fit into one mind, we 
(may) try to deal with complexity by modeling.
*) The waterfall model has distinct phases for analysis and design.
*) MDA has distinct platform independent and platform specific models.
*) Architecture is more abstract and long-living than design.
*) Design is more concrete and project specific.
*) Architecture can be project/solution specific or govern all 
projects/solutions within an enterprise.
*) Architecture has several views: software internal structure, 
operational structure, information structure,...
*) Scott Ambler has a lot of useful advice on agile modeling (model with 
a purpose, model to understand and to communicate,...)

With the end in our minds (one of Covey's advices from the 7 Habits of 
Highly-Effective People), we need the software, we may need some models.
But do we need to have analysis models? Do we need to have design 
models? Do we need to have an architecture that is more abstract and 
long-living than the design?
The answers may well be "yes", but that depends on the context / situation.

I think we shouldn't prescribe the way how to get from the requirements 
to the code via analysis => design => code.
We may show some typical roads to get there, but I wouldn't want that 
openUP readers/consumers/followers imply that they now need to do 
something in one specific way.

And even less would I want to add another term to the already confusing 
terminology in the analysis & design / modeling / architecture domain.

 Christoph