Привет, Хабр! Меня зовут Роман Логинов, и я — Solution Architect Team Lead в «Лаборатории Касперского». Этот пост — отражение моего опыта и погружение в тонкости работы Solution Architect. На мой взгляд, эта роль реально развивает людей и меняет индустрию, заставляя специалиста по-новому смотреть на вещи, а саму отрасль IT — эволюционировать.



Если вам интересно, как это происходит, почему с появлением Solution Architect’ов ведение проектов стало удобнее и продуктивнее, а также как в роли SA можно развернуться на полную и сделать крутой, нестандартный продукт — приходите под кат.

Может быть, после этого поста вы сами захотите стать Solution Architect’ом: в конце я поделюсь своими наводками и советами, как этого добиться.

Почему должность Solution Architect стала необходима

Позиция Solution Architect появилась в индустрии сравнительно недавно — пять-шесть лет назад. Примерно тогда же, когда я пришел в Kaspersky.

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

У каждого аккаунт-менеджера бывает по 5-10 больших, ключевых заказчиков, в том числе очень крупных — например, уровня промышленных гигантов, топовых банков и федеральных ведомств. Успеть проработать все задачи для каждого заказчика в одиночку — практически невыполнимая миссия: надо знать технические особенности заказчика, потребности его отдельных подразделений (а они могут быть обособленными, со своими ЛПР-ами и бюджетами), потребности дочерних организаций и так далее.

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

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

Стало понятно, что нужен подкованный человек, который мог бы стать единой, узловой точкой входа для всех технических вопросов от определенных заказчиков. То есть этот специалист, во-первых, разбирается в технологиях, которые есть на рынке, в IT, в ИБ; во-вторых, глубоко погружен в продукты компании, где он работает; а в-третьих, хорошо разбирается в инфраструктуре заказчика и состоит с ним в тесном контакте. Это и есть Solution Architect. Единый центр, который отвечает за всю техническую архитектуру, продвижение решений и реализацию проектов.

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

Как SA реально влияет на продукты и индустрию

Как выглядит такое творчество с продуктами и решениями на практике? Я приведу несколько примеров, но с учетом того, что многие подробности находятся под NDA. Так что если где-то не хватает конкретики, причина в этом.

У меня был заказчик — разработчик образовательного контента. Контент представляет собой огромный набор файлов. И для нас ставилась уникальная задача: нужно было проверить, не содержатся ли в этих файлах экстремистские лозунги, ссылки на порнографию и другие подобные вещи. Плюс убедиться, что сами файлы не вредоносные. Файлов были буквально десятки тысяч. Как их проверить и убедиться, что все нормально? Не совсем понятно. Заказчик походил с этой задачей по рынку, не смог понять, как это реализовать, обратился к нам.

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

Был и другой вариант. Я обратился к нашим вирусным аналитикам: объяснил ситуацию, рассказал, что для нас это хорошая возможность расширения. Мы в следующем году можем использовать эту активность, как door opener, открыть ею путь к сотрудничеству с этим клиентом. Мы докажем, что знаем свое дело, и сможем предложить заказчику дополнительно другие продукты.

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

Другая похожая ситуация: в некоторых случаях мы делали анализ по поиску утечек информации на основе нашего сервиса Digital Footprint Intelligence, который позволяет искать в Интернете и дарквебе угрозы, направленные на конкретного заказчика. Мы на определенных условиях по определенным ключевым словам организовывали поиск утечек и своевременно передавали заказчику информацию о них. Чтобы он понимал, что действительно у него или в подконтрольных ему организациях произошло что-то плохое, видел масштаб проблемы и мог работать с последствиями.

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

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

Или возьмем, например, нашу систему мониторинга событий информационной безопасности, KUMA (Kaspersky Unified Monitoring & Analysis). На тот момент к нам обратился один очень крупный заказчик, чьи требования на российском рынке никто не закрывал. Да, организация использовала ряд наших экспертных систем и наше решение для защиты эндпоинтов. Но ей не хватало центрального компонента, который мог бы все наши системы объединить, связать их различными сценариями, чтобы была единая консоль, на которой специалист видел все события и инциденты, происходящие в инфраструктуре.

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

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

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

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

Есть ряд других клиентов, которые тоже «драйвили» нас создавать новые продукты.

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

По большому счету, это локальная копия нашего облака KSN (Kaspersky Security Network), где содержится вся информация с эндпоинтов, расположенных по всему миру, о вредоносах, угрозах, приложениях, чистых файлах, которые мы когда-либо встречали и отрабатывали с помощью наших решений. С KPSN мы позволяем клиентам в одностороннем порядке загрузить всю эту информацию о репутации файлов на их собственный сервер. И дальше наши решения по защите почты, серверов, рабочих станций, эндпоинтов, по защите от целевых атак у этих клиентов уже не обращаются в Интернет за запросом репутации объектов. Они не обращаются к нашему облаку, а обращаются уже локально к этому серверу, который располагается на территории заказчика, для того чтобы запрашивать репутацию объектов.

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



