(В оригинале Business Drives)

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

Бизнес-заказчики обычно планируют определенный возврат вложений (ROI) перед тем как инициировать процесс разработки. Архитектор должен иметь это в виду, ограничивая те инициативы со стороны разработки, чтобы избежать принятия решений, которые могут привести к перерасходу бюджета. Возврат вложений должен рассматриваться как один из главных интересов заказчика во время переговоров о ценности той или иной функциональности по сравнению со стоимостью ее реализации. Например, архитектор должен учитывать интересы заказчика, не соглашаясь на желание разработки использовать технологию, имеющую неприемлемо высокую стоимость лицензии или техподдержки готового продукта.

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

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

Долгосрочные интересы разработки лучше всего соблюдаются, если процессом управляет заказчик.

Автор оригинала - Dave Muirhead.