Системная архитектура

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

Аналогичные проблемы касаются любого описания архитектуры. Думаю, тут надо внести некоторую определённость. Тем более, что ГОСТ Р 57100 - 2016 "Системная и программная инженерия. Описание архитектуры" вносит терминологию, которая больше запутывает, чем проясняет ситуацию. 

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

Стандарт ISO/IEC/IEEE 42010:2011 (перевод которого нам преподносят в виде ГОСТ Р 57100-2016) даёт такое определение архитектуры: 

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.

В переводе ГОСТа это выглядит так:

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

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

Тут надо дать ремарку. Указанный стандарт и его ГОСТовская реинкарнация имеют в виду архитектуру системы с преобладанием программного обеспечения. Учитывая тренд на повышение роли аппаратного обеспечения, а также облачных технологий, это определение становится всё более размытым. Окружающая среда теперь - не только операционная система или СУБД. Это целый комплекс технических и технологических средств.

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

Самая большая проблема определения из стандарта ISO/IEC/IEEE 42010:2011 - неясность, что является архитектурой, а что - нет. Определение слишком абстрактное. Где граница между архитектурой и реализацией системы?

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

Но тут возникает сложность. У будущих пользователей системы есть одни ожидания, у их руководителей - другие. Архитекторы предприятия требуют, чтобы выполнялись требования взаимодействия с существующей инфраструктурой. Системные администраторы нуждаются в возможности мониторинга работоспособности. Ещё есть технологические ограничения, ограничения по времени реализации, бюджету, и ещё куча всего. Как сделать систему, которая удовлетворяла бы всем эти требованиям? Ведь удовлетворение предъявленных или подразумеваемых ожиданий всех заинтересованных лиц и является качеством системы.

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

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

И, как писали Дино Эспозито и Андреа Сальтарелло, "Что же такое хорошая архитектура? Это архитектура, в которой все твёрдые решения, которые трудно изменить, оказались правильными" 

Архитектурный фреймворк

Стандарт ISO/IEC/IEEE 42010:2011 даёт определение следующим образом:

Architecture framework - conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders.

В ГОСТ Р 57100 - 2016 определение выглядит так:

Структура архитектуры - условности, принципы и практики для описания архитектур, установленные в пределах заданной области применения и/или объединения заинтересованных сторон.

Фреймворк - это не структура. Фреймворк - это каркас, основание для монтажа принимаемых решений. В фреймворке приводятся основные принципы, которые нужно учесть, чтобы архитектуру можно было понять по её описанию. Всё остальное зависит от тех, кто описывает, и тех, для кого создаётся описание. Вряд ли следует описывать архитектуру в виде UML-диаграмм, если пользователи не знают этой нотации.

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

Интерес и заинтересованное лицо

По ISO/IEC/IEEE 42010:2011 интерес определяется так:

Сoncern - interest in a system relevant to one or more of its stakeholders.

В ГОСТ Р 57100 - 2016 это определение переведено следующим образом:

Интерес - польза или проблемы в системе, относящиеся к одной или нескольким заинтересованным сторонам.

ГОСТ путает нас страшнее метлы Бабы-Яги. На самом деле слово concern означает беспокойство или заботу о чём-либо.

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

Собственно, такое лицо и называется заинтересованным. 

Представление архитектуры и точка зрения на архитектуру

У разных заинтересованных лиц есть разные интересы. Так, пользователю системы важно, чтобы её интерфейс был понятным, удобным, чтобы система работала с данными в терминах предметной области и всё такое. Руководителю предприятия важно, чтобы система автоматизировала определённые бизнес-процессы, увеличивая прибыли и сокращая расходы предприятия. Системному администратору важно знать, как установить и настроить систему, в каком окружении она будет работать, как отслеживать её работоспособность и что делать в случае сбоев.

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

Но то, что интересно и понятно одним заинтересованным лицам, может быть совсем неинтересно или непонятно другим. Более того, у каждого заинтересованного лица есть свои сценарии взаимодействия с системой, её окружением и её документацией. На деле, архитектору нужно знать о каждом заинтересованном лице следующие вещи:

• Какие интересы в отношении системы он имеет

• Какую информацию он вносит или получает из системы

• Какими технологиями он владеет с точки зрения выполнения своей роли в отношении системы

• Какими инструментами он владеет

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

Исходя из этого факта, возникает понятие представления архитектуры.

Стандарт ISO/IEC/IEEE 42010:2011 определяет представление архитектуры так:

Architecture view - work product expressing the architecture of a system from the perspective of specific system concerns.

В ГОСТ Р 57100 - 2016 имеем:

Архитектурное представление - рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.

Это определение говорит о представлении как о неком продукте (читай, документе). Но я бы разделил понятие представления на две темы.

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

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

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

Согласно стандарту ISO/IEC/IEEE 42010:2011:

Architecture viewpoint - work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns.

А из ГОСТ Р 57100 - 2016 имеем:

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

Т.е. точка зрения - это документ, структурирующий интересы и устанавливающий правила формирования представления.

Вот полная схема из ISO/IEC/IEEE 42010:2011, иллюстрирующая все указанные зависимости: 

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

Так вот, модель 4+1 как раз исходит из 4 разных представлений системы: представления пользователя (логика), представления бизнеса, представления разработки и представления развёртывания (физика). В центре модели находятся сценарии, отражающие интересы соответствующих заинтересованных лиц. Понятно, что это очень минималистичная модель. Достаточно взглянуть на схему интересов выше, чтобы понять, что в ней не учитываются многие точки зрения. В каждом конкретном случае нужно дополнять эту модель представлениями, которые нужны другим заинтересованным лицам. 

Описание архитектуры

Описание архитектуры подаётся в стандарте ISO/IEC/IEEE 42010:2011 так:

Architecture description - work product used to express an architecture.

В ГОСТ Р 57100-2016:

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

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

На самом деле, стандарт ISO/IEC/IEEE 42010:2011 подходит к описанию архитектуры очень формально. Не всегда оправдано создавать описания точек зрения и представлений в формальном виде. Но вот моменты, которые важно понимать:

1. Какие лица или группы лиц заинтересованы в системе?

2. Каковы интересы у заинтересованных лиц относительно системы на разных этапах её жизненного цикла?

3. Каковы способности заинтересованных лиц относительно восприятия той или иной формы подачи представления архитектуры?

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

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

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

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

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