Долгое время единственным ISO-шным стандартом по архитектуре оставался ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture description. Он даже был переведен в 2016 году на русский язык и выпущен как ГОСТ Р 57100 Системная и программная инженерия. Описание архитектуры. Переведен он был не очень хорошо, но предоставлял основания использования подходов из международного стандарта 42010.
В 2019 году появились сразу два новых архитектурных стандарта 42020 и 42030 (Architecture processes и Architecture evaluation framework). Про двадцатый стандарт я обязательно напишу более подробно в одном из следующих сообщений. Как выглядит архитектурный процесс и как он вписывается в другие активности и виды деятельности – вопрос важный. Но здесь я в большей мере хочу акцентироваться на влияние двух этих стандартов на 42010. Этот стандарт тоже обновился в ноябре прошлого, 2022 года. (ссылка на актуальную версию)
Кстати, по ссылкам, которые я привел выше, доступны короткие preview документов. В частности, десятый стандарт включает краткий обзор изменений и основные определения. А я постараюсь дать свой обзор случившихся изменений.
Начнем с предмета стандарта. Предыдущая версия посвящена архитектуре системы. Стандарт 2011 года определял описание архитектуры системы, архитектурный фреймворк и язык описания архитектуры. Система, вернее системы, остались в названии стандарта, но исчезли из определения архитектуры. Сравните:
architecture fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes
вместо:
architecture (system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
Система поменялась на entity, элементы и отношения между ними исчезли, дизайн поменялся на реализацию, зато появилась завязка с процессами жизненного цикла. Вообще, определения в архитектуре — это то, что трогать следует в самую последнюю очередь. С ними и так немереное количество проблем. А когда они начинают меняться… Единственное, что может как-то нас обнадежить, так то, что еще лет десять потребуется на обновление этого определения во всех связанных c ним работах. Посмотрим, когда это случится, например, в TOGAF (ссылка на определение).
Кто такой entity объясняется ниже. В разделе 3.12 приводится такой список примеров entities: enterprise, organization, solution, system (including software systems), subsystem, process, business, data (as a data item or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, product line, family of systems, system of systems, collection of systems, collection of applications. Ну, а в названии стандарта список покороче: программное обеспечение, системы и энтерпрайзы. Все перечисленные выше вещи и раньше можно было трактовать как частные случаи систем. Но новая версия стандарта явно обозначило своё право предписывать пути развития архитектуре ПО, архитектуре предприятия, solution архитектуре, ну и всему остальному заодно. Теперь и без подсказки системного инженера мы будем знать, что все это примеры систем, а их архитектура описывается обсуждаемым стандартом
Вообще, толкованию термина архитектура много внимание уделено в стандарту о процессе 42020. Причем в разных местах документа. Во введении см. 0.2 Use of the term architecture in this document поясняется, что термин архитектура может быть использован в общем смысле или уточнен тем или иным квалификатором (system, enterprise,…). Но иногда рядом с термином архитектура используется не наименование той или иной сущности, а subject of interest, например: security architecture, functional architecture, etc. А еще бывает, что перед словом архитектура указывается purpose, как в выражении integration architecture. Но еще более интересный разговор про виды и типы архитектур ожидает нас в приложении E.4 Architecture kinds, views and style. Во-первых, это перечисление и описание разных типов архитектур: референсная(эталонная), целевая, доменная, системная, текущая и даже архитектура данных. Во-вторых, список архитектурных представлений (views): концептуальное, функциональное, логическое, физическое и т.п. И наконец, (сюрприз-сюрприз) список архитектурных стилей: client server, event-driven, layered, object-oriented и даже service-oriented… Разве что микросервисной архитектуры нет.
Но вернемся к стандарту на описание архитектуры. Следующее изменение, случившееся в новой редакции, это расширение истории про архитектурные представления (views) и точки зрения(viewpoints) концепциями aspects и stakeholder perspectives (cм. картинку выше). Первое, что следует отметить про понятие перспективы, это то, что они отличаются от понятия перспектив из известной книжки Rozanski N., Woods E., «Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives». Стандарт говорит, что разные заинтересованные лица часто объединяются в группы на основании ролей, опыта, схожих предрассудков суждений и всяких прочих характеристик. Именно такая группировка, возникающая как общность способа осмысления системы (извините, entity) в контексте и называется перспективой. В примеры уходить не буду, обращу лишь внимание на то, что в одном из многочисленный приложений к стандарту ставится знак равенства между слоями-уровнями нотации Archimate и перспективами в обсуждаемом стандарте (см. картинку ниже). А вот аспектами в ISO 42010 называется, как правильно заметил проницательный читатель, столбцы этой самой картинки.
На сегодня стоит, пожалуй, остановиться. 42-ой стандарт никогда не являлся простым и развлекательным чтением. Но в наше время, вплетенный в систему других стандартов, он превращается в настоящий квест. Оставим блуждание по 10-му стандарту на потом, а в следующий раз, как я и обещал, погрузимся в 20-ый стандарт, описывающий процессы энтитийной архитектуры.