Software Architect · Модуль 21
Архитектура существует не в вакууме. Она должна помогать продукту зарабатывать, снижать риск и двигаться с правильной скоростью.
Business value · cost · risk · optionality · roadmap
Хорошее техническое решение должно иметь бизнес-смысл: скорость, надёжность, снижение риска, экономию или новую возможность.
Архитектурная цена должна быть видна
Бюджет стройки включает не только кирпичи, но и обслуживание, ремонт, страховку и простой.
Total cost of ownership включает разработку, эксплуатацию, поддержку, обучение, миграции, vendor lock-in, incident response и opportunity cost. Решение может быть дешёвым в разработке и дорогим в эксплуатации.
Архитектор переводит технические trade-offs в понятные business terms: «Эта интеграция быстрее на месяц, но увеличит ручную поддержку на 10 часов в неделю» или «Этот refactor снижает риск потери платежей».
Optionality имеет цену
Можно построить дом с возможностью добавить второй этаж. Но усиленный фундамент стоит денег уже сейчас.
Иногда архитектура покупает future optionality: возможность выйти в новый регион, добавить enterprise SSO, сменить провайдера платежей, масштабировать команду. Это полезно, если вероятность и ценность будущего сценария достаточно высоки.
Плохая optionality — абстракции «на всякий случай». Хорошая optionality — подготовленный путь миграции для вероятного бизнес-сценария.
Архитектор помогает продукту не путать техническую красоту с экономическим эффектом.
Пример: отложить multi-region
Магазин не строит международную логистику до того, как понял спрос в первом городе.
Стартап запускается в одном регионе, но проектирует data model так, чтобы позже добавить region field и data residency. Multi-region deployment не реализуется сейчас, потому что нет enterprise-клиентов. ADR фиксирует trigger: первый контракт с data residency requirement.
Это хороший баланс: не переплачиваем сейчас, но не закрываем путь роста.
Антипример: refactor без product narrative
Поменять плитку в цеху можно. Но если станки стоят месяц, нужно объяснить, что бизнес получит взамен.
Команда просит квартал на rewrite, потому что «код плохой». Бизнес слышит остановку roadmap без понятной отдачи. Если нет связи с cycle time, incident rate, hiring, compliance или revenue, решение выглядит как внутреннее желание инженеров.
Технические улучшения нужно связывать с measurable product или operational outcome.
- Какое бизнес-свойство покупает это решение? - Какая полная стоимость владения? - Какой риск снижается и насколько он реален? - Как объяснить это решение без технических деталей?