Архитектура решений

Практика осознанного проектирования структуры систем старше самого термина. В 1968 году Э. Дейкстра описал построение операционной системы THE в виде упорядоченных слоёв, где каждый уровень опирается только на нижележащие; слоистая организация сделала систему обозримой и проверяемой^[3]. В 1972 году Д. Парнас сформулировал критерий разбиения на модули: скрывать внутри модуля проектные решения, которые, вероятнее всего, изменятся, а наружу выставлять лишь устойчивые обязательства; этот принцип сокрытия информации до сих пор лежит в основе компонентной организации систем^[4].

Эти работы показали, что структура системы — самостоятельный объект проектирования. В корпоративной среде параллельно зрела мысль о связи информационных систем с деятельностью предприятия: модель Дж. Захмана 1987 года разложила описание организации на уровни от бизнес-целей до технической реализации и дала управленцам язык разговора с разработчиками^[5].

Слово «архитектура» вошло в название области в начале 1990-х годов. Д. Перри и А. Вулф в работе 1992 года определили архитектуру через совокупность компонентов, связей и ограничений, подчеркнули роль заинтересованных сторон и необходимость описывать систему с разных точек зрения^[6]. М. Шоу и Д. Гарлан систематизировали повторяющиеся структуры систем — архитектурные стили — и закрепили взгляд на архитектуру как на дисциплину с собственным предметом^[7].

П. Крахтен в 1995 году предложил модель «4+1», при которой архитектура описывается пятью согласованными представлениями: логическим, процессным, реализации и развёртывания, связанными сценариями использования; модель вошла в практику благодаря Унифицированному процессу разработки^[8]. К концу десятилетия появились первые своды правил описания архитектуры: рекомендация IEEE 1471—2000 закрепила понятия заинтересованной стороны, точки зрения и вида, позднее перешедшие в международный стандарт^[9].

Термин «архитектура решений» вошёл в отраслевой оборот с методологией TOGAF, первую редакцию которой консорциум The Open Group опубликовал в 1995 году, опираясь на рамочную структуру министерства обороны США^[10]. Методология разделила архитектурную работу по уровням — бизнес, данные, приложения, технологии — и потребовала связывать корпоративные нормы с конкретными проектами; так родилась промежуточная роль, отвечающая за архитектуру отдельного решения. Х. Хофмайстер, Р. Норд и Д. Сони в это же время описали метод «глобального анализа», соединяющий факторы проекта с архитектурным планом его реализации^[11].

В 2000-е и 2010-е годы роль архитектора решений закрепилась в крупных заказчиках и интеграторах: проектировать «в целом» поручали специалисту, который говорил с бизнесом о задачах, а с разработкой — о компонентах. Л. Басс, П. Клементс и Р. Казман ввели в оборот понятие значимых решений — тех, что трудно изменить после постройки, — и показали, что именно они составляют архитектуру^[1]. Н. Розански и Э. Вудс описали работу архитектора системы как службу заинтересованным сторонам: каждое представление существует потому, что кому-то нужен ответ на его вопрос^[12].

М. Ричардс и Н. Форд подвели итог: архитектурная работа начинается не со схем, а с определения характеристик, которыми система обязана обладать, — от них зависит выбор стиля и технологии^[13]. М. Фэйрбэнкс предложил руководствоваться риском: вкладываться в проектирование тех свойств, сбои в которых дороже всего обойдутся владельцу^[14].

В организациях, ведущих систематическую архитектурную работу, принято различать три уровня. Корпоративная архитектура описывает деятельность предприятия в целом: цели, процессы, данные, приложения и технологии, а также нормы их согласования^[15]. Архитектура решений соединяет эти нормы с конкретным проектом, а программная архитектура отвечает за внутреннее устройство созданного продукта^[1].

Границы между уровнями подвижны: в малом проекте один человек совмещает все роли, в крупной организации архитектор решения отчитывается о соответствии корпоративным стандартам. Архитектура решений при этом не сводится к «промежуточному звену»: она добавляет собственный предмет — выбор состава подсистем, распределение данных, план внедрения и перехода со старых систем^[16].

Архитектор решений работает на стыке трёх языков: языка бизнеса, языка проекта и языка технологий. Он переводит задачу заказчика в требования и характеристики качества, предлагает структуру системы и сопровождает реализацию^[12]. Его горизонт — жизненный цикл одного решения, но рассматривает он систему в целом, включая эксплуатацию, сопровождение и увязку с соседними системами.

Обязанности в рамках этой роли варьируются от компании к компании: от выбора продуктов до консультирования проектов. Общим остаётся ответственность за значимые решения: состав подсистем, размещение данных, распределение обязанностей между узлами, порядок интеграции. Ошибки на этом уровне дороги: замена способа хранения данных или способа соединения подсистем после внедрения обходится на порядок дороже, чем на старте^[2].

Работа начинается с контекста: с кем решение взаимодействует, какие нормы на него распространяются, кто его владельцы и пользователи, каковы ограничения бюджета и сроков. Затем собираются требования — функциональные, описывающие поведение системы, и характеристики качества, описывающие, насколько хорошо система должна вести себя: скорость отклика, доступность, защищённость, переносимость^[1]. Характеристики качества формулируются измеримо: не «система должна быть быстрой», а «страница результата открывается не дольше двух секунд при пятистах одновременных пользователях». Русскоязычная практика подчёркивает значение этого этапа: разбор проблем проектирования автоматизированных систем показывает, что большинство переделок уходит корнями в неясные требования и несогласованные обязанности подразделений^[17]. Поэтому архитектор фиксирует границы системы и список заинтересованных сторон до начала проектирования, а спорные требования выносит на решение владельца.

