Для банков эта проблема фундаментальна: они отягощены старыми технологиями. Я уже много сказал о проблеме устаревших систем и о том, как их заменить. Однако здесь расскажу, как для замены старых систем может пригодиться криогенная заморозка.
Для этого нужно шаг за шагом преобразовать функции и процессы в приложение, API или инструменты аналитики, а затем вывести их на рынок как совершенно новую технологию. В конце концов, это можно будет проделать со всеми банковскими операциями, и банк целиком окажется на открытом рынке, избавившись по пути от старых технологий. В крупной компании такая стратегия растянется на много лет, потребует лидера и стратегического видения, но ее можно реализовать. Однако когда банк приступит к таким изменениям, перед ним встанут две проблемы.
Первая связана с планированием таких преобразований, ведь у банка есть и другие неотложные дела. Например, банк практически ежедневно сталкивается с изменениями в нормативной базе и новыми требованиями, вынуждающими в первую очередь обновить старые системы. Обновления в ответ на требования регулятора съедают весь бюджет, даже если речь идет о доработке всего нескольких строк кода, ведь этот крошечный фрагмент кода может повлиять на мириады других строк. Поскольку все это требуется проверить и перепроверить, прежде чем запускать в работу, подобные обновления получаются очень ресурсозатратными и обходятся в миллионы. Вот почему банкам не хватает бюджета на инновации – большая часть средств тратится на старые системы, и, как говорят многие исполнительные директора, приходится просто следить за тем, «чтобы свет не гас».
Допустим, банк смог перестроиться и выбраться из этого хаоса, взял курс на открытый банкинг, основанный на работе с приложениями, API и аналитикой, – в чем тогда проблема? Ну слон из комнаты никуда не делся. Новая структура организации основывается на переходе от монолитных макросистем к автономным микросистемам. Однако банкам не нравятся автономные микросистемы. Они привержены тотальному контролю и не приемлют ничего иного. Банки привыкли работать медленно, чтобы все было под контролем и отвечало требованиям регулятора. Таким образом, переход к микросервисной архитектуре, которого требуют современные гибкие, дешевые, быстрые и простые технологии, сложен как раз для такой организации, чья культура пропитана контролем и следованием правилам.
Рассуждая об этом, я обычно говорю, что в микросервисной организации есть команды разработчиков размером не более двух пицц. То есть такую команду можно накормить, заказав на обед две пиццы. Если команде требуется три пиццы, значит, она слишком велика. Вся суть в маленьких и гибких адаптивных командах, умеющих быстро вносить изменения.
Итак, вообразим, что банк сформировал организацию-разработчика, применяющую микросервисную архитектуру. Каждая из команд трудится над своим фрагментом кода. Каждая команда может быстро изменить его и встроить обратно в общую архитектуру. Поскольку ни одна из команд не отвечает за весь код, никому не приходится под ним подписываться. Вот в чем загвоздка. Разве может банк отказаться от тотального контроля и позволить ордам умников заниматься им одним понятными вещами?
Если же сможет, то сможет и позволить себе ежедневный перезапуск. Однако я сомневаюсь, что многим это удастся. Так, мне довелось побеседовать об инновациях с топ-менеджером банка, и он мне объяснил, что такое «уловка-22» по-банковски. Вы хотите быть инноватором, только если это не сопряжено с рисками. Но риск – неотъемлемая часть инноваций. Можете играть в песочнице, как малые дети, но, если попытаетесь из нее выбраться, вас одернут и затащат обратно. Тут ваше место – тут и оставайтесь.
Я отмечал, что любые инновации, взятые из песочницы [47] Специально созданная среда для безопасного запуска непроверенного кода из неизвестных источников.
, невероятно сложно приживаются, поскольку банковская культура заточена на уничтожение антител, привносимых в нее инноваторами-пожирателями. Вот почему возглавлять внедрение инноваций в любой финансовой компании – адова работа, которая непременно приведет вас в финтех-стартап или в центр занятости.
Банкир поразмыслил над этим, а потом выдал кое-что действительно интересное. Он заметил, что банки не любят проигрывать. Да, нам это известно, но сам феномен целиком связан с культурой работы по правилам. Проигрыш чреват проблемами и предупреждениями со стороны регулятора. Банки любой ценой стремятся избежать таких предупреждений, вот почему проигрыш для них не вариант. Я предположил, что микросервисные архитектуры на открытых рынках API дают им право на такой провал, поскольку в этом случае им не грозят репрессии, на что он ответил:
Читать дальше