По мере того как технологии развиваются в опенсорсном направлении, даже самый недальновидный генеральный директор начинает понимать, в чем смысл облачных технологий Amazon, что Gmail работает, Dropbox полезен, а CRMсистемы на порядок проще таблиц. Распространив эту логику на API вроде Stripe, умные приложения для умных вещей и распределенные реестры, подделать которые невозможно, даже самый закостенелый гендир задумается, зачем ему все эти архитекторы и клавиатурные виртуозы, эксплуатирующие системы, созданные в 1980-е годы (обходящиеся в целое состояние) и не стремящиеся к гибкости. Когда рынки, платформы и все финтех-сообщество приступает к выстраиванию пиринговой сети на основе алгоритмов, софта и серверов, даже Джейми Даймон вам скажет: надо что-то менять. Так оно и есть.
Удивительно, но множество инноваций в банках внедряется не технарями, а бизнес-аналитиками. Понятна и безотлагательность перемен, и то, что айтишники посрамлены. Банкиры и бизнесмены видят, как банкинг становится опенсорсным, и говорят: «Эй, ребята! Вы, BASIC-кишки нашего фортрановского банка, немедленно внедрите С++, а то нас обскачут на Java!» Примерно в таком духе. Банкиры видят угрозу, поэтому во многих репликах слышится страх.
• Джейми Даймон, СЕО банка JPMorgan Chase: «Когда я бываю в Кремниевой долине, то вижу, что [все они] отбирают наш хлеб».
• Урс Роннер, председатель совета директоров Credit Suisse: «Технологическая компетентность на уровне совета директоров – необходимость, а в скором времени она станет незаменимой составляющей финансовых институтов».
• Анри де Кастр, бывший СЕО AXA: «Цифровая трансформация – это уже не предмет выбора, а насущная необходимость».
• Ана Патрисия Ботин, исполнительный директор Santander: «Если сегодня задуматься о крупных игроках, окажется, что это не банки, а четыре крупные технологические компании (Google, Apple, Facebook, Amazon), которые стоят больше нас».
Руководители этих банков боятся технологической избыточности в своих организациях, поэтому реорганизуют их архитектуру, добиваясь слияния финтеха с банками. От этого должны проиграть тысячи штатных айтишников – разработчики и архитекторы. Однако не только они сойдут со сцены. За ними последуют многие их высокооплачиваемые сотрудники фронт-офиса, мнящие себя хозяевами Вселенной, тогда как на самом деле они операторы денежного рынка, выигрывающие чаще, чем проигрывающие. Их функции будут автоматизированы с помощью искусственного интеллекта и машинного обучения. Рыночные фонды уже движутся к пассивному инвестированию. Скоро специалист по управлению инвестиционными фондами займет место рядом с руководителем отдела технического обслуживания – и они будут размышлять, куда же делись их рабочие места.
Это не какой-то оторванный от реалий прогноз, а очевидный этап постепенного перехода от собственных уникальных систем к открытости и от внутрикорпоративных технологий, в которых никто (кроме технологов) не разбирается, к технологиям, ориентированным «наружу», понятным всем, в том числе клиенту.
Клиентоориентированные открытые системы, обеспечивающие совместимость рынков, – вот к чему движется мир, и если вы этого еще не осознали, хотя работаете в банке, то учитесь поддерживать, разрабатывать и создавать роботов и умные системы, поскольку именно в этих отраслях уцелеют те немногие технари, на которых в будущем еще возникнет спрос.
Банк, ориентированный на разработку
Во многих банках бытует мнение, что задача IT-директора – использовать технологии. Как правило, это они и делают. Но не этим им предстоит заниматься в будущем.
Человек, руководящий технологическими разработками в любом крупном банке, должен быть двигателем перемен. Все потому, что его основная задача – менять АБС, превращая их в опенсорсные структуры, основанные на использовании облачных технологий, аналитики, API и искусственного интеллекта. Это серьезная задача. Но самое важное – что делать, когда эта работа завершена?
Меня просветил мой друг Сергей Даниленко, специалист из технологической компании PrivatBank, которая, так уж случилось, предлагает в том числе и банковские услуги. Сергей занимает пост директора по маркетингу и отвечает за глобальное продвижение услуг банка, цифровая АБС которого работает в облаке, предоставленная сотнями API, образующих микросервисную архитектуру.
Микросервисная архитектура позволяет распределить все операции по обновлению и модернизации между небольшими независимыми командами, которые смогут управлять компонентами банковских технологий через внутренние приложения и API. Чтобы этого добиться, банк должен разделить все процессы, которые необходимо выполнить, и реализовать каждый из них в виде крошечного приложения. Каждое приложение будет разрабатываться отдельно и помещаться в сеть. Благодаря стандартизации все эти крошечные компоненты затем можно будет объединить, и это «целое» будет надежным и удобным в обслуживании прежде всего потому, что модернизироваться и обслуживаться будут мелкие фрагменты, а не колоссальная монолитная структура.
Все это очень отличается от устройства старых АБС, с которыми я привык иметь дело. Их работа обеспечивалась программами, состоящими из тысяч строк кода; требовался жесткий контроль изменений, поскольку любое обновление кода могло отозваться по всей системе и сломать ее. Микросервисная архитектура работает совершенно иначе. Можно менять что угодно и когда угодно, поскольку все компоненты независимы, разделены и распределены.
Еще один критически важный фактор: бизнес строится на микропроцессах. Хороший пример Stripe – API для организаций, которым нужна упрощенная система проверки. В ноябре 2016 года (спустя шесть лет после основания) она оценивалась в $9,2 млрд – очень неплохо для микросервиса.
Иными словами, финтех позволяет открепить все функции и процессы от продуктов и поставщиков ПО и предлагать их в виде микросервисов, которые благодаря DevOps, облачным технологиям и API могут быть переосмыслены в виде любой бизнес-модели и структуры на ваш вкус.
Данную концепцию удивительно образно объяснил Адриан Кокрофт, бывший облачный архитектор компании Netflix. Он рассказал о переходе компании от DVD к потоковому вещанию и о том, каким масштабным изменениям пришлось подвергнуть всю технологическую структуру. Вот на чем он заостряет внимание:
• Теперь функции – это крупные компании.
• Сегодня не осталось соборов – только базары.
• Сегодня приложения – это инфраструктура.
• Ключевой аспект – проектирование, инициированное разработчиками.
• Монолитов больше не осталось, теперь все реализовано в виде микросервисов.
• Если в вашей организации принята каскадная модель разработки – это прискорбный факт.
• Когда разработчики сами отвечают за проектирование продукта, он получается гораздо более гибким и интересным[17].
Банки должны взять эти тезисы на заметку и учиться на них, ведь у многих из них, с кем я имею дело, система контроля выстроена по принципу «сверху вниз». Идея распределить контроль между разработчиками там будет воспринята как ересь. Но все-таки именно это нужно сделать.
IT-директор будущего – это не IT-директор
Как я уже говорил, задача IT-директора – перейти от управления империей инженеров техподдержки к созданию распределенной организации разработчиков. Смена роли связана с переходом от иерархической структуры, все элементы которой разрабатывались компанией под свои нужды, к организации, ориентированной наружу, более «плоской», открытой и широкой. Большинство разработок будет поступать извне, поскольку они не предназначены исключительно для внутреннего использования и не создаются такими. Если банки перенесут свои сервисы на платформы и станут действовать на открытых рынках, они, как никогда, плотно будут вовлечены в этот процесс, но старые добрые времена, когда бизнес-процессами можно было обладать, уйдут в прошлое.
Таким образом, IT-директор путем постепенных изменений должен превратить организацию из закрытой и замкнутой в опенсорсную и широкую. Банк превращается из собора в базар, из монолита в рынок. Такова роль двигателя перемен: создать новую компанию, работающую по принципу «банкинг – это платформа».
«Банкинг как платформа» – это весьма актуальный тренд, о котором я писал еще семь лет назад, и вот мы до него дожили. Это возможность свободно подключить и использовать все банковские функции, которые будут работать как приложения через API. Речь не только о внутренних приложениях и API, но и о сторонних. Это новый принцип работы, где банк встраивается в экосистему технологических компонентов. Напоминаю: банк руководит этими компонентами, поскольку остается ведущим игроком на рынке, обладает миллионами клиентов, миллиардными активами и лицензией регулятора. Но дни, когда банк был полностью замкнутой на себя, закрытой структурой, сам себе закон, – в прошлом.
Сегодня банк – это интегратор компонентов в новом рыночном окружении, где банкинг – это сервис или платформа. Как только IT-директор завершит эту работу, его роль снова изменится. Он превратится в дирижера. Руководитель организации, развертывающей банкинг как платформу, должен отслеживать все группы от бэк-офиса (ударные) до миддл-офиса (духовые) и фронт-офиса (струнные), координировать их работу, чтобы они играли слаженно, в едином темпе.
Эта роль непростая, поскольку некоторые элементы новой банковской платформы «взяты из другого оркестра». Времени на репетиции почти нет, а оркестр должен играть круглосуточно, без выходных. Вот почему столь важно, чтобы дирижер позволял оркестру, управляемому разработчиками, самостоятельно распределять партитуру. У каждого музыканта в оркестре свое место. Кто-то может сфальшивить, но в общем музыкальном рисунке этим можно будет пренебречь.
Думаю, это последний элемент в описанной долгосрочной мозаике. Я давно слышу, что организационные структуры должны переходить от иерархического арм