Существенная черта архитектурной работы — выбор среди вариантов. Для каждой значимой задачи обычно есть несколько вариантов структуры: готовый продукт или собственная разработка, свои серверы или облако, деление по функциям или по данным. Архитектор сопоставляет варианты по характеристикам качества и стоимости владения, включая расходы на эксплуатацию и развитие^[13].

Выбранные решения фиксируются в архитектурном описании — наборе документов и моделей, доступных участникам проекта: от диаграмм структуры до табличных реестров решений с их причинами. Описание не самоцель: оно нужно, чтобы разработчики понимали зоны ответственности компонентов, эксплуатация — порядок развёртывания, а заказчик — что именно он получает^[18].

По мере реализации архитектор проверяет соответствие постройки описанию: следит за отклонениями от договорённостей и разбирает инциденты, обнажившие слабые места структуры. Итогом цикла служит пересмотр описания: архитектура решения — не разовый документ, а текущая модель, которая сопровождает систему до вывода из эксплуатации^[1].

Характеристики качества — то, что отличает один вариант структуры от другого при равных функциях. В литературе устоялся набор: производительность, надёжность и доступность, защищённость, модифицируемость, переносимость, удобство сопровождения, масштабируемость^[1]. Для измеримости каждая характеристика формулируется через сценарий: стимул, источник, среду, ответ системы и меру успеха. Доступность записывают долей времени работоспособности; её связь с показателями надёжности выражается формулой A = MTBF / (MTBF + MTTR), где MTBF — среднее время между отказами, MTTR — среднее время восстановления.

Свойства качества связаны не сложением, а обменом: наращивание защищённости обычно замедляет отклик и увеличивает зацепление частей при проверках, дублирование узлов повышает доступность и удорожает эксплуатацию, глубокая настройка под заказчика снижает переносимость. Архитектор управляет этими компромиссами осознанно: сначала выясняет, какие характеристики для решения первостепенны, затем жертвует второстепенными в пределах, согласованных с владельцем^[13].

Описание собирают из представлений — разделов, каждый из которых отвечает на вопросы определённой группы участников. Модель «4+1» связала логическое, процессное, реализации и развёртывания общими сценариями^[8]. Международный стандарт описания архитектуры закрепил словарь понятий и требование обосновывать выбор точек зрения^[19]. Н. Розански и Э. Вудс предложили готовый набор видов и «перспективы» — сквозные требования качества вроде защищённости^[12]. Для записи моделей служат графические языки: UML покрывает структуру и поведение программ, BPMN — процессы бизнеса, язык ArchiMate связывает слои от бизнеса до технологий и служит общим знаменателем между архитекторами разных уровней^[20].

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

Международный стандарт описания архитектуры вырос из рекомендации IEEE 1471—2000, ставшей в 2011 году стандартом ISO/IEC 42010, а в 2022 году выпущенной в новой редакции ISO/IEC/IEEE 42010 совместно тремя организациями стандартизации; редакция 2022 года действует и распространяет требования с программных систем на системы и предприятия^[19]. Стандарт не предписывает метод проектирования, он задаёт словарь и требования к содержанию описания.

TOGAF — самая распространённая открытая методология архитектурной работы; её десятая редакция действует с апреля 2022 года и оформляет методологию как набор модулей: базовые принципы и прикладные руководства^[10]. Язык ArchiMate в версии 3.2 служит для записи моделей в согласовании с методологией^[20]. Наряду с TOGAF используются собственные методологии крупных поставщиков и лёгкие практики, при которых архитектурная работа ведётся итерациями гибкой разработки^[13].

Практика архитектуры решений сталкивается с повторяющимися затруднениями. Первое — отрыв описаний от реализации: схемы устаревают, и через годы им никто не доверяет^[18]. Второе — переусложнение: архитектор строит «на вырост» там, где владельцу нужен скромный результат, и система несёт лишние расходы весь срок службы; противовес — риск-ориентированный подход, соразмеряющий глубину проработки с ценой ошибки^[14]. Третье — слабое представительство интересов эксплуатации и защиты, когда описание создаётся с точки зрения разработчиков, а первые инциденты обнажают забытые требования^[12].

Отдельная трудность — организационная: роль архитектора решений размыта между корпоративной архитектурой и руководителями проектов, и там, где ответственность не закреплена, значимые решения принимаются по умолчанию^[1].

Архитектура решений востребована там, где строится или меняется крупная система: внедрение электронного документооборота, перевод учёта на новую платформу, объединение данных филиалов, построение расчётных сервисов. Разборы отраслевых проектов показывают типовой ход: приспособление методологии к масштабу организации, архитектурное задание, целевая архитектура решения и план перехода^[16]. В государственном секторе архитектурная работа связана с требованиями к автоматизированным системам и конкурсными процедурами^[17].

Развитие области идёт по пути уточнения связи архитектуры с измеримыми характеристиками и встраивания архитектурной работы в итерации гибкой разработки^[13]. Зрелая архитектурная работа снижает стоимость владения системами, хотя прямые измерения эффекта затруднены^[2]."