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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@IndustrialSoftwareArchitecture

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

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

@IndustrialSoftwareArchitecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изучение иерархичности начнем с ТРИЗ, а именно со знаменитого, даже гениального, системного оператора Альтшулера. Его также называют 9-ти экранкой или многоэкранной схемой мышления.

Перед этим приведу цитату из статьи "РАЗВИТИЕ СИСТЕМНОГО МЫШЛЕНИЯ – КОНЕЧНАЯ ЦЕЛЬ ОБУЧЕНИЯ АРИЗу (Альтшуллер Г. С., 1975, Баку).

«Качественное отличие талантливого изобретателя и состоит в умении видеть не только данную в задаче систему, но и надсистему и подсистемы:»

Понимаю, что для подготовленных людей этот материал может быть не интересен. Наберитесь терпения пожалуйста или пропустите. Одна из целей канала - пропаганда ТРИЗ в том числе.

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

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

Альтшуллер впервые предложил системный оператор в книге «Творчество как точная наука», 1979 г. Приведу несколько цитат и иллюстраций из этой книги: