Конечно не точно. На самом деле, я главный технический директор, но управление архитектурой - это то, что помогает мне жить и вполне себе эффектно существовать в своей роли.
Все, что я пишу ниже - мой путь и мои знания, которые я использую для запуска команд, в построении процессов разработки. Точно могу сказать, что прошел не весь путь и чем дальше я иду, тем больше точек зрения на архитектуру вижу.
Какая цель у архитектуры, кто-нибудь задумывался?
Продуктом разработки ПО является, о боже мой - код, цель архитектуры, любой архитектуры, в процессе разработки, сделать так, чтобы код доходил от идеи до прода как можно быстрее и желательно, за один раз.
Видимо, через это понимание я и стал архитектором.
Вот сейчас мне 40 годиков и только сейчас понимаю, насколько глубокая область знаний - подход к работе с архитектурой, насколько это может ускорить разработку и какие совершенные, эффективные решения можно создать, если ты вкладываешься в архитектуру со знанием дела.
До того, как я опишу свой путь, скажу, что архитекторы бывают разные и слои архитектуры тоже, за спиной у меня стеллаж с книжками и если и есть там определение сортов архитекторов и их зон ответственности, то везде оно будет разное.
По TOGAF - это так:
По Фаулеру и Эвансу - по другому. Для себя вывел следующие домены компетенций, которые по уровню знаний и навыкам существенно отличаются друг от друга:
- Software-архитектор, он же системный архитектор - тот чувак, который умеет проектировать системы и изменения в них. Этот человек максимально близок к разработке и, желательно, сам пишет код. Он знает паттерны проектирования систем, знает о существовании нефункциональных требований, умеет в технологии и может выбрать технологию не основываясь на своем желании потрогать божественное, а на основе принципов эффективности и дальнейшего развития системы. Часто выделяют роль Infrastructure - архитектора, с этим и согласен и нет, считаю, что проектирование инфраструктуры, это то, что должен уметь системный архитектор, но есть отдельные случаи, когда речь идет о проектировании облачных решений - как проекта или геораспределенной инфры как продукта - для этого нужны отдельные люди другого сорта.
- Solution - архитектор, он же архитектор решений. Умелец, который проектирует изменения на уровне не конкретной информационной системы, а на уровне ландшафта. Он, как раз, должен раскурить бизнес-требования и создать конкретные требования к каждой системе, которые будут однозначно читаемыми и не противоречивыми. Умеет в DDD и всякие такие штуки.
- Data-архитектор, В отдельных доменах, таких как, например: большие данные, машинное обучение и еще паре, есть отдельные люди, которые проектируют агрегаты данных, их структуру хранения, преобразования, консолидации. Таких людей мало и они дорогие. И когда я слышу от кандидата на собесе, что я архитектор данных в интернет-магазине, мне хочется прервать собес, ведь то, что он сказал значит, что он недосистемный архитектор и в архитектуру его прошлый работодатель ударился от того, что их система становится колом от каждого изменения, ни о какой структурности в проектировании изменений речи идти не может..
- Enterprice-архитектор. Вершина пищевой цепочки архитектуры. Управляет подходами к архитектуре в компании вплоть до разработки, делает ее ценной для компании и каждого конкретного разработчика. Проектирует бизнес кейсы с проекцией на ИТ, умеет использовать тяжеловесные фреймворки типа TOGAF/FEAF/TEAF/DoDAF, проектирует в archimate, учит солюшенов и системных быть правильными и делать правильно. ПФФФ, Ой все, о чем это я, обычно этот чувак, который мешает всем жить и квадратики которого оторваны на 100% от реальной жизни. Но не всегда так, конечно, одного хорошего корпа я знаю, который вытащил разработку одного интернет-магазина входящего в топ-3 маркетплейсов из задницы аджайл-хаоса, но это скорее исключение.
Есть еще разные подвиды архитекторов, такие как Security-архитектор, Net-архитектор, но все это подвиды, я считаю.
Мой путь.
Начинал я в начале 90х и был простым разработчиком на С++, писал какие-то программы. Сейчас бы, я наверное даже на джуна не накрафтил. Но достаточно быстро начало приходить неприятие бардака, когда требования сгружались нам в виде ТЗ, без какого-то 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 постов в день и все у нас с перформансом норм будет. И для этого стоит вкладываться в процессы и в архитектуру, а чтобы делать это эффективно стоит изучать и пребывать новые и новые практики, смотреть на других, пытаться осознать причины их подходов и их риски.
Счастья всем, да прибудет с вами архитектурная сила.