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

Контент — король. Контент — сеть. Контент — интерфейс. В современном мире, пронизанном многочисленными информационными связями, качество контента все чаще определяет успех или неудачу. FaceBook против Orkut, Google против Cuil, NetFlix против BlockbusterOnline… список сражений, выигранных и проигранных на поле контента, можно продолжать до бесконечности. Кто-то может возразить, что аспекты, касающиеся контента, не относятся к проблематике архитектора ПО, но я считаю, что следующее десятилетие докажет обратное.

Оценка контента должна стать частью процесса проектирования новой системы. Простого проектирования эффективной модели предметной области/ объектов/данных недостаточно.

Проанализируйте весь доступный контент и оцените его значимость по следующим критериям:

• Достаточно ли доступного количества контента? Если нет, как получить «критическую массу»?

• Достаточно ли актуальна содержащаяся в нем информация? Если нет, как улучшить скорость поступления?

• Все ли возможные каналы распространения контента изучены? RSS-трансляции, электронная почта, бумажные бланки — все это является возможными каналами.

• Созданы ли эффективные входные потоки, упрощающие непрерывное поступление контента в систему? Одно дело — выявить ценный контент, и совсем другое — организовать его регулярное получение.

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

Зубин Бадья (Zubin Wadia) — генеральный директор RedRock IT Solutions и технический директор ImageWork Technologies. Обладает разносторонней квалификацией в области программирования, владеет языками Basic, С, C++, Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Специализируется на разработке решений из области автоматизации бизнес-процессов для компаний из списка Fortune Global 500 и правительственных учреждений США.

Бизнес и недовольный архитектор

Чед Лавинь

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

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