Интервью TAdviser:
ИТ-директор Альфа-Банка Сергей Поляков
О грядущей цифровизации 2.0

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

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

Сергей Поляков: Работа банка со мной лично точно перетекла полностью.

Идея банковской цифровизации в целом состоит в том, чтобы перевести клиентов на удаленные каналы самообслуживания. Мобильный банк — один из таких каналов. Хорошие, во всяком случае, на вид, мобильные банки на сегодняшний день не делает только ленивый. Я пользуюсь многими из них, у всех есть какие-то особенности, прикольчики, но в основном, отличия косметические. На сегодняшний день, банковское мобильное приложение – это зрелый продукт, и даже если вы не умеете делать мобильные приложения сами, вы можете обратиться во внешнюю организацию, которая вам его построит.Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft 2.2 т

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

На первой волне цифровизации перед банками стояла задача перенести в мобильные приложения базовые одношаговые транзакционные взаимоотношения с клиентом — посмотреть выписку, перевести деньги. Зашел, сделал, вышел. Все было просто и быстро, эджайл-команды пекли микросервисы, поддерживающие подобные функции, как пирожки, time-to-market исчислялся часами, все радовались и думали, что так будет всегда.

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

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

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

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

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

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

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

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

Сергей Поляков: Два основных, одно из которых связано с CRM, с демографией и личной прямой и обогащенной информаций, а другое – операционное. Все больше и больше функции операционного приложения перекочевывают в демографическое, в CRM++, наш Единый фронт. Почему все эти функции не могут быть также вынесены в другие каналы, например, в банкоматы? Я не знаю. Для меня, например, загадка, почему экран банкомата такой, какой он есть. Это какой-то пережиток прошлого. Почему он не выглядит как экран в вашем мобильном приложении? Ведь все функции те же самые. Думаю, это должно поменяться.

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

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

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

Сейчас мы свободно мешаем команды из своих сотрудников и специалистов со стороны подрядчиков, но общий принцип такой: если это целевая платформа, то мы предпочли бы нанять людей в штат. Если это нецелевая платформа, мы предпочли бы иметь внешнего контрактора, который ее поддерживает. Причем для нас не важно, является ли платформа mission critical. У нас есть нецелевые вещи, которые, тем не менее, mission critical.

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

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

Сергей Поляков: «Альфа-лаборатория» работала по принципу «клиентских путей» (или customer journey), это определенная форма организации разработки. Сейчас «Альфа-лаба» нет, но подход к выстраиванию нового функционала для конечного клиента и для бизнеса остался. Большая часть бизнес-функционала будет сделана с помощью подобного подхода, это часть стратегии банка, и этот подход наверно на сегодняшний день является де-факто стандартом для продвинутых организаций. Но есть на этом пути и опасность – организация ИТ «от клиента» а не «от технологической платформы» может привести к дроблению технологических платформ.

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

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

Вначале беседы мы говорили о том, что на первой фазе цифровизации реализуется относительно простой функционал, связанный с быстрыми одношаговыми транзакциями и коммуникациями между клиентами и банком. Но на второй фазе уже необходимо интегрировать сложные процессы, и это уже происходит в мидл- и бэкофисе. На этом этапе кунсткамера технологий, прототипов, MVP становится не просто дорогим развлечением, но еще и начинает ломать то, ради чего мы пошли в эджайл — Time-to-market.

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

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

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

Сергей Поляков: Да, понимают. Цифровизация 1.0 шла примерно с 2006 до 2012-2013 годов. Довольно быстро в режиме Agile появлялись технологические артефакты, плодились мобильные банки, интернет-приложения. Но затем вдруг неожиданно все замедлилось, а ИТ-менеджеры стали говорить: «ой, вы знаете, тут работы на два года, а тут на два миллиона долларов, а тут надо купить лицензии…». Но как же? Было же так хорошо еще совсем недавно! Что случилось? А случилось то, что наплодили ингредиентов, технологических стеков, а следующий класс решений цифровизации 2.0 уже требует внутренней интеграции. Интеграция — это долгая, неприятная и муторная вещь.

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

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

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

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

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

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

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

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

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

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

У нас появляется единая платформа для работников отделений, которая должна быть трансмодальной, объединять как CRM, так и операции, мы об этом уже немного говорил — в своей работе с помощью единого приложения клиентский менеджер должен иметь возможность и опознать клиента, и понять его, и продать ему продукт, и выполнить его запрос.

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

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

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

Сергей Поляков: Она уже сползлась обратно, в другие структурные подразделения. Есть, безусловно, ИТ анклавы, которые расположены внутри бизнес-подразделений — в инвестиционном банке, в процессинговом центре. Но в основном ИТ консолидируется. Общая численность 3000 человек примерно пополам разделена между сопровождением и развитием. В направлении развития, я думаю, мы придем к тому, что примерно половина людей будет работать «клиентскими путями», а другая половина будет связана с платформенными, более глубокими разработками. Это, наверное, какая-то версия two-speed IT (бимодальность или двухскоростная ИТ-модель, — прим. TAdviser). Есть организации, которые говорят, что two-speed IT мертва и так работать не надо, что вся организация должна быть Agile. Я в это не верю.

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

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

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

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

Сергей Поляков: Облако — это модное слово, оно пришло к нам в жизнь усилиями многих, наиболее известно наверно Amazon, и ему есть место. Но надо понимать вот что. Цель облака — бесконечное бесступенчатое масштабирование вычислительной инфраструктуры, следующее росту достаточно простого, гомогенного бизнес сервиса, вроде соцсети, интернет-магазина, и т.п. Бизнес- и ИТ-модели таких организаций сейчас пристально изучаются, их побаиваются, мол, сейчас они в финансы ринутся, их методы берутся за пример. Коллеги из некоторых банков ездят в Силиконовую долину, смотрят как работает Facebook или Google, восхищаются инфраструктурой. Это здорово, но при этом надо понимать, что универсальный банк — это гораздо более сложная вещь, чем Facebook, Google или «Яндекс». Сложность процессов несравнима. В конечном итоге, тот же Facebook — это в принципе один очень продвинутый цифровой сервис, решающий, с ИТ точки зрения, задачу масштабирования на миллиард пользователей. Задачи универсального банки совсем иные, структура сервиса и продукта несоизмеримо сложнее, и просто наращивание облачных мощностей задачи наши не решает.

Сергей Поляков: В частности. Нет в Facebook задачи надежности, по нашим меркам. И в Гугле нет — ну не получите вы сообщение от какого-то своего приятеля или не увидите его в ленте — и что с вами будет? Или увидите разное содержание ленты с разных устройств? Или вам на почту дважды придет какое-то сообщение — и что дальше? Что с вами случится? А вот если у вас остаток на счете разный в телефоне и банкомате, или зарплата дважды пришла — тут вы встрепенетесь…

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

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

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

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