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

Причем эти разработчики писали как проприетарный софт, так и отрытый (Open Source). Но и те, кто ратовали за превращение самих банков в софтверные компании (Inner Source), оказались на обочине. Всему этому, по мнению экспертов Gartner, поставит точку концепция Low-Code. В банке никто возражать не стал.

Но и этого оказалось мало революционерам. Вместе с Agile с пьедестала смещаются микросервисная IT-архитектура, а также часть облачных технологий, на которые отечественные банкиры так и не успели толком мигрировать. Все это замещает Capabilities Economy. А это значит, что концепция Open API как основа пресловутой API Economy тоже отходит в сторону под давлением экосистем и непубличных (Private) API.

Временем практической кристаллизации всех этих идей (как минимум в «Сбере») стала пандемия, когда бизнес «припер к стенке» IT и потребовал он них и гибкости, и бизнес-эффективности. А стартом этих перемен, по нашему мнению, стали форум FINOPOLIS 2019 и фраза Германа Грефа, главы «Сбера», сказанная им в ходе пленарной дискуссии «Регуляторный fast track для финтеха», модератором которой выступила Эльвира Набиуллина, председатель Банка России.

Напомним, Герман Греф тогда заметил: «Немецкий экономист Фридрих Лист ввел термин “страны, отбрасывающие лестницы”: когда некоторые страны добираются до вершины экономического развития, они стараются “отбросить лестницу”, чтобы обеспечить себе максимальное конкурентное преимущество. В финтехе надо стараться быть впереди и делать то же самое».

Тогда это вызвало недопонимание. Но к началу 2021 года дымовая завеса, похоже, начинает рассеиваться. Пока кое-кто уходил «в облака», в «API Economy» кто-то надолго обеспечивал себе конкурентное преимущество за счет новейших IT-архитектур. О них подробнее рассказал представитель Gartner, но об этом позже.

Похоже, кто-то что-то пропустил

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

Владимир Долгов, управляющий директор «Сбера»

По данным спикера, если рассматривать все пространство API, существующее в мире, то в нем можно заметить интересную тенденцию. До 2018 года количество Open API увеличивалось с каждым годом. Затем тенденция стала смещаться в сторону открытия внутренних и партнерских API. С 2018 года число открытых API по отношению к непубличным снизилась примерно на 25%, и сейчас их доля составляет не более 16% общего рынка API! Это немыслимое падение, которое осталось до сих пор недооцененным.

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

Еще один вывод по итогам 2020 года: API — «это теперь не только кодирование или программирование». 

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

Что за зверь Capabilities Economy?

Максим Григорьев, исполнительный партнер Gartner, в докладе «Технологические тренды: API и будущее композитной архитектуры» объяснил, что именно находится сейчас «под капотом» перемен.

По мнению докладчика, API и все, что связано с ними, — это мощный трансформирующий тренд. Собственные исследования Gartner показывают, что к концу 2021 года в мировом масштабе 98% всех организаций в том или ином виде будут использовать API. При этом уже сейчас в 70% бизнесов API внедрены. 

С точки зрения зрелости технологий только 7% организаций — новички в области API, 5% можно назвать экспертами, а остальные 88% находятся на промежуточной стадии зрелости.

Что касается типов, то 88% — это внутренние API, 68% — частные проприетарные, 52% используют API от внешних поставщиков. И это то, куда до сих пор двигался этот мир: в сторону публичных (открытых, публикуемых) API. Их сейчас в мире используют 46% компаний, которые массово учатся на них зарабатывать.

Лидеры по предоставлению API — Google (34%), Salesforce (28%), Microsoft (15%) и Amazon Web Services (AWS) с долей 14%.

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

Что касается приложений,  они должны быть компонуемыми (Composable, по принципу конструктора Lego), демократизируемыми (Democratized, функциональность должны обеспечивать в меньшей степени разработчики) и интеллектуальными (Intelligent, операционализация в приложении ИИ).

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

