Об архитекторе

Поговорим об архитекторах.

Обычно все вспоминают вот этого бородатого дядьку.

Ну ладно. Сархитекторил свою матрицу.

А лично мне из киношных архитекторов больше нравится этот герой в исполнении Тома Хэнкса из «Неспящих в Сиэттле».

Это не архитектор программных систем, а архитектор домов. Но очень душевный архитектор.

А вообще, я иногда представляю работу архитектора аналогичной работе этого персонажа (крайний справа), в замечательном исполнении Харви Кейтеля, из «Криминального чтива».

Он придет и молча поправит все,
Человек из Кемерова.

©БГ

Из ИТ классики вспоминается «Мифический человеко-месяц».

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

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

Ну и весьма точно архитектор показан в небезызвесном Энекокореше. Хотя там он какой-то бессловесный, чем вызывает заметную антипатию.

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

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

В работе архитектора нет ничего такого, что бы не мог сделать толковый разработчик.

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

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

И вообще, как мы выяснили на HappyDev, хорошим выбором вполне является и такой выбор, чтобы отложить выборы на потом. А идеальная архитектура — которой (еще) нет.

Таким образом, архитектор является арбитром при принятии решения. У него есть для этого полномочия. А разработчики, бывает, сами не могут решиться. Собственно, часто варианты решения предлагают разработчики (точнее, вся команда), а архитектор лишь взвешивает и выбирает.

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

Архитектор — это роль. Где-то её выполняет обычный ведущий разработчик. Где-то — менеджер, если он технарь. Где-то — технический директор. И относительно редко архитектором является отдельный специально обученный (а скорее просто опытный) человек. Где-то, особенно в аутсорсе, архитектор сидит на стороне заказчика (иногда это хорошо, а иногда — раздражает).

Архитектор — это лишь роль. И исполнять её могут совсем разные люди. Это — коллективный труд.

З.Ы. Спасибо ребятам, которые здорово играли и пели на гитаре, пока я это писал.