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

Архитектор должен быть практиком Джон Дэвис

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

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

Лучший способ обучаться — наблюдать за другими; именно так мы учимся в детстве. Хороший архитектор должен уметь выявить проблему, собрать команду и, не занимаясь поисками виновных, объяснить суть проблемы, а затем предложить элегантное решение или обходной путь. При этом архитектор может попросить у команды помощи, нисколько не теряя авторитета. Разработчики должны ощущать свой вклад в решение задачи, но архитектор при этом направляет ход обсуждения и определяет правильный подход. Архитекторам следует присоединяться к команде уже на самых ранних стадиях проекта; они должны не сидеть в башне из слоновой кости, указывая оттуда путь вперед, а работать «в поле» вместе со всеми остальными. Вопросы выбора стратегического направления или технологии не следует превращать в самостоятельные исследования или новые проекты — к ним надо подходить прагматически, разыскивая ответ в ходе практической работы или обращаясь за советом к коллегам-архитекторам (все хорошие архитекторы знают друг друга).

Хороший архитектор обязан на уровне эксперта владеть как минимум одним из инструментов своей профессии, например интегрированной средой разработки (IDE); помните, что архитектор должен быть практиком. Вполне логично, что архитектору ПО следует хорошо знать IDE, архитектору баз данных — инструментарий построения диаграмм «сущность-связь» (ER-диаграмм), а информационному архитектору — инструменты XML-моделирования. Однако ведущий архитектор обязан уметь применять инструменты всех уровней, от контроля сетевого трафика с использованием Wireshark до моделирования сложных финансовых сообщений в XMLSpy, — для него не существует слишком низких или слишком высоких уровней.

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

Джон Дэвис (John Davies) в настоящее время является ведущим архитектором в фирме Revolution Money (США). Недавно основал новую компанию Incept5.