Действительно, как мы уже говорили, существует множество определений системной инженерии. Также существует и множество определений сложной системы.

Приводить разные определения сложной системы и выполнять их анализ я не буду.

Вместо этого дам несколько ссылок на работы, где такой анализ уже проведён, перечислю наиболее часто встречающиеся характеристики сложных систем, выскажу свою точку зрения и предложу определение, которое мне видится наиболее прикладным в контексте «Промышленной архитектуры»

Итак, сложные системы.

Ёмкий, как мне кажется, обзор эволюции «сложная система» понятия дан в статье:
«Эволюция понятия «сложная система», Ознамец Владимир

Процитирую ряд важных для нас выводов:

«В настоящее время понятие сложной системы от абстрактной или технической формы приобретает комплексный аспект с учетом когнитивных и ресурсных факторов.

Понятие сложной системы приобретает социальный аспект и аспект саморазвития.

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

Современное понятие сложной системы ставит несколько задач.

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

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

Современное понятие сложной системы включает фактор жизненного цикла и человеческий фактор.»

Для нас эти выводы очень важны.

В «Промышленной архитектуре» будут даны ответы на вопросы:
- Как строить самоорганизующиеся программные системы?
- Как делать качественные описания систем?
- Какой жизненный цикл у инженерных систем?

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

В последние годы на хайпе эволюционная архитектура. На Английском “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

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

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

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

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