Некоторые заказчики просят доработать определенные продукты под их инфраструктуру, и это тоже работа для SA. Тут приведу простой пример. У нас всегда были эндпоинты для Windows, Linux, Mac. Под Линукс наше решение всегда работало с архитектурой x64. Но сместился фокус: сейчас в стране активно идет импортозамещение, появляется много отечественных технологий, новые процессорные архитектуры. Понятное дело, что от мировых лидеров мы сильно отстаем, но выбора у организаций нет. Поэтому новые отечественные технологии нужно внедрять. Например, решения на базе процессоров «Эльбрус» и «Байкал».

Наш стандартный KES (Kaspersky Endpoint Security) для Linux с ними не работал. Заказчики пришли с проблемой: скоро приедет огромная партия серверов, тысячи, а то и десятки тысяч. Без антивируса ввести их в эксплуатацию нельзя, стандарты у клиента жесткие.

Мы вышли на диалог с клиентами: собрали информацию об архитектуре серверов, которые будут использовать, договорились о минимальном функционале, который реализуем для нового продукта изначально. Нельзя просто полностью портировать весь текущий функционал на новый процессор, тут неизбежно сильное отставание. Многие фичи воплотятся в последующих релизах, но не на старте. Поэтому нужно было заранее проработать клиентские ожидания. Опять же, это роль SA в связке с командой разработки. Когда мы создали это решение, оно стало для клиента драйвером покупать у нас больше лицензий. Помимо тех, которые он закупал раньше, заказчик стал брать на несколько тысяч больше. А после мы вывели новый продукт на рынок для других наших клиентов.

Это только малая часть того, к чему я и мои коллеги приложили руку. Как я уже отметил, значительная доля наших проектов находится под NDA, а для того, о чем можно говорить, не хватит одной статьи :)

Эволюция Solution Architect: как эта должность развивает специалиста

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

Творчество, интересная и нестандартная работа — словом, ключевой этап эволюции в профессии, когда претворяется в жизнь все то, о чем я рассказал выше, начинается через год-полтора работы в должности Solution Architect.

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

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



И человек, который перешел от продажи готовых кубиков-решений к творческому подходу, необычайно ценен. Такому Solution Architect’у доверяют, его мнение уважают. Для многих клиентов он становится так называемым trusted advisor. То есть помогает заказчикам построить стратегическую концепцию, аналогов которой нет на рынке и которая поможет решить именно их задачи, удовлетворит их потребности.

Что поможет стать Solution Architect’ом: компетенции, навыки, путь в IT

Чтобы прийти в профессию и стать сильным SA, на мой взгляд, нужно уверенно владеть тремя наборами компетенций.

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

Кроме того, нужно быть готовым дискутировать и общаться с заказчиком на глубоко технические темы. К примеру, как маршрутизировать сетевой трафик для сетевых решений. Или как интегрировать с почтовой системой для решений по защите почты. Для SIEM (KUMA) — как настраивать сбор событий с разных источников, какие правила корреляции необходимо задействовать в инфраструктуре конкретного заказчика, как происходит обновление и написание контента и так далее. Если ты не будешь как SA показывать, что ты в этом разбираешься, то заказчик не будет понимать, в чем твоя ценность. Зачем общаться конкретно с тобой, если ты не погружен в продукт?

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

Если что-то идет не по плану, то необходимо в онлайн-режиме корректировать ожидания, договариваться о новых сроках, объяснять причины, почему мы «вот прямо сейчас» это сделать не успеваем, «но вот есть новый срок, к нему мы уже точно успеем». С точки зрения менеджмента проектов это обязательно. При этом проектов много, параллельно может быть несколько десятков. И за всеми необходимо уследить. Не бывает так, что ты направил пресейла готовить пилот и забыл про эту историю на месяц. Активное участие необходимо, надо постоянно думать о ситуации и понимать, что происходит на всех сторонах, чтобы никто не потерялся, чтобы все помнили про проекты, чтобы те договоренности, которые были изначально поставлены, выполнялись в срок.



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

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

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

А как у вас?

Хотя мы обширно погрузились в работу и проекты Solution Architect’а, а пост вышел довольно большим, все особенности и тонкости в нем все равно не покрыть. Можно еще много сказать про то, как SA взаимодействуют с другими отделами в «Лаборатории Касперского», какие качества проявляют на разных проектах, и привести немало примеров, которые были у меня и коллег. Но рассказать обо всем в одной статье невозможно. Так что буду готовить следующую :)

Ну а пока, конечно, хочется почитать ваши мнения и истории. Как от тех, кто сам работает Solution Architect’ом, так и от тех, кто с ними взаимодействует. Отличается ли ваш опыт от моего в «Лаборатории Касперского»? Какие интересные задачи у вас были и как вы к ним подходили? Каково работать с SA в команде? Пишите в комментах.