«Растяжение» ключевых характеристик поможет вам:

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

• Убедиться, что в сутках хватит часов для обработки данных с заданной пропускной способностью с запасом для пиковых нагрузок и компенсации простоев. Решение, не способное завершить дневной объем работы за день и вынужденное переносить работу на выходные дни, в которые нагрузка снижается, лишено будущего.

• Убедиться в том, что механизмы доступа к данным останутся работоспособными при масштабировании системы. Решение, работающее с недельным объемом данных, может не справиться с объемом, накопленным за полгода.

• Проверить, как при повышении рабочей нагрузки приложение распределит ее на дополнительное оборудование (если оно потребуется), и проанализировать пути перехода при повышении нагрузки. Анализ переходных путей перед развертыванием приложения может повлиять на механизмы хранения данных и их структуру.

• Убедиться, что приложение сможет нормально восстанавливаться после сбоев при возрастании объема данных и/или разделении данных в пределах расширенной инфраструктуры.

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

Стивен Джонс (Stephen Jones) проектирует решения для Tier-lTelco Billing и сопутствующие крупномасштабные процессы для таких компаний, как Telstra и Optus (Австралия), а также AT&T (США). В частности, он занимался исходной реализацией систем тарификации Telco, перепроектированием системы опротестования счетов и борьбы с фальсификациями и более двух лет управлял службой круглосуточной поддержки Telstra.

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

Обдумывая архитектуру для своих проектов, вы должны представлять себе объем работы, необходимый для реализации каждого элемента вашего дизайна. Если какой-то элемент вы уже разрабатывали ранее, вам будет намного проще оценить объем работы.

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

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

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

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

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

Как же архитектор должен подходить к освоению новых инфраструктур, шаблонов и серверных платформ? Об этом вам расскажет этюд «Архитектор — прежде всего разработчик».

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

Я случайно подслушал разговор архитекторов, которые принимали решение о необходимости дополнительных уровней в их архитектуре. Они были правы, но, как это нередко случается, подошли к делу немного не с той стороны. Они пытались создать инфраструктуру, которая включала бы в себя бизнес-логику. Вместо того чтобы решать конкретную задачу, они задумали создать инфраструктуру, которая инкапсулирует базу данных и создает объекты. И при этом она должна была использовать объектно-реляционные отображения. И сообщения. И веб-службы. И должна была делать массу других Классных Штук.