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


Из товароведов в системные архитекторы с пятью остановками

В школе я увлекалась биологией и физикой. После окончания хотела поступать на биофак и мечтала стать биофизиком. Но это были 90-е, мы жили в Орле, и у меня не было возможности уехать учиться в другой город. У нас же были только педагогический и коммерческий институты. В итоге я по совету родителей выбрала коммерческий и отучилась на товароведа-эксперта.

После выпуска я даже девять месяцев проработала по специальности. В итоге поняла, что, во-первых, зарплаты в 500 рублей мне категорически не хватает, а во-вторых, по факту моя деятельность слабо связана с настоящим товароведением. Шел 2000 год: розница была такой, что никому ни моя экспертиза, ни закупка качественных товаров были не нужны.

Я переехала в Москву. Первые два года проработала маркетологом: занималась всем подряд, но должность почему-то называлась именно так. В какой-то момент передо мной возник выбор, куда уходить. У меня было предложение о работе менеджером по продаже строительных материалов с зарплатой в 1500 долларов и возможность перейти в ИТ, где предлагали на 500 долларов меньше. То есть я выбирала между деньгами сейчас и развитием в будущем. И выбрала ИТ, о чем никогда не жалела. Уже в начале нулевых я понимала перспективы этой отрасли в целом и для себя в частности.

Начинала я с контрактного сектора в компании, которая разрабатывала достаточно известную биллинговую систему для операторов связи. И пока я занималась контрактами, поняла, что мне интереснее проектирование оборудования, поставляемого по этим контрактам. Стало любопытно: люди, которые делают эти спецификации — а как они их делают? Что это за оборудование — серверы, массивы, ленточные библиотеки?

Так любопытство меня привело в технический отдел, и я начала осваивать проектирование платформы. И оно же привело меня в итоге на позицию системного архитектора: по дороге еще был ряд компаний и должностей.

И вот я уже 10 лет системный архитектор, сейчас руковожу небольшой командой. У меня нет технического образования, как и у многих айтишников. Я никогда не была инженером и не занималась внедрениями, что, наверное, нетипично для моей профессии. Бывают моменты, когда меня это смущает, потому что кажется, что все вокруг с Windows- и Linux-бэкграундом и знают то, чего не знаю я. Я же все свои знания получала прикладным путем: стояла какая-то задача, я погружалась в тему, общалась с проектировщиками, инженерами и другими людьми и так осваивала профессию. Еще, конечно, много читала, гуглила, ходила на вендорские курсы и профильные конференции. И теперь думаю, что такой, пусть и не самый распространенный сценарий для системного архитектора, вполне состоятелен, потому что в нашей профессии очень много зависит не только от hard, но и от soft skills.

Разные архитекторы

Здесь нужно сделать дисклеймер. Даже в профессиональной среде есть путаница в понимании того, кто такой «системный архитектор». Потому что есть системные архитекторы, которые занимаются архитектурой приложений, и это больше про разработку, а есть инфраструктурные архитекторы, которые отвечают за платформу, железо, на которых эти приложения будут работать. Я отношусь ко второму типу, и все мои выводы справедливы только в отношении его представителей.

К нам приходит заказчик с задачей и требованиями к вычислительной мощности, ресурсам хранения, производительности и т. д. Еще всегда есть дополнительные разрозненные требования: разработчиков приложений, службы ИБ заказчика, внутреннего регламента ИТ-департамента. И задача архитектора заключается в том, чтобы все эти разрозненные требования собрать и скомпоновать так, чтобы по возможности удовлетворить большинство из них, не потеряв при этом функционал и производительность всего решения. Это в лучшем случае, а в худшем у заказчика есть только проблема или задача, которую нужно решить, а всё остальное архитектору приходится собирать по крупицам. На выходе я формирую техническое решение в виде набора оборудования и системного ПО.

Пара важных инсайтов о лжи и перфекционизме

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

Вроде звучит просто, но это открытие меня в тот момент потрясло, потому что казалось крайне несправедливым. «Как же так, есть же задача, и она должна быть решена наилучшим способом из возможных», — думала я. Мне было непонятно, зачем инвестировать серьезные деньги в несовершенные решения, пусть уже кто-то сформировал мнение или написал регламенты.