По вертикальной оси вверх отложен тренд бизнес-ориентированного подхода (Business-Led), а вниз — тренд, основанный на преимущественном влиянии на архитектуру подразделений IT (IT-Led). Влево уходит ось, ориентированная на уровень повышенной стабильности (Stability) ведения бизнеса, а вправо — на уровень гибкости (Agility).

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

Далее наступили времена, символом которых стали методики гибкого программирования — Agile. Маятник качнулся в правую нижнюю сторону диаграммы, и для обеспечения гибкости стали использовать технологии API. Однако сегодня осуществить прямую монетизацию API и выйти хотя бы на самоокупаемость удалось мало кому в мире, что оставило эту технологию исключительно технологическим инструментом.

Понятно, что бизнесу этот печальный факт пришелся не по душе, и стрелка линии тренда оказалась в правом верхнем углу, в квадранте Capabilities Economy (композитная экономика, или экономика, построенная на законченных компонентах, имеющих явный бизнес-эффект).

Параллельно со всем сказанным выше непрерывно происходят процессы декомпозиции монолитных приложений (АБС, например) на компоненты, обогащаемые сервисами, которые поставляют третьи стороны. Это видно на рисунке ниже. 

В 1990-х годах, как уже отмечалось, многое делалось при помощи корпоративных сервисных шин, в 2010-х маятник качнулся в сторону микросервисов и Mesh-приложений. Казалось, он здесь останется навечно, и разработчики от IT ринулись «пилить» монолиты, не думая о том, что гибкость системы в целом утрачивается прямо пропорционально количеству «напиленных» микросервисов. Пандемия стала одной из причин того, что маятник ушел в центр, в зону композитных приложений. Основной строительный блок здесь — функционально законченное бизнес-приложение (Packaged Business Capabilities, PBC).

Что отличает подход PBC от микросервисного? Принципиально здесь то, что добавляется еще один инструмент (API) для компоновки нескольких PBC в законченное приложение. Иными словами, создав множество автономных инкапсулированных программных пакетов, можно использовать их как строительные блоки для создания пользовательских приложений. 

Каждый PBC имеет законченный функционал, например управление счетом, выставление заказов и т.д. Изначально они писались вендорами, затем собственными командами разработки в банках, а в перспективе будут создаваться демократизированным способом конечными пользователями этих решений (Low-Code), оставляя IT, по сути, не удел.

API-first

Основой этого подхода является наличие API, выступающих своеобразным «клеем» и инструментом компоновки приложений. Понятно, что архитектурным ядром становится композитная платформа, благодаря которой маркетплейсы API множества PBC и других Legacy-приложений и сервисов интегрируются с целевым каналом взаимодействия с клиентом (web, mobile, социальные сети, чат-боты и т.д.), формируя у последнего необходимый клиентский опыт в омниканальной среде (CX).

Так, существует два вектора развития платформенных архитектур. Пока это классическая платформа PaaS, включающая в себя различные компоненты, в том числе платформу управления API. Также набирающий все большую силу тренд — создание универсальных платформ, организуемых вокруг Low-Code ядра (SaaS-Accelerated All-In-One Low-Code Platform). Принципиально тут то, что функционал управления API должен быть доступен для непрофессиональных разработчиков. 

По оценкам Gartner, к 2024 году четыре из пяти лидирующих Low-Code Platform будут иметь в своем составе полный набор функциональности, включая API-интеграцию, элементы ИИ и управления внешними событиями.

Из-за экосистемной природы «Сбера» последний вариант, по мнению Gartner, предпочтителен ввиду легкого добавления нужного функционала.

Побочный эффект Low-Code Platform — классические SaaS-провайдеры отказываются от собственного интерфейса и предлагают его через API. К 2025 году 60% всех SaaS-решений будут работать исключительно через API, облегчая встраивание их сервисов в композитную архитектуру банков.

Что это дает? То, чего хочет бизнес: получать прибыль путем увеличения уровня монетизации Open и Private API. В реальной жизни финансистов это выглядит как бурный рост экосистем, активное становление банкинга как сервиса (BaaS) и взаимопроникновение банков и корпораций, например, на уровне казначейств. 

От теории к практике

