![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_r
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.
Decisions are the most abstract level of the process of creating. The results of decisions and the artifacts that document them could be entirely different in the real world and in software projects but the nature of decision making process could be quite similar.
It is important to consider only irreplaceable decisions. It is simple to adjust some elements of facade decorations or slightly change the positions of some internal walls. In case it is needed to change the size of all windows, to replace the material of the walls, to reduce the number of floors or to move the whole building we can say that the architecture has changed.
Of course anything is possible but almost all such changes are very expensive after the start of a construction process. Let's consider the decisions being irreplaceable, if they cannot be corrected without breaking the limits of provided budgets.
Architectural decisions are connected to each other and to obvious and hidden information. The size of a basement depends of the height of a building. Internal walls depend on the positions of windows and windows are placed considering the possible positions of internal walls. The heights of floors and the sizes of windows must be in harmony to create a pleasant facade. An architect does not draw canalization and water pipelines in the architecture sketches but they must be considered to make it possible to add them by the clarification of each floor plan.
This all must be coherent. This means all decisions must support each other or at least the decisions that ware optimized for conflicting goals must not cause insolvable conflicts.
The "mathematical" definition of the Software Architecture has the following interesting consequences:
- The Software Architect is a person who makes important decisions that define the success or the failure of a project and could infect the result with incurable illnesses.
- All errors in the Software Architecture must be corrected in the design phase because the wrong decision could not be replaced without throwing away the results of work that is based on them or depends on them.
- Even agile projects have architectural decisions within them but the importance of these decisions is hidden.
- Agile development considers all decisions easy to change but the hidden architectural decisions are irreplaceable. Agile managers demand to build new solutions upon the work that is already done. To correct architecture it is necessary to throw away big amount of written code that depends on a wrong architectural decision. Nobody dares to allow this in an agile project.
- Agile development states that the main goal could be reached by planing of small sprints but hidden irreplaceable architectural decisions made in a such step based on limited information and forced by time constraints to be hasty are interconnected with other decisions that were made and that would be made in future iterations. Even if this connections are unknown for agile developers and agile managers they cause conflicts between different parts of a system, degrade the overall performance and produce other incurable problems.
- Agile will destroy the world.
(frozen) [1]a discusion in comp.software-eng "What is architecture?"
Date: 2018-10-30 12:12 pm (UTC)Subject: What is architecture?
Date: 1997-11-06
Message-ID: <63t9ma$r0a$1@rational2.rational.com>#1/1
Organization: Rational Software Corporation
Newsgroups: comp.software-eng
From: seri...@aha.ru (George Seriakov)
Subject: Re: What is architecture?
Date: 1997-11-08
Message-ID: <3465847b.1746277@news.aha.ru>#1/1
Newsgroups: comp.software-eng
From: seri...@aha.ru (George Seriakov)
Subject: Re: What is architecture?
Date: 1997-11-09
Message-ID: <34672449.3153116@news.aha.ru>#1/1
Newsgroups: comp.software-eng
(frozen) [2] Цитаты из диалога с juan-gandhi
Date: 2018-10-30 12:12 pm (UTC)Все дома разные и по-разному покрашены, но мы говорим, что архитектура есть.
И, естественно, архитектура (которая архитектурная, строительная) - это не наука.
Грубо говоря, архитектура - это то, что можно нарисовать.
Чего для софта практически никто не умеет. Но это не значит, что это невозможно. Просто это nontransferable knowledge.
Графическое выражение - это просто проекция, необходимая для понимания иерархий и связей. Она может быть сколь угодно детальной. Главное, чтобы была возможность сквозного перехода от частностей к общему и обратно. Архитектура - это представление высшего уровня.
Дело в том, что объём внимания ограничен, потому всё надо выкладывать на бумагу.
Люди, способные работать только левым полушарием - ущербны. Правое было настроено на выживание в 3D мире. При построении связей мозг всё равно рисует картинки. И, кстати, 3D диаграммы - это очень круто и удобно. Но с возможностями их построения всё ещё хуже, чем с 2D.
И не надо ограничивать изображение архитектуры популярными языками моделирования. Если читать мой блог, то можно было давно понять, что я приравниваю UML к диверсии.
Проблема с UML не в сложности, а в том, что его подогнали под потребности производителей тулов, поломав по дороге всё остальное.
no subject
Date: 2018-10-30 02:49 pm (UTC)no subject
Date: 2018-10-30 06:07 pm (UTC)The last sentence must be removed in a public version. ;-)
TNX.
no subject
Date: 2018-10-31 09:42 am (UTC)If this (yanking away chunks of source code) doesn't happen quite often, then the project is not agile. It may be called agile, though, but it may be called anything else too.
Here is a quote from the agile manifesto: "Continuous attention to technical excellence and good design enhances agility". So I'd say agile per se doesn't stop anyone to have software projects architected properly. But how you oppose "agile" to "software architecture" is very funny because these were precisely the arguments for taking agile "approach" back then (cca 2001, iirc).
no subject
Date: 2018-10-31 10:14 am (UTC)big amount of written code != chunks of source code
Do not mistake small changes that cost several hours with complete rewriting of something that costs many man months.
It may be called agile, though, but it may be called anything else too.
Yes. Did you not know that modern "agile" is not agile and that it ignores important principles of the agile manifesto?
no subject
Date: 2018-10-31 11:55 am (UTC)Well, I didn't specify the size of the "chunk", so no mistake at all. In fact, this is how I usually develop, by completely rewriting parts of the system if they do not fit my "naturality" criteria, so after several iterations you have something you can rely on.
> modern "agile" is not agile
This is what I've been saying for quite a long time, and, in fact, I'm going to discuss it with our agile "enablers" and "couches", by making them read and comment the agile manifesto as a start.