Тогда, на самом старте, это бесило. Сейчас к этому уже выработался некий философский стоический подход. Моя задача как архитектора в этом случае — обозначить ухудшение, которое несет не самый оптимальный выбор или замена. Но иногда бывает и так, что я должна костьми лечь и настоять на лучшем решении, найти какие-то доводы, что «это — не вариант». Иначе мы получим нерабочее решение, и плохо от этого будет и заказчику, и сейлу, и мне. Это непросто: необходимо быть гибким, уметь убеждать и находить подход к собеседнику.

Инсайт второй — все врут. Речь не о злонамеренной лжи, когда тебя осознанно вводят в заблуждение. В работе системного архитектора тебе просто без злого умысла сообщают недостоверную информацию. Если, например, я не погружена в тему, а проектировщик говорит, что надо сделать только вот так, я скажу «спасибо» и пойду спрошу еще одного-двух человек и почитаю, действительно ли это так. Дело не в недоверии или в конкретном человеке. Я просто по опыту поняла, что люди погружены в свои процессы, у всех высокая загрузка, и часто тебе дают ответ по инерции, не особо задумываясь. Или у человека могут быть устаревшие или неполные сведения, он может не понять контекст твоей задачи и просто в чем-то заблуждаться. Если говорить в терминологии Даниэля Канемана, люди часто дают ответ, используя Систему 1 там, где явно нужно подключить Систему 2.

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

Не инсайт, а общее место. В моем непростом пути в системной архитектуре мне очень помогло то, что я не боюсь задавать вопросы, даже те, что на первый взгляд кажутся дурацкими. Сколько раз я сидела на совещании, и заходила речь о чем-то таком, что половине присутствующих непонятно. Это можно было прочесть по лицам или понять уже после совещания, когда явно мало кто понимал, что в итоге надо сделать, посчитать и т. д. Часто люди предпочитают не подавать вида и сидеть с умными лицами. Я же предпочитаю задавать вопросы, когда мне что-то непонятно. Иногда такие вопросы сначала кажутся дурацкими, но чаще всего, когда на них начинают отвечать, задача раскрывается совсем с другой стороны, и всем становится понятно, что вопросы были по существу.

Технические vs человеческие

Я понимаю, что мощный технический бэкграунд помогает человеку стать хорошим системным архитектором, и все же автоматически его таковым не делает. Ты можешь качественно собрать все технические требования, объединить, обсудить с заказчиком, придумать очень красивое техническое решение — но это всё потом умрет, потому что ты не сможешь презентовать его сейлу или заказчику. И эта часть проекта «про общение» часто съедает больше сил и ресурсов, чем техническая.

Поэтому я считаю, что личные качества, коммуникативные навыки и прочие soft skills крайне важны для системного архитектора. Путь в эту профессию из проектировщиков и внедренцев признан, но не каждый специалист с суперпрокачанными hard skills может стать хорошим архитектором. Для этого, по моему опыту, кроме уже упоминавшихся гибкости и умения договариваться, человеку нужны следующие качества:

Умение чем-то пренебречь и подняться на уровень выше. Иногда чем больше человек с глубокой технической экспертизой знает деталей, тем сложнее ему принять решение. Хорошо, если человек, зная обо всех нюансах решения, может подняться над ними и сказать: «Ок, вот этим мы можем пренебречь», и обрисовать заказчику связанные с этим риски.

Принятие решений в условиях неопределенности. Это вообще одно из ключевых умений системного архитектора. Потому что не бывает такого, что на старте проекта у тебя есть ответы на все вопросы. И особенно сейчас. Чаще всего заказчик хочет, чтобы сделали «как-то хорошо». А как это — «хорошо»? Вы же эксперты, и это вы мне должны объяснить, что такое «хорошо». Решения приходится принимать в условиях нехватки времени и ресурсов. Например, когда мы ведем пресейл, это 3–5 дней, еще у заказчика есть бюджетные и прочие ограничения — и под таким давлением при недостаточности информации нужно найти оптимальное решение задачи. И взять на себя все связанные с ним риски.

В целом это, конечно, здорово, когда у человека есть знания в технических науках, умение программировать на нескольких языках, он может сам смонтировать и настроить сервер или массив, знает на практике, как работают разные технологии. Это все очень помогает при переходе в архитекторы. Но есть еще личные качества и навыки, которые могут быть у человека из других направлений — например, продаж. Поэтому путь из других околотехнических специальностей также нормален, как и путь из инженеров, только в этом случае человеку будет сложнее: придется потратить много сил и времени на прокачку технических компетенций.

