ИТ-архитектор. Как стать тем, на кого не учат?

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

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

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

    Так чем же они, то есть мы, по факту занимаемся?

    Три вида архитекторов

    Проще всего это понять, разобравшись, какие бывают архитекторы в ИТ.

    Есть наиболее распространённое и понятное определение «архитектора решений» или «solution-архитектора» — это специалист, который понимает, как устроена и должна работать определенная прикладная система (веб-сервис, социальная сеть, ERP-система и пр). Он держит команды разработки в рамках техзадания и помогает создавать решения, фокусируясь на бизнес-задаче, а не просто на функциональных требованиях к исполняемому коду. Любое приложение должно на чем-то работать, а данные, которым оно оперирует, храниться долго и без потерь. Solution-архитектор может только сформулировать, какие ресурсы требуются и как быстро должен подниматься упавший сервис. Кто же сделает это реальностью?

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

    В идеале синергия системного и solution-архитекторов должна давать компании тот самый импульс для развития. В действительности между ними — бездна. Архитекторы решений не знают, как функционирует инфраструктура, а системные архитекторы часто не заинтересованы вникать в работу ПО. Именно поэтому над ними появляется «enterprise-архитектор» — супермен, способный соединить два сегмента архитектуры. Это не какой-нибудь отдельный «биологический» вид, а скорее новая эволюционная форма развития системного и solution-архитектора. Обычно он соединяет два берега над той самой бездной.

    Мой личный опыт

    Лично я начинал с простого инженера. Еще будучи студентом, работал эникейщиком, потом руководил маленьким отделом из трех человек в компании в Приморье. После перебрался в Питер и там впервые столкнулся с полноценной ИТ-инфраструктурой, став руководителем группы эксплуатации серверов и систем хранения. Через какое-то время меня притянула Москва. За несколько лет я стал руководителем дирекции ИТ-инфраструктуры, где кроме должности и нового масштаба задач мне вручили набор административных и, как я потом уже понял, архитекторских задач. Разбираться с этим приходилось на ходу, а многое просто брать и делать своими руками. Часто впервые.

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

    Футболисты и шахматисты

    Наша компания ведет много крупных и сложных проектов, и поэтому у нас в штате я далеко не единственный системный архитектор. Оказывается, достичь этой позиции можно разными путями. Например, я — «футболист». Всю свою карьеру я «играл на поле»: бегал по ЦОДам, физически имел дело с оборудованием, знал его особенности, решал проблемы в реальном окружении. Но бывают прекрасные архитекторы «шахматисты». Они развиваются из глубоких теоретиков, которые изначально занимались только проектированием и не имеют богатого «полевого» опыта.

    У каждого карьерного пути свои плюсы и минусы. Однажды я участвовал во встрече, где мои коллеги архитекторы готовили таблицу сравнения по двум системам резервного копирования. Мне это было странно, потому что, как практик, я прекрасно знал, насколько одно решение лучше другого. Да что там — на голову выше! Практика дает хорошую опору в принятии решений. В то же время, теоретики более беспристрастно оценивают все возможные опции, особенно когда все запутано и откровенно плохо. Так что разница между практиками и теоретиками не сказывается на качестве принятых решений.

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

    Какие навыки нужны ИТ-архитектору?

    Умение абстрагироваться

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

    Менеджмент и любовь к людям <3

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

    Как-то на проекте мы уперлись в «человеческий фактор». Специалист, отвечавший за работу СУБД, был крутым DBA. А еще у него был прямолинейный и упрямый характер. Миграция приложений происходила долго и мучительно, и ему надоели миллионы вопросов по поводу каждой системы. Однажды он перестал выдавать нужную информацию по БД. Миграция застопорилась.

    Тогда я остановил все миграции и стал разбираться, что же происходит. Столько возмущения и несогласия со стороны коллег мне еще не приходилось выносить! Но зачем страдать и поддерживать процесс, который идет хуже некуда? Пока инженеры фокусировались на других задачах, мы нарисовали общий сайзинг для всех серверов и кластеров СУБД, составили таблицу, и я лично пошел к тому специалисту, которого тогда уже все боялись. Посидели, поговорили, нашлись общие темы. Обсудили «портянку» на 100 серверов БД. Так наконец появилась карта миграции для всех баз данных до конца проекта. Больше не нужно было ходить к DBA с каждой мелочью, и процесс миграции встал на рельсы.

    Высокая обучаемость

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

    Желание быть «на гребне волны»

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

    Владение языком бизнеса

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

    Наличие опыта

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

    Необъективное мнение

    Мир ИТ сегодня разделен на два лагеря. В первом те, кто верит в облака, во втором — те, кто сталкивается с реальностью «большого ИТ» и понимает, что к эпохе digital еще долгий путь. Первые считают вторых динозаврами, дни которых сочтены. Но по факту on-premise пока не уступает место облакам, как предрекали аналитики и эксперты. Оба направления развиваются параллельно. И системные архитекторы крайне востребованы. Причем все больше с учетом роста роли ИТ в последние годы в разных сферах бизнеса.

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

    Автор: Сергей Терехин, руководитель отдела комплексных проектов «Инфосистемы Джет»

    Инфосистемы Джет
    Системный интегратор

    Комментарии 27

      +1
      спасибо. Но мне каженся тема не раскрыта — как же все таки стать архитектором то? Требования понатны, но где такие вещи как TOGAF, patterns, views и все прочее?
      PS. я — что то среднее между тремя видами, иногда сам задумаваюсь в чем же именно моя роль
        +3
        Как по мне, тема не только не раскрыта, но и подана довольно однобоко в меру собственного видения.
        Разделение на виды архитекторов часто зависит от размера компании, сложившейся практики ведения работ, объема легаси кода, опыта других членов команды и т.д., а приведенный список навыков нужен вообще любому хорошему ИТ специалисту, а не только абстрактному «архитектору».
          –1
          Вы правы, тема обширная и точно не поместится в один пост. Роли ИТ-архитекторов, как и их названия, сильно меняются в зависимости от ситуации. Например, системный архитектор в компании с собственным ИТ чаще всего координирует разные инициативы и проекты по ИТ-инфраструктуре. Он плотнее работает с подрядчиками, чем со своими коллегами. А системный архитектор в интеграторе — про непосредственное ведение проектов и генерацию идей для внедрения. Именно поэтому ширина его знаний и скиллов важнее глубины из-за разнородности задач.
          +1
          но где такие вещи как TOGAF, patterns, views и все прочее?

          На теплых полках с монографиями их изобретателей.)

            –2
            На наш взгляд, сертификация TOGAF и изучение других фреймворков и методологий — необязательный пункт на пути становления системного архитектора. Чем больше багаж знаний специалиста, тем легче ему будет ориентироваться в почти бесконечном мире ИТ-инфраструктуры. В тоже время необходимые знания можно накапливать разными способами, в том числе через практику. Какой путь выбрать — дело каждого. Главное, не бояться брать на себя роль архитектора, а вместе с ней ответственность и сложные комплексные задачи.
              0

              Совершенно верно. Но в том то и вся хитрость! Каждая глобальная компания в/с которой я работал имеет свой фреймворк. Как правило гораздо примитивнее тогафа, но им хватает. Вся работа по сути заключается в трансляции менее технических требований в более технические элементы и делать можно кучей разных способов, потому и не учат этому. Как itil всего лишь набор знаний основанных на опыте и здравом смысле, тогаф просто более сложный фреймворк основаный на опыте собранном из кучки мелких. Как с айтилом, можно самому наступать на грабли, а можно посмотреть как другие это делали и выбрать полезные для себя элементы. Базироваться тол ко на своих знаниях — это наступать самому на грабли. Да, без этого никак и опыт важнее всего, но далеко на этом тоже не уехать. В лучшем случае получится неосознанная компетентность, после долгих лет жития в сначала неосознанной и затем осознанной некомпетентности ;) систематический поход — это практически вся работа архитектора и есть, и фреймворки этому радикально помогают.

            0
            Владение языком бизнеса

            На этом я могу опустить руки и сказать "ну, не моё..".

              –1
              Опустить руки можно, когда были тысячи попыток, провалов и предприняты новые попытки. Автор поста своим примером показывает, что даже самый закоренелый технарь при желании может разобраться в основных задачах бизнеса и понять, как их решение зависит от ИТ-инфраструктуры. Например, можно ли терять данные в базах (RPO>0)? Можно, если бизнес-процесс, позволяет их перечитать или перезапросить и заново поместить в базу. Иногда без такого понимания, предъявляемые требования к ИТ-инфраструктуре оказываются невыполнимы или их выполнение обходится необоснованно дорого.
                0

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

              0
              в чем отличие «solution-архитектора» от «product-manager»? PM выступает посредником между внешним заказчиком и продуктовой командой, а SA работает с внутренним заказчиком, или что-то другое?
                0
                Контекст ролей зависит от компании, потому что часто названия и заложенные в них смыслы разнятся.
                В целом PM отвечает за сроки и формальные обязательства перед заказчиком, например, полноту заявленного функционала, а SA больше за архитектуру приложения и то, как именно она реализует обещанный функционал. Плюс, по нашему опыту, PM появляется, когда проект или продукт уже сформулированы, то есть на этапе разработки или внедрения, а SA, как правило, участвует в генерации самой идеи, зачастую вместе с заказчиком.
                0
                перебрался в Питер

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

                  0
                  В Москве и Питере концентрация заказчиков, задач и экспертов, у которых можно многому научиться. Это факт.
                  В тоже время есть «очаги» крупных ИТ-проектов в других городах. Например, сейчас всё больше крупных ЦОД появляются далеко за пределами Москвы, чтобы оптимизировать расходы на строительство. Пропускная способность магистральных оптических каналов при этом растет и перестала быть барьером для использования удаленных дата-центров.
                  +2

                  А всё-таки, как стать? Смотришь вакансии — везде опыт архитектором или CTO требуется. Прям джуном себя чувствуешь, правда опции "а давайте я у вас за еду поработаю" нет

                    0
                    Описание вакансий составляются HR-ами. Для них важен поиск по ключевым словам. И, конечно, любая компания хочет заполучить опытного и крутого эксперта, но на практике вариантов больше.
                    Опыт можно набрать и без официального титула системного архитектора. От компании к компании ситуации очень разные, но, вероятно, путь один – искать архитекторские задачи, брать их и нарабатывать опыт.
                    Как пример – история нашего коллеги, который чуть больше года работает системным архитектором. Он начинал в нашей компании дежурным инженером, подрабатывая еще будучи студентом. В один момент возглавил группу инженеров и отвечал за внедрения проектов. Но потом решил попробовать себя в роли системного архитектора и самому прорабатывать сложные ИТ-решения. Какое-то время ему даже пришлось «усидеть на двух стульях»: коллега руководил группой инженеров и примерял на себя задачи системного архитектора. Эксперимент оказался удачным, теперь он конструирует масштабные ИТ-системы.
                    И таких примеров в нашей команде немало. Многие сегодняшние системные архитекторы успели поработать и инженерами-проектировщиками и «чистыми» Field-инженнрами, а потом устали от кнопок, захотели больше ответственности и стали пробовать себя на другом поле. Действуйте, все получится!:)
                      0

                      В целом получается, что наиболее частый способ: прийти на "линейные" позиции в компании, где архитекторов много (больше двух) и расти в рамках компании?

                        0
                        Это самый очевидный путь.
                    0
                    Имхо, если уж и выбирать роль архитектора, то точно не системного. На сегодня чистый системный/инфраструктурный архитектор (как описано у автора) — вымирающий вид, и в первую очередь именно из-за облачных сервисов. Зачем париться с инфраструктурой, ее настройкой, поддержкой, гарантией, ремонтом, вот этим вот всем, если это можно отдать облачному провайдеру за ежемесячную мзду? А значит, системный архитектор, знающий наизусть отличия пяти конкурентных бекап-решений, и умеющий запланировать железо на пару лет вперед — становится нафиг не нужен. Да, еще есть ентерпрайзы с их легаси и стремлением все держать у себя, но и и они постепенно сокращаются, т.к. для новых продуктов именно облака — природное место обитания. Ну еще есть собсно сами облачные провайдеры/интеграторы, но их очень конечное множество, и на всех их не хватит:) Собственно, как подтверждение моей мысли — уже несколько лет, что в вакансиях, что в обращениях хед-хантеров — все хотят солюшн/продакт архитекторов, но никак не системщика.
                    Ну а на место системных архитекторов приходят облачные архитекторы, но это совершенно другая специализация, не сильно пересекающаяся с багажом знаний системного архитектор — и подходы разные, и продукты другие.

                    З.Ы. Если что — я чистый системный архитектор, выросший из инженера, и сейчас стоящий на перепутье, куда податься -то ли в солюшн, то ли в клауд архитекторы.
                      0
                      По мне, даже если твои сервисы в облаке, все равно есть работа для архитектора. Понятно, на маленькие проекты нет, а на большие очень даже надо.
                      Я тоже думал, что следующая ступень будет архитектор, по описанию ТС-а, solution architect. Теперь, не так твёрдо стою на этой позиции, есть мысли поменять область.
                        +2
                        Зачем париться с инфраструктурой, ее настройкой, поддержкой, гарантией, ремонтом, вот этим вот всем, если это можно отдать облачному провайдеру за ежемесячную мзду?
                        — затем, что в энтерпрайзе были, есть и будут вещи, которые останутся на земле. Потому что гибрид без поддержки важной наземной части это хромой инвалид.
                        Нужны специалисты, которые точно могут сказать, как, почему и зачем это необходимо делать именно на земле (или в облаке). У которых есть глубокое понимание формирования TCO, факторов, влияющих на SLA как компонентов, так и систем в целом.
                        Востребованность таких специалистов количественно невелика, но по значимости она выше, чем у руководителей команд разработки или идеологов Agile/SCRUM и ещё многих модных на сегодня профессий.
                          0

                          А чем она совершенно другая? Вот надо выбрать для проекта инфраструктуру и два вопроса сразу — покупаем своё или арендуем, классика или облако (облако можно тоже своё поднять). Ну и с облаком: тупо виртуалки берём и разворачиваем всё на них почти по классике, или максимально используем вендорские сервисы (ещё не знаем какого вендора). Ну и куча гибридных вариантов… Как можно делать разумный выбор не зная одного из вариантов?

                          +1
                          Менеджмент и любовь к людям <3

                          О господи, вы это сейчас всеръез? Про любовь к людям в капиталистическом обществе, где каждый мечтает только о личном успехе. За всеми громкими словами про «мы делаем мир лучше» и т.п. стоит банальная и простая мысль «я хочу дофига денег, но мир устроен так, что эту мысль надо прикрывать разными способами»
                            +1
                            В мире 7 817 410 000 людей и у каждого из них свой набор ценностей. Очевидно, что если работаешь с людьми, симпатия к ним как таковая помогает.
                            0

                            У вас получается, что архитектор это soft-skiller, а все остальное это опыт. Я правильно прочел? :)

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

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


                                А в том, что опыт нужнее образования, вы не одиноки :)

                              0

                              веткой ошибся

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое