В чём состоит работа архитектора? Часть 2

Я описал 3 направления деятельности архитектора, теперь давайте рассмотрим, в чем именно состоит работа архитектора в каждом из них.

«Всё зависит от контекста» - наверное это самая избитая фраза, которую можно услышать от архитектора.
Фраза стала настолько избитой, что, когда её слышат, на ум автоматически приходит: «ну, понятно, здесь будет ничего полезного, архитектор просто пытается съехать с темы».
В действительности означает эта фраза, что не существует идеальных или типовых архитектурных решений, которые можно брать готовыми, приносить в любое место, ставить и запускать. Очень важен контекст, в котором вы работаете, а также адаптация архитектуры под контекст, в котором решение будет применяться.
В контекст можно включить множество факторов: направление бизнеса (например, ритейл отличается от банка, а малая энергетика похожа на телеком), законодательная база, существующий ИТ-ландшафт, имеющиеся компетенции и многое другое.
Можно сколько угодно хватить golang, но если у вас в штате 100 разработчиков Java и весь корпоративный стек систем написан на Java, внедрение проекта на golang может принести больше проблем, чем пользы. Именно поэтому архитектор должен хорошо изучить и понимать окружающий его контекст.

Согласно легенде строительство Вавилонской башни прекратилось, потому как Бог, разгневанный поведением людей, разобщил людей, наделив их разными языками. Люди больше не могли нормально коммуницировать и великий проект не был завершён, а строители отправились блуждать по свету.
Думаю у каждого в жизни есть хотя бы один пример такого ИТ-проекта.
Архитектор – это универсальный коммуникатор и хороший переговорщик, который постоянно скользит между бизнесом и ИТ, пониманием задачи и проблемы как одних, так и других.
Задача архитектора – создать общий язык между бизнесом и ИТ, наладить коммуникацию между разными командами проекта.
Архитектор должен стать создателем и проводником «общего языка».

Те, кто много путешествуют по России или хотя бы ездят на дачу по Подмосковью, часто видят картину, приведённую на фотографии.

Где-то обязательно попадается кусок дороги, настолько низкого качества, что ехать по нему сложно даже полноценным внедорожникам. Такие участки при этом, как правило, не такие большие, порой всего пара десятков метров. Отсюда возникает законный вопрос: почему нельзя его взять и сделать, остальные десятки километров вполне себе ничего?

Как правило, ответ кроется в том, что этот участок не имеет конкретного владельца и является «серой зоной» между двумя областями. В итоге, именно за него не отвечает никто.Ровно такая же история происходит в ИТ-проектах, когда в каждой отдельно взятой команде всё хорошо, ведётся бэклог, понятна архитектура и планова идёт разработка. А где-то рядом работает еще одна такая же замечательная команда, и у всех всё хорошо.Однако, когда дело доходит до создания совместного результата, который образуется в итоге работы двух команд, вот тут возникает так же проблема, как и с российскими дорогами.Одна из важнейших задач архитектора – находить такие стыки, обрабатывать их, объединять команды для работы над общим результатом и предварять в жизнь концепцию «бесшовной интеграции».

Многие системы, продукты и проекты в какой-то момент ломаются в следствии внесённого в них изменения, и вся вина ложится на того, кто это изменение внёс. Я не зря привёл здесь картинку популярной игры Jengo, которая чётко иллюстрирует этот процесс.
На самом деле 95% изменений не влияют на архитектуру системы кардинальным образом. Небольшие изменения по чуть-чуть, но верно разрушают систему, и в какой-то момент сумма таких изменений приводит к необратимым последствиям. Тут вставили костыль («ну ты пойми, сроки, потом поправим»), тут доработали модель данных и внесли в систему не свойственные ей сущности («ну больше негде!») и так далее. И через какое-то время система даёт критический сбой, превращается в одного из уже упомянутых трёх чудовищ – зомби, вампира или оборотня.
Задача архитектора анализировать такие изменения и рассматривать их влияние на целостность и выживаемость всей системы.

Польза любой системы измеряется её способностью выполнять возложенные на неё функции наилучшим образом.
Задача архитектора – вместе с аналитиками выявлять функциональные требования и подбирать оптимальные решения для выполнения поставленных задач.

Грузы можно возить и в легком авто, а людей перевозить в кузове грузовика, но куда правильней и эффективнее это делать наоброт.

Зачастую в погоне за новыми функциями и конкурентным преимуществом системы и продукты все больше задаются вопросом: «что делать?», опуская или почти не уделяя внимания вопросу: «как делать?»
Вопросы качества выполнения тех или иных функций зачастую опускаются, будучи мотивируемыми следующими идеями: «да, может наша система не возвращает остаток минут на тарифе, но зато смотрите сколько крутых фишек есть в нашем приложении!».
Для меня это порой звучит примерно также странно, как если бы я заказывал еду из ресторана, а мне бы сказали, что привезти смогут её только через 4 часа, зато курьер накроет на стол, расскажет сколько в еде калорий и включит музыку, способствующую улучшению пищеварения.
Задача архитектора – мыслить критически и учитывать нефункциональные требования, предявляемые к системе.

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

Как было сказало в Акте 1, архитектор – это человек, обладающий большой «насмотренностью» и пониманием, что конечный продукт может сильно отличаться от планов на бумаге.
Требования могут меняться постоянно и порой вообще противоречить изначальным планам. Именно опыт и «насмотренность» архитектора позволяют ему держать в голове конечный образ результата, который будет выполнять возложенные на него функции. Некрасивый, но рабочий продукт – лучше красивого дизайна оставшегося на бумаге.