Из пресейла в архитекторы

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

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

И дальше уже надо сделать финальный рывок. У нас, например, есть «школа архитекторов». Если в компании нет такой истории с выращиванием архитекторов внутри, можно попроситься к кому-нибудь на проект вторым архитектором, чтобы посмотреть, как эта кухня работает: поездить на встречи, поучаствовать в проектировании и внедрении.

Еще хочется сказать о навыке, который мне очень помог — навык обучения через аналогию. Теперь, по опыту, я понимаю, что эта способность есть не у всех людей. Но для человека, переквалифицирующегося в системные архитекторы, такой навык необходим. Потому что в принципе задачи, которые до этого никто никогда не делал, встречаются на практике достаточно редко. В них могут немного отличаться вводные, иногда условия совпадают один в один, только цифры разные, а иногда надо что-то добавить или заменить. Поэтому, если ты способен действовать по аналогии, — это будет очень сильно помогать.

Нет такого института, куда можно пойти учиться и стать системным архитектором. Это происходит через самообучение, изучение смежных областей и усложнение того, что ты делал. И чтобы стать хорошим специалистом в этой области, нужны эти способности — учиться у других и учиться самостоятельно — плюс некий стартовый набор личных характеристик: системное мышление, коммуникативные навыки, гибкость и др. И это справедливо для человека с любым бэкграундом.

Источник иллюстрации: Shutterstock.com

