Во многих банках бытует мнение, что задача IT-директора – использовать технологии. Как правило, это они и делают. Но не этим им предстоит заниматься в будущем.
Человек, руководящий технологическими разработками в любом крупном банке, должен быть двигателем перемен. Все потому, что его основная задача – менять АБС, превращая их в опенсорсные структуры, основанные на использовании облачных технологий, аналитики, API и искусственного интеллекта. Это серьезная задача. Но самое важное – что делать, когда эта работа завершена?
Меня просветил мой друг Сергей Даниленко, специалист из технологической компании PrivatBank, которая, так уж случилось, предлагает в том числе и банковские услуги. Сергей занимает пост директора по маркетингу и отвечает за глобальное продвижение услуг банка, цифровая АБС которого работает в облаке, предоставленная сотнями API, образующих микросервисную архитектуру.
Микросервисная архитектура позволяет распределить все операции по обновлению и модернизации между небольшими независимыми командами, которые смогут управлять компонентами банковских технологий через внутренние приложения и API. Чтобы этого добиться, банк должен разделить все процессы, которые необходимо выполнить, и реализовать каждый из них в виде крошечного приложения. Каждое приложение будет разрабатываться отдельно и помещаться в сеть. Благодаря стандартизации все эти крошечные компоненты затем можно будет объединить, и это «целое» будет надежным и удобным в обслуживании прежде всего потому, что модернизироваться и обслуживаться будут мелкие фрагменты, а не колоссальная монолитная структура.
Все это очень отличается от устройства старых АБС, с которыми я привык иметь дело. Их работа обеспечивалась программами, состоящими из тысяч строк кода; требовался жесткий контроль изменений, поскольку любое обновление кода могло отозваться по всей системе и сломать ее. Микросервисная архитектура работает совершенно иначе. Можно менять что угодно и когда угодно, поскольку все компоненты независимы, разделены и распределены.
Еще один критически важный фактор: бизнес строится на микропроцессах. Хороший пример Stripe – API для организаций, которым нужна упрощенная система проверки. В ноябре 2016 года (спустя шесть лет после основания) она оценивалась в $9,2 млрд – очень неплохо для микросервиса.
Иными словами, финтех позволяет открепить все функции и процессы от продуктов и поставщиков ПО и предлагать их в виде микросервисов, которые благодаря DevOps, облачным технологиям и API могут быть переосмыслены в виде любой бизнес-модели и структуры на ваш вкус.
Данную концепцию удивительно образно объяснил Адриан Кокрофт, бывший облачный архитектор компании Netflix. Он рассказал о переходе компании от DVD к потоковому вещанию и о том, каким масштабным изменениям пришлось подвергнуть всю технологическую структуру. Вот на чем он заостряет внимание:
• Теперь функции – это крупные компании.
• Сегодня не осталось соборов – только базары.
• Сегодня приложения – это инфраструктура.
• Ключевой аспект – проектирование, инициированное разработчиками.
• Монолитов больше не осталось, теперь все реализовано в виде микросервисов.
• Если в вашей организации принята каскадная модель разработки – это прискорбный факт.
• Когда разработчики сами отвечают за проектирование продукта, он получается гораздо более гибким и интересным[17].
Банки должны взять эти тезисы на заметку и учиться на них, ведь у многих из них, с кем я имею дело, система контроля выстроена по принципу «сверху вниз». Идея распределить контроль между разработчиками там будет воспринята как ересь. Но все-таки именно это нужно сделать.