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

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

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

Проверяйте решения на прочность по ключевым характеристикам Стивен Джонс

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

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

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

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

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

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

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

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

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

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

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