Александр Камчатнов, архитектор Sber Registry, в выступлении «SberAPI Registry — энейблер экосистемы “Сбера”» «перевел» слова аналитика Gartner на язык, более понятный финансисту, и рассказал о том, что банк успел сделать на практике в контексте того, о чем говорили в Gartner.

Создан SberAPI Registry — объединяющий элемент экосистемы, b2b-платформа для публикации и подключения к API цифровых сервисов участников экосистемы. Его отличают: 

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

Сейчас продукт состоит из одноименного SberAPI Registry (шлюз и реестр Open API экосистемы), портала разработчика SBER Developer (точка входа разработчика экосистемы) и «СберAPI» (шлюз и реестр Open API Сбербанка, т.е. внутренняя система банка, позволяющая публиковать свои API вовне и подключать партнеров).

Чего же удалось достичь «Сберу» в продуктовом плане в 2020 году?

• Запущена в полном объеме новая Open API платформа, полностью построенная на Open Source. При этом значительные изменения коснулись не только технологий, но и бизнес-процессов. Иными словами, был пройден путь от вендорного интеграционного решения к «демократизации», чтобы разработчики продуктовых команд могли сами публиковать на Sber API Registry свои продукты. С точки зрения процессов идет «обвязка» Inner Source инструментарием для разработчиков, т.е. все движется в полном согласии с мнением аналитиков Gartner.
• Ключевые API были переведены на новую платформу. в планах на 2021 год — полностью отказаться от старой вендорской интеграционной платформы.
• Стартовало привлечение новых клиентов — участников экосистемы и дочерних банков.

 Sber API Registry вошел в 2021 год с 60+ опубликованными API, 110+ активными приложениями, а также с производительностью в 130+ транзакций в секунду, что в пять раз больше, чем в 2019 году. За этими транзакциями стоят реальные бизнес-истории, позволяющие запускать новые продукты за счет интеграции банка и его партнеров. Пока данной пропускной способности достаточно, но тренд на монетизацию API приведет со временем к существенному росту этого показателя.

Изменения бизнес-процессов в платформе привели к разделению клиентов, которые хотят опубликовать API, на четыре группы. Начинает этот ряд группа Light, допускающая упрощенную интеграцию участников и формирование их актуального каталога. Это все нужно для ускоренного роста экосистемы за счет упрощения интеграции. Во второй группе находятся те, кому нужны безопасность и отказоустойчивость, обеспечиваемые промышленной API-платформой. Для специфических участников, требующих сертификацию, например, по PCI DSS, предусмотрена инсталляция по принципу on-premise. В эту группу входят дочерние банки «Сбера», процессинг и т.д. Четвертая группа — «энейблеры» (Enablers) — имеетприоритет и обеспечивает предоставление наиболее критичных сервисов экосистемы, а также формирует стандарты и принципы для будущего развития.

Если перейти от стратегических направлений к тактическим достижениям, то применительно к Sber API Registry выделяется ряд запусков реальных API от конкретных поставщиков сервисов: Sberbank ID, «Плати QR», SberPrime, «Аккредитивы и эскроу», а также Account Linking (связка учетных записей Sberbank ID и поставщика контента для SberBox и SberPortal).

В ближайшем будущем от «Сбера» можно ждать:

• Community — развития портала developers.sber.ru как точки входа разработчиков экосистемы;
• Self-service — развития инструментария экосистемных и банковских разработчиков;
• API Management — сервисов API Gateway /API Management для участников экосистемы;
• Integration — расширения поддержки транспортных протоколов и шаблонов интеграции;
• On premise — тиражирования решения в дочерние банки;
• Economy — развития функционала учета использования и монетизации API, заключения договоров между участниками.

Теория и практика соединились. По крайней мере, в рамках одного крупного банка. Но IT-архитектура и API — не все компоненты решения. В нем переплелись судьбы проприетарного ПО, Open Source и Inner Source. Эти узлы в ходе конференции развязывали представители таких вендоров, как Microsoft, Huawei, Oracle, SAP и компании LeroyMerlin. Но это уже другая история.