
It is obvious that the Software Architecture is not the real world architecture. It is a trend among software consultants to take appealing terms from areas they do not know and use them without understanding their meaning. "Experience", "lean", "kanban", "engineering"... The term "architecture" is one of this buzzwords.
There are a lot of definitions of "Software Architecture" but in most cases these are empty shells.
If you have a "Software Architect", if you provide courses for "Software Architects" and if you give certificates with a title "Software Architect" you must have at least one definition for the "Software Architecture". You can use unclear generalizations, cyclic definitions and meaningless words to construct one or several sentences that can be remembered and repeated by answering certificate exam questions.
The software literature is full of results of such exercises.
Of course there are a lot of definitions of the real world architecture but in most cases most people can agree that the architecture exists, that there are people who can be called architects and that it is usually obvious what can and what can not be called "architecture".
If you ask software people they not only provide different incompatible definitions of the term "Software Architecture" but they also would endlessly argue about cases when this term could be used.
It is intuitively clear that the software development must contain something analogous the real world architecture because this is also a process of building big complex systems. The problem is in the virtual nature of software. It is impossible to use direct analogies.
It is difficult to construct a productive definition but this is possible. I explain and extend some ideas from [1] a discussion in comp.software-eng "What is architecture?" and [2] my recent explanations in Russian.
It is true that the architecture is an overall view and a top most decomposition.
It is true that an architecture of something could be represented as a drawing. This is simple a projection of knowledge on paper. Not always this could be done in standard graphical representations but, if an overall view truly exists, it could be somehow projected on paper.
It is true that some high level design elements belong to the architecture and that they are usually incomparable in different software solutions.
The problem with these characteristics is their vague nature. Let's strip the final definition from all dependencies from specific contexts:
Architecture is a set of coherent interconnected irreplaceable decisions.
( Read more... )