Конечно, не точно. На самом деле, я главный технический директор, но управление архитектурой - это то, что помогает мне жить и вполне себе эффективно существовать в своей роли.
Все, что я пишу ниже - мой путь и мои знания, которые я использую для запуска команд, в построении процессов разработки. Точно могу сказать, что прошел не весь путь и чем дальше я иду, тем больше точек зрения на архитектуру вижу.
Какая цель у архитектуры, кто-нибудь задумывался?
Продуктом разработки ПО является - о, боже мой, - код. Цель архитектуры, любой архитектуры, в процессе разработки, - сделать так, чтобы код доходил от идеи до прода как можно быстрее и, желательно, за один раз.
Видимо, через это понимание я и стал архитектором.
Вот мне 40 годиков, и только сейчас понимаю, насколько глубокая область знаний - подход к работе с архитектурой, насколько это может ускорить разработку и какие совершенные, эффективные решения можно создать, если ты вкладываешься в архитектуру со знанием дела.
До того, как я опишу свой путь, скажу, что архитекторы бывают разные и слои архитектуры тоже. За спиной у меня стеллаж с книжками, и если и есть там определение сортов архитекторов и их зон ответственности, то везде оно будет разное.
По TOGAF - это так:
По Фаулеру и Эвансу - по-другому. Для себя вывел следующие домены компетенций, которые по уровню знаний и навыкам существенно отличаются друг от друга:
- Software-архитектор, он же системный архитектор - тот чувак, который умеет проектировать системы и изменения в них. Этот человек максимально близок к разработке и, желательно, сам пишет код. Он знает паттерны проектирования систем, знает о существовании нефункциональных требований, умеет в технологии и может выбрать технологию не основываясь на своем желании потрогать божественное, а на основе принципов эффективности и дальнейшего развития системы. Часто выделяют роль Infrastructure - архитектора, с этим и согласен, и нет. Считаю, что проектирование инфраструктуры - это то, что должен уметь системный архитектор, но есть отдельные случаи, когда речь идет о проектировании облачных решений как проекта или геораспределенной инфры как продукта - для этого нужны отдельные люди другого сорта.
- Solution - архитектор, он же архитектор решений. Умелец, который проектирует изменения на уровне не конкретной информационной системы, а на уровне ландшафта. Он, как раз, должен раскурить бизнес-требования и создать конкретные требования к каждой системе, которые будут однозначно читаемыми и не противоречивыми. Умеет в DDD и всякие такие штуки.
- Data-архитектор, в отдельных доменах, таких как, например: большие данные, машинное обучение и еще паре, есть отдельные люди, которые проектируют агрегаты данных, их структуру хранения, преобразования, консолидации. Таких людей мало и они дорогие. И когда я слышу от кандидата на собесе, что я архитектор данных в интернет-магазине, мне хочется прервать собес, ведь то, что он сказал значит, что он недосистемный архитектор и в архитектуру его прошлый работодатель ударился от того, что их система становится колом от каждого изменения, ни о какой структурности в проектировании изменений речи идти не может..
- Enterprice-архитектор. Вершина пищевой цепочки архитектуры. Управляет подходами к архитектуре в компании вплоть до разработки, делает ее ценной для компании и каждого конкретного разработчика. Проектирует бизнес кейсы с проекцией на ИТ, умеет использовать тяжеловесные фреймворки типа TOGAF/FEAF/TEAF/DoDAF, проектирует в archimate, учит солюшенов и системных быть правильными и делать правильно. ПФФФ, ой все, о чем это я, обычно этот чувак, который мешает всем жить и квадратики которого оторваны на 100% от реальной жизни. Но не всегда так, конечно, одного хорошего корпа я знаю, который вытащил разработку одного интернет-магазина входящего в топ-3 маркетплейсов из задницы аджайл-хаоса, но это скорее исключение.
Есть еще разные подвиды архитекторов, такие как Security-архитектор, Net-архитектор, но все это подвиды, я считаю.
Мой путь.
Начинал я в начале нулевых, и был простым разработчиком на С++, писал какие-то программы. Сейчас бы, я, наверное, даже на джуна не накрафтил. Но достаточно быстро начало приходить неприятие бардака, когда требования сгружались нам в виде ТЗ, без какого-то DOD, который мы могли бы проверить. Работает в проде - и ладно. А если нужно внести изменения, идешь к соседу Васе и выясняешь, как и зачем он написал модуль и как он работает.
Нужно понимать, что в те времена, был и Мартин, и Фаулер, был Бек и Александер, но доступ к их великолепным трудам был сильно ограничен, какие-то урывки, которые приходили через фидошечку или с BBS были на английском, насыщенными специальными терминами, о которых в универе нам не рассказывали, ну и в голову все это не ложилось. Но было четкое ощущение неправильности происходящего, когда решение о реализации той или иной фичи принималось на этапе написания кода.
Дальше я сделал "поворот не туда" - стал, тем кого сейчас называют девопсом - организовывал инфраструктуру разработки в дочке одной нефтегазовой компании, был тупой и жадный, что поделать? Там, обслуживая "настоящих" программистов, ну те, что деньги на этом зарабатывали, в 2004м году я познакомился с прообразом CI-СD. QA толкового, как и человеческого саппорта у нас не было, и я как человек ленивый, очень быстро устал разбираться кто чего не так собрал, как это говно выехало в прод и что мне делать в воскресенье вечером, чтобы вся эта тряхомудина работала... Через руководство пропихнул CVS, а затем скачал через eDonke сабвершен, обвязал все это баш-скриптами. Так в моей жизни появилась итерационная разработка и что-то похожее на CI.
Но еще тогда меня очень сильно напрягало, что разработчики предпочитали зафигачить сырой код в релизную сборку и по 10 раз переделывать решения, которые они принимали в коде. Почему нельзя спроектировать решения? Что мешает нарисовать решение, а раз нарисовал - проверить, хотя бы, на непротиворечивость?
"Какие они недалекие", - думал я, но вскоре я стал еще более жадный и вернулся в разработку. Почти сразу мне представилась возможность залидировать проектирование и разработку биллинга для интернет-провайдера. И стало мне не по себе - половину паттернов использования биллинга, я не знал. Начал я с фиксации требований, максимально четких, понятных для меня, разработчиков и заказчиков. Это в дальнейшем сильно упростило жизнь, и это именно то, что подразумевает в своей книге Эванс под понятием "единый язык".
Дальше было сложнее. Имея опыт в разработке, понимал, что любое допущение с моей стороны - шаг к переписыванию частей системы. Тогда мне помогло погружение в СУБД и какая-то теория в базах данных, я попытался сформировать агрегаты и наложить на них эвентовую модель. Как-то сформировал нефункциональные требования, что позволило мне разбить систему на модули, агрегаты - на таблицы, спроектировать и написать биллинг с первого захода. И это был 2006-2007 годы.
Видимо, понимание рисков, сформировало критическое отношение к недостатку знаний о системе, всегда пытался разобраться до винтика во всем, очень сильно очковал, когда приходилось принимать решения, не зная до конца механику процессов в системах и в требованиях. Часто работая где-либо, слышал фразу: иди к Артему - он точно знает, как тут все работает.
Дальше было много чего: свой бизнес, большие и малые проекты в логистике, финтехе, HORECA, много где еще, руководство разработкой десятком команд, но до 2016 года я руководствовался не фундаментальными знаниями в архитектуре, а ощущением несовершенства происходящего - почему так странно переиспользуется функционал, почему нет стандартизации в стеке технологий, почему требования так странно преобразуются в процессе разработки и как с этим бороться??
В 2016 я стал корпоративным архитектором. В тот момент я уже понимал, что что-то здесь не так в разработке, и это не творчество, это инженерный процесс, в котором каждый этап призван ускорить появление качественного кода, желательно еще, за одну итерацию.
А тут такая возможность - стать сразу на вершине, рулить архитектурой в компании с 300 000 сотрудников..
Что ж, я попробовал, получилось так себе, научился TOGAF, проектировал в Archimate, богатый бэкграунд разработчика помогал делать красивые решения на уровне ландшафта. Но то, что меня люто бесило - это то, что команды класть хотели на мою архитектуру и единственное, в чем я был полезен - это в консультировании команд по ИТ-ландшафту: что и как работает в клубке из более чем 300т систем.
Потом уже, анализировав этот опыт, понял парадигму из предисловия: архитектура нужна для кода, а не код для архитектуры. Насаживать корпоративные стандарты сверху - неправильно, главенствующий код и процессы нужно строить вокруг его производства, целей качества, скорости и эффективности.
В какой-то момент мне это надоело, хотелось видеть результат своей работы. И в той же компании я перешел руководителем разработки на домен систем, где все пропало - ничего не работало и не поставлялось в прод. И вот сижу я и смотрю на архитектуру и думаю: какой мудак это нарисовал? сколько времени нужно на реализацию всего вот этого вот?
Ну а дальше были книжки, много книжек, божественный Эванс, не менее крутой Клепман и много кто еще. И где бы я дальше ни работал, первое, что я делал при сборе команд или при рефакторинге существующих - ставил процесс принятия решения, даже не разработки архитектуры, а именно принятия решения. В корне не верно принимать решение в момент, когда ты пишешь код, ведь его ни кто не критикует, ты сам не можешь задуматься в момент создания решения. Ведь никто не задумывается, что будет дальше, что будет, если ты напишешь так, а не иначе, выберешь ту или иную технологию. И это приводит к рискам увеличения стоимости разработки системы и, как следствие, - к изменению отношения к тебе заказчика, что совсем печально. А вот для этого и нужен инженерный процесс и архитектура.
Лучшей работой на земле, в итоге, для меня стала работа руководителем Dev2Dev департамента в одном крупном enterprice, где я отвечал за разработку инструментов, практик архитектуры и объединения всего процесса разработки в единый pipeline. Была возможность действительно пощупать эффективность своей работы, построить процесс от кода, создать разветвленный набор инструментов и практик, сделать так, чтобы разработчик занимался своей работой, а QA своей, чтобы они не бегали друг к другу с вопросиками, а просто делали свою работу и получали от этого удовольствие.
Интересен был переход от состояния "мы тут творим, хрен ли ты к нам лезешь со своими практиками" до "мы не примем эти требования, они не прошли quality gate, мы так не работаем".
Что ж, сейчас я главный техдиректор в банке из топ-3 и история с подходами к архитектуре играет новыми красками. Это бездонная бездна, путешествуя по которой можно добиться значимых и клёвых результатов.
Резюмируя.
Всегда приятно видеть результат своей работы. Особенно приятно видеть результат, когда он красив и элегантен, когда система, которую ты разработал гибкая, масштабируемая, эффективная, а не так что, ой нагрузка, давайте пользователям по 600 постов в день и все у нас с перформансом норм будет. И для этого стоит вкладываться в процессы и в архитектуру, а чтобы делать это эффективно стоит изучать и пребывать новые и новые практики, смотреть на других, пытаться осознать причины их подходов и их риски.
Счастья всем, да прибудет с вами архитектурная сила.