Создание компонуемых банковских операций

Когда я впервые начал свою карьеру в области банковских технологий в 80-х, я сначала работал с мейнфреймами.

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

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

В то же время нам разрешалось работать из дома или из любого места, где мы чувствовали, что можем быть продуктивными. Мой график обычно был таков: вставать в 6 утра и кодировать до 2:6, затем перерыв на обед и полдник. Я вернулся к своему рабочему столу примерно с 7/XNUMX вечера и обычно кодировал до полуночи. Это сработало для меня.

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

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

Однако, как правило, для конкретных бизнес-требований аналитик документирует их, а разработчик пишет код. Это была модель на протяжении десятилетий.

Были попытки изменить это, чтобы предоставить бизнес-пользователям возможность писать свои собственные решения, используя решения с низким кодом или без кода. Действительно, моя последняя компания, edgeIPK, была пионером в создании платформы без кода для разработки веб-приложений и мобильных приложений. Gartner называет пользователей таких инструментов «гражданскими разработчиками». Это сократило разделение требований и разработки, но осмелюсь сказать, что породило множество решений, которые было трудно поддерживать и которые мало способствовали повторному использованию. Следовательно, такие инструменты на самом деле не использовались на уровне предприятия для критически важных решений.

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

1. Архитектор предприятия (EA): кто-то, кто управляет общим решением на высоком уровне, обеспечивая максимальное повторное использование и согласованность. Архитектура BIAN — хороший пример того, что может создать советник. BIAN предлагает отличную модель для применения составных «строительных блоков» для полной банковской архитектуры.
2. Создатели: разработчики, которые создают и публикуют строительные блоки отдельных вычислений, функций или бизнес-возможностей.
3. Кураторы: роль для управления «библиотекой» или рынком строительных блоков. Эта библиотека также должна включать любые проприетарные или сторонние решения.
4. Составители: команды, которые составляют решение из стандартных блоков, используя платформы и инструменты для создания приложений, но не обязательно.
5. Потребители: фактические пользователи приложения.

Для получения дополнительной информации см. недавний вебинар Ефима «Основные принципы компонуемости: процветание за счет изменений в бизнесе».

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

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

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

Об авторе

Дхармеш Мистри работает в банковской сфере более 30 лет и находится в авангарде банковских технологий и инноваций. От самых первых интернет-приложений и мобильных банковских приложений до искусственного интеллекта (ИИ) и виртуальной реальности (ВР).

Он был по обе стороны забора, и он не боится делиться своим мнением.

Он генеральный директор Спросите, в котором основное внимание уделяется опыту для домашних хозяйств, а также инвестору и наставнику в сфере проптех и финтех.

Следите за Дхармешем в Твиттере @dharmeshmistry и LinkedIn.

Прочтите все его размышления «Я просто говорю» здесь.