Забезпечення роботи складної банківської системи

Коли я вперше почав свою кар’єру в банківських технологіях у 80-х, я спочатку працював з мейнфреймами.

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

Кілька років потому банк хотів випробувати те, що сьогодні було б названо agile, але тоді це була швидка розробка додатків. Мета полягала в тому, щоб прискорити впровадження наших рішень. Ми першими в ІТ озброїлися ноутбуками і навіть мобільними телефонами. Нас вивели з ІТ-офісу і дали кабінет в одному з підрозділів.

У той же час нам дозволялося працювати вдома або там, де ми відчували, що можемо бути продуктивними. Мій розклад був зазвичай прокидатися о 6 ранку і кодувати до 2:6, потім перерву, щоб пообідати та післяобідню порцію. Я повернувся за свій стіл приблизно о 7:XNUMX і зазвичай кодував до півночі. Це спрацювало для мене.

Окрім цього, найбільшою зміною стало отримання вимог від кінцевих користувачів у філіях. Це значно змінило зручність використання та правильні функції рішення.

Перемотайте 30 років вперед і зараз це норма. За останні 30 років ми спостерігаємо зростання інтеграції бізнес-користувачів та ІТ. Навіть постачальники програмного забезпечення перейшли до моделі, за якою клієнти глибоко залучені до нових продуктів.

Однак, як правило, для конкретних бізнес-вимог аналітик їх документує, а розробник пише код. Це була модель протягом десятиліть.

Були спроби змінити це, щоб надати бізнес-користувачам можливість писати власні рішення, використовуючи рішення з низьким кодом або без нього. Дійсно, моя остання компанія, edgeIPK, була піонером у створенні платформи без коду для розробки веб-/мобільних додатків. Gartner називає користувачів таких інструментів «громадянами-розробниками». Це зменшило поділ вимог і розробки, але я смію сказати, що це створило багато рішень, які було важко підтримувати, і сприяло мало повторного використання. Отже, такі інструменти насправді не використовувалися на рівні підприємства для критично важливих рішень.

Однак це може змінитися з компонованим банкінгом, де акцент робиться на розробці, публікації та споживанні будівельних блоків з ринку, а потім дозволі комусь іншому «компонувати» ці блоки в повне рішення. Але очевидно, що це не так просто. Єфім Натіс, видатний віце-президент-аналітик і науковий співробітник Gartner, визначає наступні п’ять ролей у складовій банківській системі:

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

Додаткову інформацію дивіться на нещодавньому вебінарі Єфіма «Основні принципи компонування: процвітайте завдяки змінам у бізнесі».

Я просто кажу, що «складний банкінг» — це не лише проблема ІТ, оскільки вона стосується бізнес-користувачів. Це не просто стандартна розробка з бібліотекою повторного використання, це організаційна зміна, і фірмам буде важко побачити всі переваги без цієї зміни.

У минулому роль архітектора підприємства була надзвичайно важкою, оскільки вона вимагала глибоких знань бізнесу та технологій, щоб мати можливість просіяти сотні, якщо не тисячі систем, і створити план для кращого ландшафту. BIAN значно спростив це, хоча завдання відображення існуючих систем все ще не таке просте.

Як я підкреслив у попередні дописи, комбінована банківська справа може вирішити низку проблем для банків, але це вимагатиме організаційних змін і має підтримуватися стратегією навчання та прийняття нового способу роботи, що підтримується новими ролями. Як завжди, інструменти та теорія доступні, диявол криється в деталях. Є переконливі приклади організацій, які вміють це працювати, і я сподіваюся, що незабаром напишу про них.

Про автора

Дхармеш Містрі працює в банківській справі більше 30 років і перебуває в авангарді банківських технологій та інновацій. Від найперших програм для Інтернету та мобільного банкінгу до штучного інтелекту (AI) і віртуальної реальності (VR).

Він був по обидва боки паркану, і він не боїться поділитися своєю думкою.

Він є генеральним директором Запитай Homey, який зосереджується на досвіді для домогосподарств, а також інвестор і наставник у proptech і fintech.

Слідкуйте за Дхармешом у Twitter @dharmeshmistry та  LinkedIn.

Прочитайте всі його міркування «я просто кажу». тут.