Сергей Николаев: «ИТ-архитектор должен понимать и бизнес, и ИБ лучше, чем они понимают друг друга»

Вы отвечаете за ИТ-архитектуру в Росгосстрахе. Что входит в ваши задачи?

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

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

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

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

ИТ-архитектор для реального сектора. Кто это?

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

Моя задача как руководителя — выстроить эту функцию так, чтобы она работала системно, эффективно и приносила реальную пользу.

Насколько страховой компании нужна единая цифровая платформа? Или бизнесу стоит дать больше свободы?

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

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

У любого бизнес-подразделения есть рамки: бюджетные, регуляторные, корпоративные. Классический пример — работа с персональными данными. Законодательства разные, трактовки сложные, риски высокие. Ожидать, что каждый бизнес-юнит сам все это учтет — наивно. Для этого и существуют централизованные компетенции — юридические, ИБ, архитектурные.

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

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

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

Это как качественный контекст: если у вас хорошая среда, в ней даже неудачные эксперименты не приведут к катастрофе. Ошибки будут локальными. А успехи масштабируемыми. Вот это и есть настоящая свобода в рамках архитектуры.

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

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

Как навести порядок в ИТ-архитектуре с помощью трех ключевых инструментов

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

Раз уж мы заговорили о взаимодействии, один из классических конфликтов — между бизнесом и безопасниками. Бизнесу нужно двигаться вперед, ИБ — обезопасить все, что движется. Архитектура в таких случаях оказывается между двух огней?

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

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

Роль архитектуры здесь — быть посредником. Мы лучше, чем бизнес, понимаем ИБ, и лучше, чем ИБ, понимаем бизнес. Это позволяет предложить решение, которое учитывает обе позиции. При этом архитектура не подменяет собой ни одну из сторон. Мы не «прокси» ни для бизнеса, ни для ИБ. Мы те, кто помогает сторонам услышать друг друга.

Мы уже много лет говорим об импортозамещении, особенно активно — с 2022 года. Есть ли у вас честные критерии оценки отечественного софта? Или приходится подгонять реальность под то, что «доступно»?

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

Да, у нас есть критерии, и они абсолютно соответствуют требованиям регулятора. Мы не придумываем ничего от себя. А вот как это работает на практике — можно условно поделить на две корзины.

Первая — это те случаи, где отечественные вендоры действительно есть. Причем они сами отлично понимают, что импортозамещение стало приоритетом. За последние три года многие решения из статуса «мы знаем, как сделать, но пока не сделали» превратились в зрелые продукты. Сейчас есть компании, которые уверенно заявляют о полной импортонезависимости своих продуктов и готовы подписаться под своими словами.

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

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

А если решения в принципе нет?

Это похоже на вторую корзину. Бывают сегменты, где отечественных решений просто не существует. Особенно в таких специфических зонах, как, например, отраслевые страховые платформы для крупных компаний. Таких в мире немного вообще, а в России тем более.

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

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

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

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

То есть по сути — возврат к самописным системам?

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

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

Расскажите про «альтернативные болезни». Есть ли проблемы с легаси?

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

Более того, система становится легаси не потому, что «у вас старая Java», а потому, что в какой-то момент мы понимаем: если продолжим вкладываться в поддержку этой системы, то через пару лет она, поддержка, начнет стоить дороже, чем ее замена. А наша задача, как всегда: тратить меньше, зарабатывать больше.

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

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

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

А как вы со стороны архитектуры участвуете в создании новых клиентских сервисов?

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

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

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

Есть ли в архитектуре страховой компании какая-то уникальность по сравнению, скажем, с банками или телекомом?

Безусловно. У страхового рынка в целом есть своя специфика, и у Росгосстраха в частности тоже есть своя уникальность. Но если обобщать, все можно разделить на несколько блоков.

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

А вот «ядерная» страховая деятельность — это уже совсем другое. Страховой и операционный учет, специфическая отчетность, регулирование убытков, процесс тарификации, все это не похоже ни на банки, ни тем более на телеком. Здесь своя логика, свои процессы и, соответственно, свои архитектурные требования. Дальше все упирается в масштаб. Большая страховая компания, такая как наша, не может себе позволить выполнять все эти процессы вручную. Невозможно нанять тысячи сотрудников поддержки или специалистов по урегулированию, поэтому все должно быть автоматизировано. И это отражается в архитектуре: появляются сложные решения, интеграции, оркестрации, платформенные компоненты. Маленькой страховой, особенно если она нишевая, можно обойтись чем-то попроще — базовой коробкой, условным «1С для страхования».

Так что специфика архитектуры — это и отрасль, и масштаб. Чем шире продуктовая линейка и сложнее процессы, тем уникальнее архитектура.

А можно ли, на ваш взгляд, передавать архитектурные функции на аутсорс?

Зависит от того, какие именно функции. Архитектура — понятие широкое. И когда говорят об аутсорсе, всегда всплывают два основных риска.

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

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

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

Какая архитектурная ошибка оказалась самой дорогой?

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

Если же говорить о решениях, которые можно было бы принять по-другому даже с теми вводными, что были тогда —таких я припомнить не могу. В больших архитектурных решениях всегда есть коллективное обсуждение, анализ, методологии. Ошибки в этом контексте — скорее повод для рефлексии: что не учли, где нужно было смотреть шире, что стоит изменить в подходах к анализу и управлению рисками.

А если представить, что можно было бы переписать архитектуру Росгосстраха с нуля — что бы вы сделали иначе?

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

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

И напоследок. Представьте, вы проводите собеседование архитектора и можете задать только один провокационный вопрос. Что бы это было?

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

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

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