Комментарии (31)


  1. Neom1an
    20.10.2022 12:09

    Окей, "нормально". Принимается. Однако хочется всё-таки "хорошо", "отлично' или " Превосходя ожидания"


    1. juhok Автор
      20.10.2022 12:31

      у меня не было ожиданий :))) поэтому " Превосходя ожидания" точно не подходит :)


      1. Neom1an
        20.10.2022 12:33

        Выполнять работу не "нормально", а на "превосходя ожидания"


        1. juhok Автор
          20.10.2022 12:47
          -1

          Закажу себе щит с таким девизом :))))


    1. vladvul
      20.10.2022 14:20
      +4

      Делай, чтобы превзойти ожидания, плохо само получится.


  1. AndreySitaev
    20.10.2022 12:42
    +5

    Случилось мне провести анализ, сравнение и выбор нескольких ERP для внедрения в небольшую организацию. Фаворитом стал NetSuite. Выбор я сделал, основываясь на информации рекламного характера. Составил сравнительную таблицу, проставил галочки.

    Позже я же стал интегратором этой ERP. Тут выяснилось, что заявленные возможности автоматизации на деле не оправдали ожиданий. Как программист, я плевался на множество ограничений и в итоге NetSuite стала лишь тонкой прокладкой поверх самописной системы учета финансов.


    1. AndreySitaev
      20.10.2022 12:46
      +10

      К чему это я? Производя выбор и сравнение ERP я оказался таким вот "системным архитектором без технического бэкграунда". Я обращал внимание на то, что было на поверхности. С точки зрения бизнеса, на бумаге всё было хорошо - до внедрения. Дьявол крылся в технических деталях, на которые я просто не обращал внимания.

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


      1. juhok Автор
        20.10.2022 12:52
        -3

        Наличие или отсутствие технического бэкграунда не отменяет подхода к выбору решения :)) обычно мы не останавливаемся на выборе решений по даташитам, отобрав лучшие на основе заявленных производителем характеристик проводим внутреннее тестирование и вот уже на основании него мы и выбираем подходящий продукт. Возьмите на заметку ;) Не верить вендору и проверять самому руками - очень полезный подход.


  1. Electrohedgehog
    20.10.2022 12:44
    +8

    Правильное название статьи будет примерно такое — я работаю инжинером-проектировщиком а называют системным архитектором. И это нормально.


    1. juhok Автор
      20.10.2022 12:55
      -2

      Странно, что у вас сложилось такое впечатление, возможно прочитали по диагонали :) Хотя в вашем замечании подсвечена основная проблема в нашей ИТ отрасли - когда название должности не соответствует функциональным обязанностям.


  1. Velzipuzik
    20.10.2022 12:44
    +12

    ой как все плохо... ИМХО теперь понятно почему качество продуктов такое у jeta, да и понятно почему люди от туда бегут... То что вы описали, это не Системный архитектор, это Проект манагер с особым самомнением. В статье не увидел ничего, что связанно с профессией в заголовке.


    1. juhok Автор
      20.10.2022 12:45
      -10

      Спасибо за обратную связь :) жаль что о вас лично мне ничего не известно - потому что всегда важно не только кого судят, но и кто судьи :)


  1. ivoronin
    20.10.2022 12:58
    -3

    Проработали вместе 6 лет, только из статьи узнал что оказывается у автора нет технического бэкграунда. До этого считал что это абсолютный must, а вот оказывается можно быть супер-успешным в роли архитектора и без. Дела!


  1. elve
    20.10.2022 13:29
    +10

    Системный архитектор без инженерного бэкграунда это ненормально. Сейчас объясню почему:

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

    Так называемые "soft skills" это больше к менеджерам относится. По тому, как вы описали свою работу, вы все же не архитектор, а менеджер больше. Объясняю почему: вы строите свои выводы на основе опроса экспертов, а не на базе собственных знаний или изученной документации (как вы описали в статье, так я и понял ;) ). Это больше смахивает на управленца, а не технаря.

    А теперь к самой сути - смесь вашего уникального опыта, пытливого ума и навыков общения позволили вам эффективно работать на должности архитектора. Но если "каждая кухарка начнет управлять государством", то будет очень много проблем. Смиритесь со своей уникальностью =).


    1. juhok Автор
      20.10.2022 14:02
      -2

      Смиряюсь :)
      вы правы, надо написать вторую часть и назвать ее "Потом и кровью или учите матчасть!" :) Прийти таким красавчиком с одним только желанием и нулем знаний и сразу стать системным архитектором конечно не получится, и конечно я не сразу стала архитектором - в процессе работы нарабатывала технические скилы и продолжаю это делать. И до идела мне конечно же далеко :) В этой профессии ты постоянно должен учиться иначе тебя выкинет. Тут как в Алисе - чтобы оставаться на месте нужно бежать изо всех сил, а чтобы куда-то прийти двигаться в два раза быстрее :) и, да, без технического бэкграунда изначально будет гораздо сложнее - потому что нужно будет больше читать, больше узнавать, больше напрягаться. Сильно больше, чем тем, у кого он есть. Но, статья про то, что это реально. Вижу цель - не вижу препятствий! Если есть такое желание, то даже не имея ИТ-образования и инженерного опыта, можно попробовать. А по поводу кухарок и государства - к сожалению и часто из инженеров и проектировщиков не получается системных архитекторов. Некоторые просто не хотят усложнять себе жизнь, беря на себя лишнюю ответственность, а у некоторых не хватает других навыков. В общем конечно архитектор = обширные технические знания +софт скилы. В статье больше про софт скилы - без них архитектору никуда. По поводу прямо вот обязательного инженерного навыка - не согласна, для того чтобы понять как что-то работает, не обязательно ставить\настраивать это руками самому - чтение техдоков + обратная связь от людей-практиков, в которой недостатка не бывает как правило + народ сейчас щедро в сети делится своим опытом.


  1. svinopterix
    20.10.2022 15:16
    -1

    Удивительно, так много негативных комментов. Я, как архитектор с техническим бэкграундом :), уверен, что практический инженерный опыт для работы архитектором не особо нужен, хоть и полезен. Обязательно нужен кругозор в технологиях - это да. Допустим, ты архитектор комплексного инфраструктурного проекта, где есть инженерка, серверы, Windows, Linux, виртуализация, хранилки, сеть, безопасность, мониторинг и ещё немного хеви-метала. Что, нужно прям во всех этих областях поработать инженером? На это жизни не хватит) И ещё одно наблюдение. Часто под архитектором понимают специалиста, который умеет детально спроектировать техническое решение. В нашем же понимании этим занимается не архитектор, а инженер-проектировщик - тот, кто глубоко понимает конкретную технологию и может её спроектировать с точностью "до болта". А архитектор - да, в каком-то смысле это технический менеджер и есть. Его задача: собирать требования, фомулировать задачу, подбирать специалистов для её решения и координировать в техническом плане их совместную работу, защищать решение перед заказчиками, чтобы в конце концов получившаяся система соответствовала исходным требованиям.


    1. Mike_Mihalych
      20.10.2022 15:26

      Больше удивляет количество минусов к ответам.


      1. juhok Автор
        20.10.2022 17:16

        и меня тоже :)


    1. juhok Автор
      20.10.2022 17:14

      Да, и именно необходимость иметь широкий кругозор становится врагом экспертности. Как правильно вы заметили, жизни не хватит глубоко изучить все решения и технологии, которые входят в состав даже стандартной небольшой ИТ-инфраструктуры. И получается, что архитектор какие-то технологии знает очень хорошо, какие-то поверхностно. И вот тут как раз становится важна команда инженеров и проектировщиков, на которых в некоторых вещах архитектор может опереться, и коммуникативные навыки архитектора и его умение быстро вычленять главное и задавать правильные вопросы :)


  1. JavaFox
    20.10.2022 16:24
    +8

    Это не нормально. Я лично считаю, что даже Тим лидом и руководителем отдела где сидят одни технари, должен быть технарь. А сейчас, с огромным багажом знаний, огромным опытом и лучшими практиками, мы имеем Windows 11, Cyberpunk 2077 и кучу другого "крутого" софта, где каждый человек запустив "это", может сразу же найти 5+ багов, не имея технического! бэкграунда. В итоге мы пришли к тому, что лучший софт пишется ужасно токсичным, сексистским и расистским сообществом (привет линуксойды), а уверенные в себе архитекторы, стоят за миллионными проектами, которыми потом невозможно пользоваться, а благодаря великому скраму, фикс простого бага или возврата фичи которая уже была раньше (привет таскбару Windows 11) мы будем ждать год или больше. И всё потому, что очень много людей считает, что для написания и создания архитектуры приложения не нужен технический бэкграунд


    1. juhok Автор
      20.10.2022 17:05
      -3

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


      1. JavaFox
        20.10.2022 17:53
        +2

        А как можно знать, какое железо подойдет лучше, не зная как работает софт? Самый простой пример, если софт работает с кучей мелких файлов, то есть смысл инвестировать в ssd и т.д. Но что бы это знать, надо знать как работает софт и далеко не всегда в брошюре это будет написано


        1. juhok Автор
          21.10.2022 11:25
          -2

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


  1. megamrmax
    20.10.2022 18:56
    +2

    Девушка пришла и обидела кучу бородатых мужиков :-)


    1. juhok Автор
      21.10.2022 11:20
      -3

      Думаете, если бы автор статьи был мужчина, то хейта было бы меньше? :)))) уверена, что нет :) и если бы у автора был технический бэкграунд, но виндовый, то в комменты пришли бы юникс\линукс и заявили, что это не настоящий технарь и такой бэкграунд не считается :))))


  1. Sayonji
    20.10.2022 21:54
    +4

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


  1. computerix
    21.10.2022 06:57
    +2

    Возможно вы так описали, но я увидел менеджера, а не архитектора. Имхо, без отличного технического бекграунда и прохождения всех ступеней развития, ваши решения врятли будут глубоко проработанными. Когда я читал эту статью у меня в голове возник образ Джен из IT-Crowd (мост между бизнесом и it).


    1. juhok Автор
      21.10.2022 12:04
      -3

      А без продвиженческих навыков, ваши прекрасные глубоко проработанные технические решения так и останутся на бумаге :) Технический бэкграунд важная вещь, но он дело наживное. И статья же не о том, что вот вы ничего не знаете и вам и узнавать не надо. Однозначно технические знания прокачивать надо, но для того чтобы знать что нужно для установки сервера в стойку, не обязательно самому ставить его руками :) И да, архитектор это и есть мост между бизнесом и IT :))) именно поэтому и не каждый инженер идет в архитекторы.


      1. computerix
        21.10.2022 12:43
        +1

        Ну да. Для продвижения обычно менеджеры и нужны). В моем понимании системный архитектор это типо ГИП в строительстве. Если инженер там глубоко не понимает в техническом аспекте, то быть беде. И не поможет что он все красиво рассказал) Но это только мое понимание. В каждой организации свои порядки, так что возможно у вас эта должность и называется системным архитектором. Я не претендую на истину в последней инстанции.


  1. ggo
    21.10.2022 10:09

    Ничего не знаю про автора статьи и его навыки системного архитектора. Предпочитаю профессиональные навыки оценивать при личном общении.

    А вот про утверждение что софт скиллы архитектору (не важно какому) не нужны. Я бы поспорил.

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


    1. juhok Автор
      21.10.2022 11:58
      -1

      Статья и была о том, что не боги горшки обжигают. Технические навыки, на мой взгляд, наработать легче, чем многие софтскилы. С машинами гораздо проще чем с людьми, они более предсказуемы :)