В худшем своем проявлении самонадеянность просачивается в сферу деловых отношений. Это отличная возможность навсегда загубить свою карьеру. Именно бизнес оправдывает само наше существование. Возможно, нам несколько неприятно сознавать этот факт, но все же не стоит упускать его из виду. Мы живем для того, чтобы служить потребностям бизнеса, а не наоборот. Умение слушать представителей бизнеса, которые нанимают нас для решения своих задач, и понимать эти задачи — один из самых важных наших навыков. Вам когда-нибудь доводилось нетерпеливо дожидаться, пока бизнес-аналитик закончит говорить, чтобы приступить к изложению своей позиции? Скорее всего, его точку зрения вы при этом не восприняли. Относитесь к экспертам в предметной области с тем уважением, которое хотели бы видеть по отношению к себе; крайне нежелательно, чтобы они считали вас непробиваемым упрямцем. Если они начнут избегать вас, вы станете катализатором нарушения информационного обмена и по сути выроете могилу собственному проекту. Помните: когда вы говорите, то сможете услышать только то, что уже знаете. Никогда не считайте себя умным настолько, что другие уже не могут сообщить вам ничего стоящего.

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

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

Изначально архитектура приложения Формируется на основании заданных бизнес-требований, выбранных или уже применяемых технологий, диапазона производительности, ожидаемых объемов данных и финансовых ресурсов, выделенных для построения, развертывания и управления системой. Решение, каким бы оно ни было, должно соответствовать требованиям из этого набора либо превосходить их — и при этом успешно работать в современных условиях (иначе это попросту не решение).

Теперь возьмите свое решение и посмотрите, какие проблемы появятся, если «растянуть» ключевые характеристики.

Анализ такого рода выявляет архитектурные ограничения, которые проявятся в том случае, если система станет, например, чрезвычайно популярной и количество ее пользователей превысит начальные ожидания, или увеличится ежедневное количество транзакций, или потребуется хранить данные в течение полугода вместо изначально предусмотренной недели. «Растягивайте» ключевые характеристики сначала по отдельности, а затем в сочетаниях друг с другом, чтобы выявить те невидимые ограничения, которые скрыты в исходной архитектуре.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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