Бизнес-цель и экономика изменения
Архитектура начинается не с перечня систем. Сначала фиксируются бизнес-проблема, ожидаемый эффект, ограничения по срокам и затратам, а также показатели, по которым будет оцениваться результат.
Без этого поставщики оптимизируют предложения под собственные продукты, а заказчик сравнивает несопоставимые объёмы и обещания. Экономика изменения задаёт границы решения и помогает отказаться от функций, которые не создают достаточной ценности.
Целевой процесс и роли
До автоматизации нужно определить, как должен работать процесс: входы, решения, контрольные точки, исключения и ответственность участников. Иначе новая система закрепит текущие разрывы или перенесёт их в цифровую форму.
Целевая модель показывает, где требуется технология, а где — изменение регламента, полномочий или управленческого контроля. Это снижает объём ненужной разработки и будущих доработок.
Данные и интеграционные зависимости
Карта данных определяет источники, владельцев, правила качества, хранение и использование информации. Отдельно фиксируются системы, с которыми решение должно обмениваться данными, и последствия недоступности каждого обмена.
Этот контур позволяет заранее оценить реальную сложность миграции, интеграций и сопровождения, а не обнаруживать её после подписания контракта.
Функциональные и нефункциональные требования
Функциональные требования описывают, что должно делать решение в конкретных бизнес-сценариях. Нефункциональные — как оно должно работать: производительность, доступность, безопасность, масштабирование, удобство, поддерживаемость и требования к данным.
Хорошее требование проверяемо и связано с целью или риском. Большой перечень пожеланий без приоритетов не заменяет архитектуру и затрудняет сравнение вариантов.
Ограничения и критичные риски
Архитектурный контур должен учитывать обязательные платформы, нормативные требования, зрелость команды, допустимые зависимости, сроки и пределы изменений в смежных системах.
Риски оцениваются до выбора решения: технологическая зависимость, дефицит компетенций, сложность миграции, эксплуатационные расходы и последствия масштабирования. Это позволяет видеть полную стоимость владения, а не только цену внедрения.
Критерии сравнения вариантов
Поставщики должны отвечать на одну и ту же задачу и раскрывать одинаковый набор параметров: покрытие требований, архитектурные отклонения, стоимость, сроки, ресурсы заказчика, ограничения и риски.
Вес критериев задаётся до получения коммерческих предложений. Тогда выбор опирается на модель решения, а не на наиболее убедительную презентацию или заранее знакомый продукт.
Этапность и критерии приёмки
Будущее решение делится на управляемые этапы с самостоятельным результатом. Для каждого этапа задаются доказательства готовности, контрольные точки, зависимости и условия открытия следующего объёма.
Такая структура позволяет остановить или скорректировать инвестицию до накопления критичных затрат и заранее связывает архитектуру с приёмкой проекта.
Управленческий вывод
Сначала модель решения — затем технология и поставщик
Архитектура до выбора поставщика не означает преждевременное детальное проектирование. Она задаёт нейтральный контур, в котором видно, что именно меняет бизнес, какие условия обязательны и как проверить результат. Это уменьшает стоимость ошибки до того, как она закреплена контрактом.
Архитектура ИТ-решения