Архитектурный Вижн Решения (Solution Architectural Vision) — это прикладной технический артефакт, который описывает, как именно будет устроено и встроено в ИТ-среду компании конкретное крупное решение.

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

В отличие от корпоративного архитектурного вижна (определяющего стратегию развития ИТ на годы вперёд), архитектурный вижн решения:

• имеет среднесрочный горизонт планирования (обычно 1–2 квартала);
• фокусируется на ограниченной предметной области и одном крупном эпике или наборе тесно связанных эпиков.

Что отвечает архитектурный вижн решения

• Какова целостная техническая схема для реализации данного эпика?
• Какие изменения нужны в существующих системах, чтобы поддержать новые бизнес-требования?

Отсутствие утверждённого архитектурного вижна решения означает высокий риск:

• построения неоптимального или несогласованного решения (каждая команда «тянет одеяло на себя»);
• неконтролируемого роста технического долга — временных «затычек» и обходных решений, которые потом дорого исправлять;
• сложностей с масштабированием и сопровождением (система плохо выдерживает рост нагрузки и изменений).

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

Технический долг

Это когда мы делаем быстрее и проще «здесь и сейчас», понимая, что позже придётся заплатить временем и деньгами за переделку.

Функциональное назначение

Архитектурный вижн решения играет роль архитектурного контракта между:

• бизнесом (заказчики эпика, владельцы процессов);
• командами реализации (разработчики, тестировщики, DevOps и др.).

Архитектурный контракт

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

Ключевые функции

Техническое обеспечение бизнес-целей
Архитектурный вижн переводит бизнес-требования с языка «что хотим получить» на язык «из каких блоков и как это будет собранно»:

• какие сервисы и компоненты понадобятся;
• как они будут взаимодействовать друг с другом;
• какие данные и где будут храниться;
• какая инфраструктура требуется (облако, серверы, базы данных и т.д.).

Выявление и минимизация архитектурных рисков
Вижн помогает заранее увидеть потенциальные проблемы:

• критичные зависимости между системами (если «упадёт» одна, пострадают другие);
• ограничения по производительности (не выдержим нагрузку);
• риски по безопасности и доступности;
• сложные интеграции между системами.

Задача — увидеть риск до начала разработки, когда его ещё можно дешево решить на уровне архитектуры.

Обеспечение целостности системы
Вижн гарантирует, что новая функциональность:

• не ломает существующие системы и интеграции;
• не нарушает корпоративные архитектурные принципы и стандарты;
• не создаёт хаотичные «обходные решения» и анти-паттерны.

Проще говоря, он не даёт продукту превратиться в «лоскутное одеяло» из случайных решений.

Основа для декомпозиции и оценки
Архитектурный вижн даёт командам:

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

Без архитектурного вижна оценки по эпикам и интеграциям почти всегда слишком оптимистичные.

Декомпозиция

Разбиение большой задачи (эпика) на понятные и реализуемые части — фичи, задачи, подзадачи.

Синхронизация команд
Если эпик затрагивает:

• несколько направлений бизнеса;
• несколько систем и команд разработки,

архитектурный вижн даёт всем одну общую картинку и фиксирует:

• границы ответственности команд;
• контракты взаимодействия — какие данные и в каком формате одна система отдаёт другой;
• интеграционные каналы: API (запрос-ответ), события, очереди сообщений и т.д.

Структурные компоненты архитектурного вижна решения

Архитектурный вижн решения — это структурированный документ с обязательными логическими разделами.

Контекст и границы решения

Здесь задаются следующие рамки:

• какая бизнес-проблема или инициатива лежит в основе решения;
• какие системы и процессы входят в объём работ;
• какие системы, процессы и сценарии осознанно исключены.

Цель — зафиксировать, что именно покрывает данное решение, чтобы:

• не было «расползания объёма»;
• стейкхолдеры не ожидали того, чего в постановке нет.

Концептуальная архитектура

Это общая картинка реализации, без углубления в детали.

