Понятие архитектуры

Архитектура, как и любое другое определение системы, всегда есть – начиная с того момента, когда вы выделили систему из окружающего мира. Не всегда есть архитектурное описание. Архитектура дана нам в виде архитектурных описаний, и поэтому в речи и текстах часто путаются понятия «архитектуры» и «архитектурного описания». Обычно понятно из контекста, о чём идёт речь.

Так, «цвет» шкафа тоже есть, но есть и описание цвета – слово «чёрный», код цвета по одной из цветовых моделей141 или даже попытка воспроизвести этот цвет ? (на каком-то носителе, вот прямо как тут). Но если есть шкаф, то и цвет у него есть. И архитектура у шкафа есть. Но может не быть описание цвета (нигде не будет написано, какой у шкафа цвет), как может не быть описания архитектуры.

Об описании цвета или архитектуры мы говорим, или о самом цвете или архитектуре – это понимаем из контекста, или проговариваем явно. Если мы говорим «цвет нужно сделать почернее», то это про цвет, а если «цвет в кодировке RGB», то про описание цвета. С архитектурой всё то же самое.

ISO 42010 даёт следующее определение архитектуры: «Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития»142. Обратите внимание, что в этом определении нет никакого упоминания структуры системы. Ибо для такой системы как интернет нельзя указать на структуру системы: в интернете никто не знает, что входит в структуру интернета в каждый конкретный момент, какие есть связи между элементами этой системы, непрерывно появляются и исчезают новые узлы интернета и между ними непрерывно появляются и исчезают новые каналы связи. Но определение от этого не стало понятней.

Вот другое определение архитектуры, от части авторов того же ISO 42010, но данное ими в книге про документирование системных архитектур143: «Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений»144. Там наоборот, дан акцент на структуры.

Но самых разных определений много больше, и в интернете есть место, где собрано более 150 таких определений145. Самые разные стейкхолдеры определяют архитектуру по-разному, с акцентом на те или иные её свойства, те или иные классы целевых систем.

Мы будем придерживаться неформального простого и понятного определения архитектуры, которое дал Ralf Johnson: «Архитектура – это обо всём важном. Что бы это ни было.»146.

Эти слова обычно указывают на важные решения, которые могут быть для «железных» систем инженерные, для предприятия организационные, менеджерские или предпринимательские, в случае танцев – постановочные решения, и т. д. Важные решения определяются как такие, в случае принятия альтернативных решений по ним придётся перепринять большинство других решений, то есть перепроектировать и затем переделать всю систему. Так, если при проектировании самолёта принято решение сделать его с реактивным двигателем, а не обычным поршневым, то это означает переделку практически всей конструкции: от устройства топливной системы до формы крыльев и фюзеляжа. Если в здании принято решение печатать его на бетонном 3D-принтере, а не выкладывать его из бетонных блоков или даже из кирпича, то смело можно переделывать всю проектную документацию – или переделывать весь дом, если он уже построен.

Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь проект/design тем самым делится на две части: архитектура и неархитектурная часть проекта (non-architectural part of design).

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

Более сложные формы архитектурных описаний включают в себя компонентные, модульные диаграммы, трассировку компонент и их функций к модулям, размещения и компоновки. То есть архитектурное описание это совсем необязательно список принятых решений: решения могут быть документированы и в других формах. Главное, чтобы они не оказались устными. Интересно, что в советской устной архитектурной традиции, когда архитектурных описаний практически не было, всё важное обозначалось словами «заделы», «опыт», «наработки». Архитектуры были, но их нельзя было предъявить, обсудить, передать, развить иным способом, кроме как задействовав ту команду, которая имела тот самый «опыт» и «заделы» в голове.

Обычно важнейшими архитектурными решениями оказываются решения модульного синтеза: какие модули выбираются для выполнения каких потребных функций. Тем самым в архитектуру попадают решения по верхнеуровневому разбиению на функции, и верхнеуровневому разбиению на модули – в их взаимосвязи. Иногда функциональные описания называют логической архитектурой, а модульные описания и описания компоновки – физической архитектурой. Есть и возражение к такой терминологии: архитектура это про всё важное, а если выбирать только логические и только физические части важного, то это только части архитектуры, а не отдельные архитектуры. Тем не менее, термины эти можно встретить довольно часто, равно как часто можно встретить и другой нерекомендованный термин «нефункциональные требования».

Все эти решения оказываются не только субъективными в части отнесения к архитектурным (и поэтому нельзя провести чёткую границу между «важным» и «неважным»), но относительными в части принятия их разными стейкхолдерами: что архитектурное для одного, неархитектурное для другого. Если один конструктор делает самолёт (целевая система), а другой делает к нему двигатель (подсистема), то для первого выбор типа топливного насоса – неархитектурное решение, а для второго – важное архитектурное решение.

На рисунке субъективность отнесения к архитектурным решениям показана насыщенностью цвета, при этом стрелки примерно соответствуют небольшому числу взаимосвязанных решений, определяющих все остальные решения. Стейкхолдеров-архитекторов показано два: один занимается архитектурой всей системы, другой архитектурой подсистемы. Где остановиться в принятии архитектурных решений? Спускаясь по отношениям часть-целое в холархии нужно остановиться там, где стейкхолдер-архитектор считает, что там уже нет его важных решений, то есть работа уже поделена между разработчиками модулей и дальше будут их важные решения.

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

Итак, архитектура это (с точностью до разницы между определением и описанием – самой архитектурой и выражающими её рабочими продуктами):

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

• компоненты + модули + размещения (только важные, верхнеуровневые), или оно же как

• принципиальная схема + заказная спецификация + компоновка (только важные, верхнеуровневые), или оно же как

• логическая архитектура + физическая архитектура (при учёте возражения о недопустимости «частных архитектур»), или оно же как

• список важнейших принятых конструкторских/проектных/постановочных решений