Архитектура, архитектор, его взаимодействие с инженерами

В курсе "Системное мышление 2020" рассказывается, что такое архитектура системы. Но не могу сказать, что после прочтения написанного в курсе для меня абсолютно ясно стало, что такое архитектура и кто такой архитектор. Попробую разобраться в этом.

Есть такой комитет, ISO/IEC JTC 1/SC 7 Software and systems engineering, который выпускает различные стандарты по программной и системной инженерии. Комитет выпустил несколько стандартов касающихся архитектуры:

  • ISO/IEC 26552:2019 Software and systems engineering — Tools and methods for product line architecture design
  • ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture description
  • ISO/IEC/IEEE 42020:2019 Software, systems and enterprise — Architecture processes
  • ISO/IEC/IEEE 42030:2019 Software, systems and enterprise — Architecture evaluation framework

Безусловно, все эти стандарты мы тут рассматривать не будем, да и не читал я их особо, только 42010 по диагонали. Но зато теперь мы знаем, что можно изучить, чтобы точно уже разобраться, что же такое архитектура, как правильно ее составлять (т.е. как правильно принимать важнейшие решения по устройству системы), и как правильно ее описывать.

По ISO 42010 архитектура это (определение копирую из учебника СМ) "основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития".
Если идти по материалам курса, то архитектура это важнейшие решения об устройстве системы.
Итого можно сказать:

  1. Архитектура - это шаг в сторону устройства системы, рассмотрения ее как прозрачного ящика.
  2. Архитектура это только о самом важном. Что такое это "самое важное" описано в курсе, не будут цитировать его.
  3. Архитектура это про выделение элементов системы (если точнее - подсистем).
  4. Архитектура это про отношения между элементами системы (подсистемами).

Хорошо, какую-то чуйку (увы, пока что только чуйкой и будем обходиться, ясности 100% все равно нет) относительно того, что такое архитектура мы вроде бы сформировали.
Но кто такой архитектор? Этот вопрос достаточно хорошо раскрыт в статье https://larionov.pro/ru/articles/2019/what-is-it-architect/.
Статья базируется на определении ИТ архитектора, данного в своде знаний по IT архитектуре - ITABok - https://itabok.iasaglobal.org/itabok/
Если коротко, то модель взаимодействия архитектора, инженера по требованиям и разработчика примерно следующая.

Инженер по требованиям получает на вход бизнес-требования. С учетом некоторых принципов и ограничений он превращает бизнес-требования в (1) модели уровня реализации, (2) описания уровня реализации, (3) требования к ПО.
Для инженера по требованиям принципы и ограничения - данность, он ими не управляет. Ограничения возникают в связи ранее принятыми решениями (выбранным стеком технологий, например). Принципы нужны, например, для того, чтобы решение соответствовало стратегии предприятия, дальнейшим планам развития, было масштабируемым. Принципы устанавливаются командой, а именно - ИТ-архитектором.
То есть ИТ архитектор этот такая роль, которая посредством (1) принципов проектирования ПО, (2) высокоуровневых моделей, (3) высокоуровневых описаний преобразует видение бизнеса, его стратегию и планы развития в рабочие продукты проектирования программного обеспечения. Причем такого программного обеспечения, которое соответствовали бы стратегии бизнеса, планам по развитию, было масштабируемым и т.д.

Изображение взято с https://larionov.pro/ru/articles/2019/what-is-it-architect/

Если переложить слова "высокоуровневые" на слова из курса СМ, то это будут архитектурные модели, архитектурные описания. То есть самые важные модели и описания, изменения которых приведут к изменению многих других частей системы. Вот мы и снова пришли к тому, что архитектура - это про самое важное. Но теперь мы еще можем сказать, что ИТ Архитектор - это тот, кто берет самое важное в бизнесе и перекладывает в самое важное в программном обеспечении.
А инженер по требованиям, в отличии от архитектора, берет менее важные части бизнеса и перекладывает в менее важные (слово "рабочка" из курса СМ) части программного обеспечения. Т.е. те части, изменения которых не приведут к изменению множества других частей.

Для меня чуть-чуть яснее стало, что такое архитектура и кто такой архитектор. Надеюсь, для вас тоже :)

Артём, спасибо за такое разложение, интересно продумать в таком ключе.

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

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

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