О существенности в архитектуре
Как гласит стандарт 42010:2011, архитектура описывает существенные компоненты системы, но не существует единого понятия о существенности. В более поздней версии стандарта от 2022 года все фразы о существенности исчезли, но появилось слово "фундаментальные компоненты". Так как же на самом деле обстоят дела: архитектура описывает только существенные компоненты или все? "Все", "существенные", "фундаментальные" или есть другое прилагательное, которое ограничивает множество рассматриваемых компонентов предприятия?
Если признать, что архитектура есть модель, а значит уже по определению она является упрощенным описанием объекта реальности, то значит архитектура (арх.модель) содержит не все компоненты рассматриваемой системы (системы-предприятия). Почему таки не все?
- так как арх.модель создается зачастую как проект, то есть образ будущей реальности, имеющий целью принятие решений, то арх.модель будет содержать только то, что влияет на принятие решения. Скорее всего это будут самые дорогие компоненты или какой-то принципиальный стержень будущей конструкции.
- на отбор компонентов в архитектурную модель будет влиять точка зрения: кому-то важно видеть технологические компоненты, кому-то функциональные, кому-то информационные. Кто-то хочет убедиться лишь в замысле относительно того, почему будущая система будет достигать поставленные перед ней задачи.
- арх.модель содержит не всё, потому что абсолютно всё будут содержать чертежи (подробные чертежи) будущей системы или отдельных ее частей. Но как мы понимаем, чертежи тоже содержат только необходимые проектные решения.
- арх.модель может не содержать тривиального, всем известного, элементов контекста, так как группа моделировщиков спокойно держит это в голове, как совершенно очевидное.
- если арх.модель создается на готовую систему с целью описания/изучения готовой системы, то логика рассуждения остается той же, как описано выше.
Однако архитектурный репозиторий может содержать почти все компоненты предприятия, так как:
- арх.репозиторий объединяет в себе все модели, созданные для разных лиц и в разное время. То есть с течением времени описание предприятия становится более изощренным (особенно стабильного предприятия) и для новичка (или стороннего наблюдателя) такое описание может даже показаться избыточным.
- в том числе в арх.репозитории могут содержаться подробности уровня чертежей, если конструторы создают их средствами арх.репозитория. Например, диаграммы классов и UML SD можно отнести уже к подробностям конструкторского уровня детализации.
- в ходе описания архитектуры зачастую нет времени на отсечение несущественного: описывается всё, что попало в поле внимания архитектурной команды. О существенности тех или иных компонентов выводы будут сделаны позже.
- арх.репозиторий может содержать слои (каталоги), которые являются полной инвентаризацией какого-то фрагмента реальности. Например, для целей учета. С точки зрения архитектуры предприятия может быть неважно, сколько серверов находится в ЦОДе и сколько ЦОДов использует предприятие. Но для учета это важно, а сервера и ЦОДы рано или поздно будут связаны с виртуальными или программными компонетами, такими как операционные системы, гипервизоры, средства защиты и т.п.
- зачастую тщательная инвентаризация физических компонентов предприятия помогает упорядочить когнитивные компоненты. Например, если в арх.репозиторий заносят риски и требования, то важно привязать их к физическим или виртуальным объектам, подвергающимся риску или выступающим в качестве "приемников" требований.
А также существенное или несущественное определяется зачастую объемом памяти заинтересованного лица. ... и наличием инструмента, позволяющего упорядочить архитектурный контент. Существенность также меняется со временем: что вчера была важным, сегодня уже не важно - как равно и наоборот: вчера мы что-то игнорировали, как несущественное, а сегодня именно это приобретает первостепенное значение.


