#дляайтишников

В последние годы на хайпе эволюционная архитектура. На Английском “Evolutionary architecture”.

Эволюционные архитектуры нужны для построения самоорганизующихся систем.

#дляайтишников

Бубны износились

Мы подойдём к построению эволюционных архитектур с помощью инженерии.

#тизер

И снова тизер, самоорганизующиеся системы - самые живучие, наиболее устойчивые к изменениям, в том числе в условиях неопределённости.

Сегодня нужны именно такие системы.

И да, такие системы почти всегда сложные.

#отсебя #дляайтишников

По моему сугубо личному мнению, известные книги из серии “Building Evolutionary Architectures” не дают ответы, как строить самоорганизующиеся системы.

Весь их смысл де-факто редуцирован до Алертов, которые называют фитнес-функциями.

Во всяком случае, при обучении инженеров на материалы этих книг лично я опираться практически не могу. Если конечно не брать во внимание несколько вернеуровневых идей.

После обсуждения решили, что неверно называть программные системы самоорганизующимися.

Во всяком случае до тех пор, пока их разрабатывают люди.

Мы будем говорить об архитектурах программных систем, которые способствует самоорганизации каких-то других систем, уже сосциотехнических, частью которых программные системы могут являться.

Возможно стоит говорить о самоорганизации в Software Intensive Systems.

Перевода пока не нашёл подходящего.

Из обсуждения:

«Из IEEE1471-2000:
A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole»

Также приведу несколько заключений из статьи: “Определение понятия «сложная система» в контексте науки устойчивого развития”, Глаз Роман Алексеевич

«Так, сложные системы имеют следующие отличительные особенности:
1. Любая сложная система является и большой;
2. Любая сложная система имеет эволюционное развитие;
3. Любая сложная система характеризуется наличием большого количества уровней, на которых может быть рассмотрена (например, экосистема, лес, дерево);
4. Любой сложной системе присущи паттерны формирования»

Далее автор ссылается на работы И.Н. Глухих и В.Н. Чернышева и указывает на существование прямой взаимосвязи между сложностью и размером системы:
«Любая сложная система является и большой. Для сложной системы предлагаются следующие характеристики: 
- сложность назначения и многообразие выполняемых функций;
- большие размеры системы по числу элементов, их взаимосвязей, входов и выходов;
- сложная иерархическая структура системы, позволяющая выделить в ней несколько уровней с достаточно самостоятельными элементами на каждом из уровней, с собственными целями элементов и особенностями функционирования;
…»

Автор данной статьи отдельно отмечает, что есть и авторы, которые «называют главной характеристикой сложной системы наличие у нее подсистем.»

В своих исследованиях с такой точкой зрения я тоже нередко встречался.

Заметьте, до сих пор я не привёл определения сложной системы. Я сделал это намеренно, потому что не нашёл определения, которое, на мой взгляд, было бы достаточно прикладным, чтобы использовать его в обучении.

При этом, как мне кажется, уже сформировалось понимание необходимости изучения таких важных вопросов, как самоорганизация, иерархичность, качественное описание и жизненный цикл.

В контексте этого канала, то есть “Промышленной архитектуры”, сформулирую определение “сложной системы” опираясь на когнитивный фактор. И в первую очередь, на определение сложности, которое этот фактор учитывает.

Разумеется, есть множество определений сложности. В нашем случае буду опираться на следующее определение:

“Сложность (complexity): Свойство системы или компонента, имеющих устройство, исполнение или поведение, трудные для понимания или верификации.”, ГОСТ Р МЭК 61513-2011 (IEEE 610)

Поскольку мы говорим об архитектуре программных систем, то для нас:

Сложная система — это трудная для понимания система, которую невозможно исследовать, моделировать, проектировать и описывать без применения методов управления сложностью, таких как декомпозиция, абстракция, моделирование, иерархичность, модульность и системное мышление, чтобы с наибольшей вероятностью обеспечить её успех.

Мы все эти методы рассмотрим отдельно и будем их использовать при решении задач по проективанию архитектуры «Промышленных программных систем». И конечно рассмотрим разные паттерны их формирования и не забудем про эволюционное развития.

Чтобы идти дальше, нужно поставить точку в вопросе, инженеры ли архитекторы программных систем, или нет.

На этот вопрос можно найти ответы в статьях инфлюенсеров, но цитировать их я не буду, потому что мне не удалось найти ни одного убедительного ответа.

Чтобы ответить на вопрос, инженеры мы или нет, нужно сначала разобраться с понятием инженерной системы. Ведь инженерные системы по определению должны строить инженеры.

На мой взгляд, хорошее определение инженерной системы есть в SEBoK:

«Инженерная система - конкретная система, состоящая из технических и/или социотехнических элементов, имеющая системно-инженерный жизненный цикл.
Инженерные системы создаются людьми и для людей, и направлены на удовлетворение интересов заинтересованных сторон»

https://sebokwiki.org/wiki/Engineered_System_%28glossary%29

В этом определении следует обратить внимание на два аспекта: жизненный цикл и заинтересованные стороны (стейкхолдеры).

Мы будем регулярно упоминать жизненный цикл и детально рассматривать взаимодействие со стейкхолдерами, их идентификацию и выявление их потребностей.

Можно сказать, что типовой жизненный цикл систем в системной и программной инженерии состоит из следующих этапов:

- Анализ и проектирование
- Конструирование
- Тестирование
- Эксплуатация
- Техническое обслуживание
- Вывод из эксплуатации или замена.

Однако в программных системах всё сложнее.

Отдельные элементы программной системы могут развиваться независимо.

Одни элементы могут находиться на стадии проектирования, а другие уже могут быть выведены из эксплуатации.

Более того, одни и те же элементы могут находиться на разных этапах жизненного цикла.

Какая-то версия элемента может проектироваться, более ранняя версия — находиться в разработке (конструировании), а ещё более ранние версии — одновременно эксплуатироваться, например, для обеспечения обратной совместимости.

@IndustrialSoftwareArchitecture

Можно сказать, что программные системы одновременно находятся в прошлом, настоящем и будущем.

А приведенный выше (системно-инженерный) жизненный цикл справедлив для отдельных версий элементов системы.

@IndustrialSoftwareArchitecture

Иллюстрация из концепции Цифрового двойника информационных систем