Обычно здесь:

• показывается, как новое решение вписывается в существующий ИТ-ландшафт;
• выделяются:
  — новые компоненты и сервисы,
  — существующие компоненты, которые будут изменены,
  — внешние интеграции,
  — основные хранилища данных.

Часто используется нотация C4 (уровни Context / Container) — это диаграмма связей, без лишних технических деталей.

«Одна картинка вместо тысячи слов»

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

Основные архитектурные решения

Здесь фиксируются ключевые выборы, которые сильно влияют на то, как продукт будет работать и развиваться:

• как компоненты будут обмениваться данными (по запросу, по событиям, через очередь сообщений и т.п.);
• какие типы баз данных используются (реляционные, аналитические, in-memory кэши);
• какие технологии применяются для интеграций, обработки данных и т.д.

Для каждого решения кратко описываются:

• почему так (обоснование);
• какие альтернативы рассматривались;
• последствия для разработки и эксплуатации (например: сложнее, но масштабируется лучше).

Потоки данных и интеграции

Этот раздел отвечает на вопрос:
«Как данные проходят через систему в ключевых сценариях?»

Здесь описывается:

• какие компоненты участвуют в сценарии;
• в какой последовательности они взаимодействуют;
• какие данные и в каком формате передаются.

Часто используются:

• диаграммы последовательностей (Sequence Diagrams) — изображает кто и в каком порядке взаимодействует с продуктом в рамках одного сценария: последовательность шагов сверху вниз, участники — колонками.

• описания контрактов взаимодействия (структура запросов/ответов, форматы событий).

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

Нефункциональные требования и качественные атрибуты

Это раздел про то, как система должна работать, а не про то, что именно она делает.

Здесь фиксируются:

• производительность (какие нагрузки, какое время отклика приемлемо);
• доступность и отказоустойчивость (какой процент времени система должна быть доступна — SLA);
• параметры восстановления (RTO/RPO — за сколько восстанавливаемся и сколько данных можем потерять);
• безопасность (как защищаем доступ, шифруем данные, ведём аудит);
• масштабируемость (что будем делать, когда пользователей станет в X раз больше);
• наблюдаемость (логирование, метрики, трассировка запросов, алёрты).

Пример

Функционально система «умеет показывать баланс и транзакции».
Нефункционально — «делает это за ≤ 2 секунд, доступна 99,9 % времени, безопасно хранит и передаёт данные».

План перехода и влияние на существующие системы

Этот раздел отвечает на вопрос:
«Как мы переедем от текущего состояния к целевому без катастроф?»

Здесь простыми словами описывается:

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

Цель этого раздела одна: сделать так, чтобы бизнес продолжал нормально работать, пока мы меняем систему внутри.

Процесс формирования и место в жизненном цикле

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

Основные этапы

Инициация

Архитектор получает запрос на проработку решения для конкретного эпика или группы эпиков от:

• бизнеса,
• владельца продукта,
• ИТ-подразделения.

На этом этапе:

• фиксируются цели и ограничения;
• описывается бизнес-контекст без углубления в технические детали.

Анализ и проектирование

Архитектор:

• изучает бизнес-требования и текущие процессы;
• проводит встречи с предметными экспертами и техническими лидерами;
• формирует концептуальную архитектуру (общую картинку);
• выявляет ключевые риски и зависимости (где может «стрельнуть»).

Результат — черновой вариант вижна, который уже можно обсуждать с командами.

Документирование

По результатам анализа формируется сам документ архитектурного вижна решения:

• структурированные разделы (как описано выше);
• диаграммы (контекст, контейнеры, основные сценарии);
• описания ключевых решений и рисков.

Важно

Документ должен быть понятен не только архитекторам — менеджерам, PO и ключевым стейкхолдерам.

Рецензирование и утверждение

Архитектурный вижн представляется:

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

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

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

Место в потоке работы

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

Заключение

Послесловие

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

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

Что дальше?

➡️ Разберём как происходит оценка вижнов на стороне команд