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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@IndustrialSoftwareArchitecture

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

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

@IndustrialSoftwareArchitecture

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

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

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

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

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

Значит, архитекторы программных систем — это инженеры.

Все кто занимается инженерным делом и строит инженерные системы, инженеры.

Почему возник вопрос: «инженеры ли мы»?

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

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

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

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

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

Пока скажу только одно: с моей точки зрения, профессионал — это искусный мастер. То есть человек, который очень хорошо, профессионально умеет что-то делать.

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

А что же дальше?

Мы рассмотрим важнейшие свойства систем: иерархичность и самоорганизацию. Затем разберёмся со стейкхолдерами.

И после этого приступим к моей самой любимой теме: моделированию и моделям.

Почему порядок именно такой?

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

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

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

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