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

Все мы попадали в «бюджетектурные» переделки, когда разумные технологические решения «хоронятся» ради экономии. Разговор проходит примерно так:

«Нам действительно так необходимы X?» — спрашивает спонсор проекта.

На место X можно подставить практически всё жизненно необходимое для работы системы: лицензии на программные продукты, избыточные серверы, внешние резервные копии или источники питания. Вопрос всегда задается отеческим тоном, словно вы спускаете все карманные деньги на комиксы и жвачку, тогда как серьезным взрослым людям нужно думать о покупке новых ведер, в которых они будут таскать свою будущую прибыль.

Правильный ответ на этот вопрос звучит так: «Да. Абсолютно необходимы». Но так почему-то почти никто не отвечает.

В конце концов, у нас техническое образование, а любая техническая дисциплина — это искусство компромисса. Понятно, что экзотика вроде источников питания никому не будет нужна, если поставить в центре обработки данных несколько беличьих колес и запустить в них практикантов. И вместо того чтобы сказать «Да, абсолютно необходимы», мы говорим что-то вроде: «Вообще-то без второго сервера можно обойтись, если вы согласны смириться с простоями из-за профилактики и при каждом сбое памяти. Хотя если мы купим память с автоматическим контролем четности, то и эту проблему можно обойти. Так что остаются только сбои операционной системы в среднем через каждые 3,9 дня, а значит, по ночам сервер придется перезагружать, но это вполне могут делать практиканты, когда устанут крутить колеса».

И все это может быть совершенно справедливо, но говорить так ни в коем случае не следует. Спонсор перестает вас слушать уже после слов «вообще-то».

Проблема в том, что вы рассматриваете происходящее с технической точки зрения, а ваш спонсор четко понимает, что он ведет переговоры. Вы занимаетесь совместным поиском решения, тогда как он проводит тактический маневр типа «выйдет/не выйдет». А в любых переговорах ни в коем случае не следует делать уступки по первому требованию. Правильный ответ на вопрос «Нам действительно так необходимы X?» звучит примерно так:

«Без второго сервера вся система будет „падать“ примерно три раза в день, особенно в периоды максимальной нагрузки и при демонстрации на собрании совета директоров. На самом деле нам нужно четыре сервера, чтобы одна независимая пара обеспечивала сохранение 100-процентной работоспособности, даже если другая пара неожиданно перестанет работать».

Конечно, вы прекрасно знаете, что третий и четвертый серверы на самом деле не нужны. Это тактический гамбит, который заставит вашего спонсора перевести разговор на другую тему. Вы повышаете ставку и показываете, что система и так работает на минимальной, рискованной конфигурации. Кроме того, если вам каким-то чудом удастся получить дополнительные серверы, вы всегда можете передать один под тестирование (чтобы среда тестирования полностью соответствовала рабочей среде), а из другого получится отличная машина для сборки.

Биография автора приведена ранее.

Используйте количественные критерии Кейт Брайтуэйт

«Быстрый» не может быть требованием. Как и «обладающий хорошим временем отклика». Или, скажем, «расширяемый». Главная причина заключается в отсутствии объективных критериев выполнения таких требований. Но пользователям эти характеристики все равно нужны. Задача архитектора — позаботиться о том, чтобы система обладала необходимыми качествами, а также сбалансировать неизбежные противоречия, возникающие между ними. Без объективных критериев архитектор зависит от капризов заказчика («Нет, я не могу принять программу — она работает недостаточно быстро») и разработчиков, одержимых навязчивыми идеями («Нет, программа еще не готова — она работает недостаточно быстро»).

Обычно мы стараемся записать все подобные пожелания, как и любые другие требования. Но эта запись очень часто выглядит как набор туманных эпитетов: «гибкий», «удобный в сопровождении» и так далее. Однако все критерии такого рода (при достаточном усердии даже «удобство использования») могут измеряться в числовых величинах, для которых можно установить пороговые значения. Если этого не сделать, пользователи лишатся объективных оснований для принятия системы, разработчики потеряют полезные ориентиры, которыми они могут руководствоваться во время работы, а представление архитекторов о системе утратит четкость.