Кажется, что сейчас нет ни одного крупного бизнеса, где бы не работали архитекторы. Однако с ролью архитектора решений (Solution Architect) история очень интересная, так как этим специалистам часто приходится сталкиваться с непониманием данной роли в проекте. Наиболее частый стереотип, что архитектор решений – это такой прокачанный разработчик или PM с бэкграундом разработки.
Конечно, если посмотреть чуть-чуть назад, то раньше на проектах эту роль выполняли опытные разработчики. Но время идет, рынок меняется и сейчас если у вас большой проект, а вы хотите, чтобы он «полетел», то без архитектора решений вам никуда.
Как и в любом крупном банке в Росбанке есть такие специалисты. Мы решили разобрать роль Solution Architect с Александром Егоркиным, директором по технологиям департамента информационных платформ.
Кто такой архитектор решений?
Давайте попробуем расшифровать. Например, в строительной отрасли «архитектор» — это главный строитель, который осуществляет проектирование и надзор за строительством объекта. Соответственно, в ИТ смысл, заложенный в термин «архитектор решений» это как раз проектировщик решений, который на основе информационных систем создает целостную картину проекта, удовлетворяющего требованиям заказчика и отвечающего стратегии развития ИТ организации.
Он умеет разговаривать на одном языке с техническими специалистами и бизнесом, понимает технические особенности ИТ-систем и, главное, правильно их использует. Также он контролирует параметры производительности, надежности, масштабируемости и совместимости всего решения в целом. Архитектор решений — это человек, отвечающий не только за разработку, но и за практическую реализацию идей.
Какие функции у архитектора решений?
Архитектура решений фокусируется на описании важных и сложных вопросов, которые позволят сделать успешной реализацию задуманной идеи. В проектах сложные реализации означают большие расходы с непонятным результатом.
Как можно снизить стоимость проекта? Для этого нужно снизить сложность решений, сделав декомпозицию. То есть создавать сложный проект лучше на основе более простых систем с наиболее широким применением. Именно из них складывается требуемый «пазл». И чем больше в организации присутствует таких общих систем/сервисов, то итоговое решение будет более качественным, дешёвым и соответствующим проектным требованиям. Таким образом, мы как бы отодвигаем принятие ключевых архитектурных решений.
Следовательно, еще одной задачей архитектора решений является создание предпосылок для внедрения таких атомарных информационных систем со своим минимальным набором «свойств», которые бы можно было переиспользовать в разных проектах, как строительные блоки. Это снижает общую сложность как по дальнейшему развитию, так и поддержке и повышает качество работы таких решений в целом. Все это в конечном итоге повышает стабильность сервисов организации.
Например, можно сделать частное решение по защите API, выставить требования для бэкэндов и реализовывать в каждом API этот функционал. А можно вынести эту функцию на API-Management систему, внедрив ее как селф-сервис. Таким образом, бэкэнд сервис не приземлил к себе этот дополнительный функционал, а у архитектора есть профит в виде нового «кубика», который будет решать в дальнейшем свойственные ему функции в других задачах.
Далее, создавая новые решения, мы можем рядом запустить новый «кубик». Например, движок бизнес-процессов в виде селф-сервиса. Публикуя его API на «апиме», в движке не потребуется реализация ролевой модели по доступам к бизнес процессам.
Мы получаем уже набор «кубиков», на основе которых можем быстрее собрать решение под ключ для заказчика. А ведь могли бы все в один «монолит» запихнуть, обозвать его «супермегановый фронт». Но в этом случае в дальнейшем были бы проблемы с обслуживанием и разработкой, да и переиспользовать его в других проектах было бы проблематично. Каждый раз изобретать велосипед — не очень хорошая идея :)
Какие ключевые скилы для архитектора решений?
Хард-скилы:
должен знать стандарты и методики разработки;
уметь проектировать архитектуру нагруженных систем и контролировать реализацию;
выбирать и обосновывать технологии;
обеспечивать баланс между стоимостью разработки и гибкостью решения;
также важно быть погруженным в предметную область и понимать цели заказчика.
Софт-скилы:
умение работать с командами развития и поддержки;
разговаривать с заказчиком на одном языке;
иметь системное мышление и целеустремленность;
готовность брать ответственность за принимаемые решения.
Как выглядит типичный рабочий день архитектора решений?
В типичном рабочем дне Solution Architect главным образом сосредотачиваются на решении различных технических задач. Начинается день с рабочих конф-коллов, где обсуждаются текущие проблемы, возможные подходы к их решению и отслеживание прогресса работ по проекту.
Также одной из ключевых задач является решение технических вопросов, которые включают в себя создание прототипов для демонстрации концепций и проведение технологических исследований для выбора оптимальных решений.
Не менее важным аспектом работы является документирование. Создание презентаций, проведение митапов для коллег, отработки обратной связи, разработка документации по дизайну системы, а также создание схем и диаграмм для наглядного представления информации о проекте.
Откуда и как приходят в профессию архитектор решений?
Если говорить про меня, то в Росбанк я сразу пришел на эту позицию. Здесь нужно немного пояснить, что ранее я уже работал в «Росе» прошел путь от эксперта по интеграции, аналитика ДБО до руководителя Центра компетенций и довольно хорошо знал ИТ-ландшафт как со стороны разработки, так и со стороны поддержки.
Я проработал в банках почти 28 лет. Первый опыт и впечатления получил на проекте смены автоматизированной банковской системы (АБС), в 1998 году прошла смена плана счетов, деноминация, это зацепило интересными задачами в банковском ИТ (до этого, честно говоря, не планировал, что свяжу свою карьеру именно с банками, считал их достаточно скучными J).
И дальше была череда самых разных проектов: разработки собственных ИТ-систем, поддержка, смена ИТ-систем. Я рос вместе с отраслью, поработав во многих направлениях банковского ИТ. С уверенностью могу сказать, что постоянное изучение новых технологий, применение их на практике позволяло лучше разбираться и видеть результаты тех или иных внедрений с разных сторон «баррикад» (здесь я имею ввиду «разработку» и «поддержку»).
В целом мне видится, что неисповедимы пути архитекторов решений. Чаще всего ими становятся ИТ-архитекторы, лиды разработки или руководители проектов, имеющие большой практический опыт по работе с ИТ системами (здесь я имею в виду не только опыт создания ИТ-систем, но и обязательно опыт их поддержки).
Чем отличается архитектора решений от разработчика, бизнес-аналитика и техлида?
В работе «солюшена», как правило, используются навыки данных ролей, и в принципе, он может заменить каждого из них. Но его задача в целом верхнеуровнево и согласованно вести всю техническую часть проекта, поскольку решения обычно предполагают участие нескольких ИТ-систем и нужна синхронизация всех участников проекта. А указанные роли погружены уже в детали и конкретные задачи своих систем.
Зачем в проекте нужен системный архитектор, если есть архитектор решений?
С моей точки зрения системный архитектор — это специалист, обладающий глубокой технической экспертизой в своей области и сфокусирован на своем направлении. Более детально знает все аспекты работы своего участка и консультирует «солюшена» по своему стеку, высказывает ограничения, помогает предложениями по реализации.
Можно ли нанять архитектора решений со стороны?
Почему нет? Необходимость в отдельном архитекторе нарастает, когда решение предполагает участие нескольких информационных систем со своими сформировавшимися командами развития (я про интеграцию). Как правило, если больших систем в проекте больше двух, то без «арбитра», разбирающегося в теме, проект будет ехать очень тяжело.
Если же команда зрелая и инженеры умеют договариваться, то роль «солюшена» выполняют они сами своей группой. Все зависит от самой команды, от задач и от частоты изменений.
Как оценить эффективность архитектора решений?
Конечно, необходимо учитывать специфику проекта, сделать декомпозицию на задачи, по факту выполнения которых уже можно проанализировать работу. Однако базовые пункты оценки звучат так:
Реализация решения. Необходимо определить, насколько решение рабочее. Оценивает работу проектная команда.
Оценка результата. Здесь необходимо обратить внимание на то, насколько решение оказалось удобным в обслуживании, производительным, надежным, интегрируемым с другими процессами. Сюда же относится оптимизация стоимости решения.
Все это окажется в метриках эксплуатации. Оно и покажет компетенции, а также вовлеченность архитектора в этом решении.
Сколько уровней у архитектора решений?
Думаю, здесь зависит от самой компании и ее структуры, как позиционируется роль или должность. Отсюда и будут уровни внутри компании. Есть обычная механика (junior, middle, senior), где на потоке стоят решения и нужно переваривать объемы (это в основном про «интеграторов»). Есть практика одного «солюшена» на подразделение, где он вырастает из ИТ-архитекторов с наибольшим кругозором.
Куда расти архитектору решений?
ИТ-технологии не стоят на месте. По прошествии времени должно произойти смещение идей, концептов и потребуется работа по иной парадигме. Думаю, именно это сместит акцент работы у данной роли и выдавит «солюшенов» в новую реальность.
Но если вернуться к вопросу, всё зависит от того, чем хочется заниматься по жизни. Для кого-то архитектор решений – это конечная цель, а кто-то может рассмотреть позицию CTO и создавать технологическую стратегию развития компании.
Как отрабатывать изменения в идущем проекте?
Чаще всего изменения в текущих проектах присутствуют, так как изначально допускались в просчете рисков. Когда же случаются непрогнозируемые риски, то здесь уже место сложным решениям: это может быть пересмотр проекта, а иногда даже фиксация убытков, вплоть до закрытия проекта.
При старте проекта, как правило, есть несколько путей реализации, которые имеют свою стоимость. Такие развилки и их комбинации должны быть описаны в рисках проекта и отрабатываться соответствующими мерами.
Например, для снижения технологических рисков сначала идет отработка гипотез, как и на чем делать решение. Готовится прототип решения и тестируется. На этом этапе могут всплывать неучтенные требования или их неверная трактовка. Уже по результатам исследования принимается решение о целевом каркасе (архитектуре) проекта с допусками, запасными вариантами, стоимостью каждого варианта.
Как отрабатывать конфликты?
Важно выяснить почву конфликта. К примеру, если рассматривать технический аспект, выбор технологий и тому подобное, то здесь нужно, во-первых, разговаривать на одном языке (бывает, что говорят об одном и том же, но не слышат собеседника). Во-вторых, изложить на бумаге все плюсы и минусы каждого решения, обсудить со всеми участниками. Кстати наглядные диаграммы, блок-схемы лучше помогают синхронизироваться между собой и решить недопонимание.
Открытость здесь играет на руку. Необходимо довести до участников проекта конечную цель и причины, по которым выбирается то или иное решение.
Как соблюдать work-life-balance в интенсивных проектах?
Здесь у каждого свои методы. Например я руководствуюсь простым концептом: рабочий календарь в аутлуке помогает разделить работу и личную жизнь. Расписание помогает распределить задачи и понять, как ты работаешь.
«Залезание» работы в личное время снижает качество отдыха и это начинает влиять на качество работы. Из этого порочного круга тяжело выбраться. Да, бывает, что проблема «зацепила» и нужно быстро найти решение.
Надо понять, что привело к занятости в личное время, оценить причины и сделать выводы, как такого не допускать в будущем. Также отмечу, что иногда есть соответствующее настроение вечером спокойно разобраться с задачей и получается эффективно. Особенно когда проблема несколько дней живет в голове и не дает покоя. Это поднимает настроение и есть то самое чувство удовлетворения от сделанной работы. Вообще для меня важно видеть результаты своего труда.
Если у вас остались вопросы о деятельности архитекторов решений, то готов обсудить их в комментариях.