97 этюдов для архитекторов программных систем

Всем заправляет бизнес Дэйв Мурхед

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

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

Одна из сложных задач, возникающих, когда всем заправляет бизнес, — предоставлять достаточный объем сведений качественного характера о том, как движется разработка продукта, чтобы бизнес-руководство могло принимать обоснованные деловые решения. Здесь важнейшую роль играет прозрачность. Архитектор вместе с руководством проекта должен создать и усовершенствовать средства получения регулярной, оперативной обратной связи. Этой цели можно достичь, применяя различные приемы бережливой разработки ПО (lean software development): большие, заметные диаграммы, непрерывная интеграция, частые выпуски рабочих версий продукта и их передача бизнес-руководству уже на самых ранних стадиях проекта.

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

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

Дэйв Мурхед (Dave Muirhead) — ветеран в области искусства программирования и бизнес-технологий, владелец и ведущий консультант Blue River Systems Group, LLC (BRSG) — расположенной в Денвере компании, оказывающей консультационные услуги в сфере бережливой разработки программного обеспечения и технических стратегий.