Як банк модернізував застарілі ІТ-системи та мігрував у "хмару"

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

Фінансовий сектор — колись лідер у використанні інформаційних технологій — ще до COVID-19 почав сповільнюватися у розвитку, хіба за незначними винятками. А коли почалася пандемія, ситуація для декого виявилася критичною. З’ясувалося, що навіть IT-фахівці банків, не кажучи про інших працівників цих установ, не можуть працювати віддалено. Питання про переведення організацій на дистанційний формат роботи доводилося вирішувати в авральному режимі. У багатьох випадках процеси в банках були орієнтовані на обслуговування клієнтів у відділеннях, а не дистанційно. І це при тому, що ІТ-технології мають достатньо рішень, щоб «бути онлайн».

Хмарні платформи , які зараз бурхливо розвиваються, мають значний потенціал. Нині можна швидше започаткувати нову fintech-компанію, ніж перевести банк, страхову або велику роздрібну компанію, особливо з довгою історією, на нові технології. Також змінюється корпоративна культура, і роками відшліфовані стандарти відходять у минуле й актуальними стають культура та методи роботи, що виросли на Open Source-проєктах.

Ця стаття буде цікавою працівникам IT-підрозділів банків, страхових і роздрібних компаній, які думають про модернізацію своїх IT-систем та їхню міграцію у хмару. Оскільки не всі дані можна мігрувати, то в статті основний акцент — на побудові гібридної хмари (приватної та публічної) за технологіями компанії IBM. Описані інструменти створено на open source продуктах і їх можна використовувати як локально, так і в інших публічних і приватних хмарах.

Чому трансформація — це важливо

За світовою статистикою , 3–4 роки тому тільки 10% компаній використовували хмари, нині ж ця цифра доходить до 90%. Водночас тільки 20% обчислювальних ресурсів перенесені у хмару.

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

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

Спілкуючись з колегами, котрі представляють українські банки та великі роздрібні компанії, я виділив основні причини, що гальмують процес трансформації. Тому вирішив поділитися надбаними знаннями з модернізації ландшафту IT-системи одного банку.

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

Соціально-бізнесові передумови

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

Для досягнення успіху компанії формують чітку та обґрунтовану стратегію модернізації та крок за кроком рухаються нею. Водночас важливо бути готовими до трансформації на всіх рівнях управління та виконання. Впевнений рух уперед має мотивувати співробітників опановувати нові способи роботи та вчитися мислити по-новому. Працівникам, особливо бізнес-підрозділів та підрозділів інформаційної безпеки, необхідно прийняти нову реальність і будувати та аналізувати процеси відповідно до нових інструментів та способів роботи. Занадто швидка трансформація не спрацює, бо спеціалісти будуть просто перевантаженими. Але вона не має бути занадто повільною, бо люди втрачатимуть інтерес.

Тож нетехнічні передумови, що вимагають трансформації IT-систем, можна викласти у такому переліку:

клієнти не бажають відвідувати відділення банків;
нові бізнеси все частіше ґрунтуються на цифрових технологіях;
бізнес прагне бути гнучким і швидко адаптуватися під вимоги часу;
соціальні мережі увійшли в наше життя, і компанії намагаються знайти нові канали для просування своїх послуг клієнтам;
COVID-19 — новий фактор, який змушує пришвидшити трансформацію.

Перелік спеціально не впорядкований, оскільки кожна компанія і пов’язана з нею IT-система має свої цілі та свою історію розвитку. Залежно від цього організації матимуть свій порядок.

Технічні передумови

Сучасним інформаційним технологіям давно стало тісно у своїх центрах обробки даних. При цьому банки й великі роздрібні мережі вже накопичили великі бази даних, і ці дані потрібно використовувати, змінювати, модифікувати та збагачувати разом із впровадженням нових систем. Але першочерговим чинником для вибору інструментів і платформ є бізнес-виклики, які стоять перед кожною компанією, що використовує певну IT-систему. Тому технічні передумови можна описати через відому піраміду потреб Маслоу.

В основі лежить невідповідність IT-інфраструктури сучасним бізнес-викликам. Вже неодноразово йшлося про «тісноту» та перевантаженість сучасних ЦОД. Для класичного банку з історією характерним є ландшафт, в основі якого є монолітна або модульна автоматизована банківська система (АБС) від великих компаній- вендорів. А інколи й не одна.

АБС вирішує завдання бухгалтерського обліку, нарахування відсотків, розрахунку тарифів, налаштування продуктів. Має інтерфейси із системами електронних платежів, додаткові модулі для роботи з платіжними системами, кредитними бюро, фінансовим моніторингом тощо.

Переважно автоматизовані банківські системи мають інтерфейс користувача для співробітників, які працюють з клієнтами або виконують бек-офісні операції.

Основне завдання банківської системи — виконувати фінансові транзакції. Але свого часу в гонитві за універсальністю в неї напакували багато непрофільної функціональності. Вона слугує основним джерелом даних для корпоративних сховищ, CRM, звітності. І тому є безліч інтеграцій з усім, що банк надбав.

Це призводить до проблем з продуктивністю, складнощів тестування, високої вартості підтримки та довгого терміну внесення змін. Варто згадати й CRM-системи, які існують в банках. Зазвичай це ті самі моноліти.

Усе це може стати серйозним бар’єром на шляху до цифрової трансформації.

У пошуках рішення

Рішення лежить на поверхні, але його не так просто реалізувати. Якщо не стоїть питання про перехід на кардинально нову систему чи архітектуру, то потрібно позбавити АБС непрофільних функцій і даних. А потім, коли буде можливість і потреба, рознести на слабопов’язані модулі та модернізувати інтеграційний інструментарій. На противагу важким локальним CRM-системам уже існує багато хмарних систем або систем, що розгортаються у власній інфраструктурі й потім легко можуть видалятися з IT-ландшафту.

Інтеграційний рівень. Деякий час було очевидним трендом створення централізованої шини даних, що мала зв’язати всі компоненти ІТ-ландшафту банку. Але, як правило, повної реалізації не відбувалося і цілей досягали частково. Переважно це пов’язано з вартістю та комплексністю такого підходу. Потрібно було доробляти майже всі системи (як з боку вендорів, так і системи власної розробки).

Регулярні інвестиції. Крім того, схожі комплекси потребують постійного вкладання ресурсів в оновлення та здійснення ліцензійних платежів. І це все нівелює переваги впровадження єдиної шини.

На противагу цьому нині широко використовують мікросервісний підхід. Він передбачає велику кількість слабопов’язаних програм, в кожній із яких реалізовані свої бізнес-функції. Програми запускаються у власній інфраструктурі, взаємодіють через API. Кожна з них може бути змінена, протестована, розгорнута або масштабована з допомогою CI/CD та спеціалізованого середовища з управління мікросервісами.

Ще потрібно згадати про низьку якість клієнтських даних у системах, особливо які мають давню історію.

Неякісні дані є одним з основних гальмівних факторів у впровадженні технології smart data. Це коли спершу отримуємо дані з трансакційних, облікових систем та DWH, а потім застосовуємо інструменти машинного навчання. Таким чином отримуємо таку собі павутину взаємопов’язаних факторів і суперечностей, які потрібно якось проаналізувати та вибрати дані.

Складність і багатовекторність вибору

IT стоїть перед складним вибором:

Інвестувати у старе, щоб не завалити бізнес?
Здійснити революцію та купити «коробку», яка «розв’яже усі проблеми»? Але такої коробки не існує. Знов-таки це вимагатиме часу, бюджету, спеціалістів, яких на ринку обмаль або вони дорого коштують...
Мобілізуватися й переписати програмний код повністю під нову платформу?

Чи не краще піти шляхом модернізації? Але тут теж можуть виникнути різні проблеми:

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

З одного боку, ради директорів тиснуть на IT-підрозділи щодо цифрової трансформації. А з іншого — численні проблеми заважають IT-підрозділам втілити її.

Приклад аналізу традиційного шляху модернізації IT-ландшафту компанії, а також питання, що виникають за результатами аналізу

Світові тренди говорять уже не просто про модернізацію шляхом міграції у хмару. Нині широко використовуються гібридні хмари, і деякі корпорації присутні одночасно в кількох хмарах, а також мають свої приватні. Тобто традиційний ландшафт інформаційних систем розбивається на кілька хмарних компонентів, а їхні складові можуть мігрувати з одного компонента до іншого, коли є така потреба. Адже всі застосунки відповідають принципам Cloud-native applications.

Часто розпочатий процес міграції не збігається з бізнес-цілями компанії. В такому разі він приречений на провал. Що робити? IT-директор повинен надати чітку стратегію трансформації. Її потрібно скоригувати так, щоб вона збігалася з бізнес-цілями компанії. І вже з готовим баченням спілкуватися із внутрішнім замовником. Основна мета — ідентифікувати найбільш зацікавлених клієнтів у цифровій трансформації та зрозуміти, які функції їм потрібні уже сьогодні.

Зазвичай під час модернізації IT-систем з глибокою історією не працює корпоративна методика «водоспаду». Не варто багато уваги приділяти історії розвитку окремо взятого програмного забезпечення, більш продуктивним буде думати про актуальні потреби. Власники бізнес-процесів уже давно змінилися по кілька разів, і вже немає у кого питати, чому був обраний той чи інший підхід.

Щоразу я переконуюся, що у співпраці з бізнес-замовниками краще віддавати перевагу сучасним підходам, які мотивують команди думати нестандартно та генерувати ідеї. Наша команда використовує комбінацію методів Design Thinking та IBM Garage for Cloud.

Додам, що важливо не глобалізувати задачі, особливо на початкових етапах, коли в командах замовників і виконавців поки немає достатнього досвіду, спрацьованості та впевненості у власних можливостях. І потрібно дотримуватися моделі MVP (моделі продукту мінімальної вартості).

Модернізація на прикладах

У цьому розділі опишу кроки модернізації IT-інфраструктури інформаційних систем банку.

Вибір стратегії модернізації

На малюнку нижче показано перший крок модернізації — «Побудова фундаменту». Після спілкування із замовником (банком) обрали такий підхід, коли IT-система послідовно, крок за кроком отримувала нові сучасні функції, не ламаючи наявних. І поступово застарілі функції відмирали, а нові стали здобувати своїх прихильників, тому що вже відповідали сучасним викликам і були реалізовані на сучасному технологічному рівні.

Очевидно, що маємо класичну «важку» автоматизовану банківську систему з усіма згаданими недоліками. Також маємо інтеграційну шину, що допомагає будувати сучасні інтеграції.

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

Приватна хмара побудована на базі Enterprise Kubernetes — платформа OpenShift.
Публічна хмара побудована на базі сервісів IBM Public Cloud.

Одна з переваг OpenShift у тому, що вона присутня у більшості основних хмарних провайдерів, у тому числі OpenShift може бути розгорнутий на локальній інфрастуктурі. Можна переносити свої застосунки (і навіть DevOps) з хмари у хмару — процес не зміниться.

А з IBM Cloud Paks для OpenShift ви можете швидко розширити його функціональність. Наприклад, з IBM Cloud Pak for Multicloud Management навіть у локальному ЦОД є можливість резервувати інфраструктуру, починаючи з підйому VM.

А з IBM Cloud Pak for Applications ви отримуєте вже готову інфраструктуру для розробки нових і модернізації наявних застосунків, DevOps-інструменти та моніторинг.

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

Додатково в банку вже побудована інфраструктура гібридної хмари, яка в майбутньому дасть змогу винести в публічну хмару фронтальні компоненти. На цьому етапі почалося перенесення у приватну хмару невеликих і некритичних застосунків і фахівці здобували досвід їхньої експлуатації. Викликати сервіси банку з публічної хмари вже давно не є проблемою.

У публічній і приватній хмарах DevOps-процеси побудовані, і команди набираються досвіду управління ними та вже оптимізують процеси.

Другим кроком є «Широка трансформація», коли ми змінюємо бекенд-застосунки та розширюємо присутність клієнта в соціальних мережах. Більше починаємо використовувати сервіси IBM Public Cloud.

На малюнку нижче показано, як «сателіт 1» переробляється на мікросервісну архітектуру. Нові програми розробляються тільки на базі OpenShift.

Замовник є активним у соцмережах. Також обговорюється присутність банку у Viber, Telegram та інших платформах. Спектр банківських сервісів, з якими Watson Assistant інтегрований, почав швидко збільшуватися. Виникла потреби аналізу логів його роботи, щоб зрозуміти якість роботи чат-бота та аналізувати тренди. Тут починаємо застосовувати Watson Studio (Big Data з коробки) в комбінації з Jupyter Notebook або RStudio та IBM Cloud Object Storage.

До речі, є сенс розглянути Watson Studio уважніше, оскільки його можна використовувати департаментам ризиків для аналізу ризикових даних, моделювання клієнтів або прогнозування. Платформа передбачає можливість колективної роботи, має широкий спектр інтеграційних інструментів для отримання даних з локальними базами даних. До того ж ви можете використовувати її тільки тоді, коли вам потрібно. Для прикладу: розрахунки здійснювали двічі на місяць, після чого інструмент вимикали, звільнивши ресурси.

Ви можете виставити ваш фінансовий чи інформаційний API через продукт API Gateway для публічного використання та отримувати з цього прибуток. Термін API economy є трендовим у світі.

IBM Cloud Functions — продукт з дуже широкими можливостями: від побудови мобільного back-end до виконання рутинних операцій за розкладом, як-от:

трансформація логів роботи чат-бота у щось більш прийнятне та їхній запис у базу даних;
отримання курсу НБУ або оновлення довідників НБУ тощо.

Тут два процеси (інвестиції та запуск нових каналів продажу, що допомагають отримувати бізнес-цінність) відбуваються паралельно.

Міграція сателіта на мікросервіси на початкових етапах передбачає більші інвестиції, адже потрібно розробити багато програмної інфраструктури та компонентів. А от розширення сервісів чат-бота — це нові канали спілкування з клієнтами та аналітика щодо них. API-економіка — це нові канали продажу банківських сервісів чи послуг.

Крок «Нова реальність» ще в майбутньому, але основна його мета — максимально трансформувати програмну архітектуру так, щоб у локальному ЦОД залишити мінімум, в ідеалі тільки АБС, та звільнити її від надлишкових функцій. Всі інші сателіти потрібно конвертувати до мікросервісної архітектури.

А паралельно, мабуть, варто задуматися щодо присутності в кількох хмарах.

Побудова DevOps-процесів

Перш ніж почати активну розробку, потрібно побудувати процеси розробки з підтримкою DevOps. На малюнку показані:

Git-сумісний репозиторій програмного коду;
Docker — сумісний репозиторій (зовнішній відносно OpenShift);
SonarQube, який використовують для контролю якості коду, він відшукує закладки у вигляді паролів та API-Keys;
Jenkins уже присутній в OpenShift, тому його використовуємо як основний CI/CD-інструмент;
Storage, підключений до OpenShift.

Але з урахуванням того, що інфраструктура типова для Cloud Native app, побудовано єдиний процес для всіх вендорів, яких запрошуватиме банк. Тобто тепер такі питання, як «нам для розгортання потрібно три сервери Red Hat для кожного середовища», вже не мають виникати. Якщо прикладна система не відповідає сучасним вимогам, то, можливо, немає сенсу на неї витрачатися (звісно, окрім випадків, пов’язаних із регуляторними політиками, де вибору немає).

Приклад окремих рішень

На малюнку нижче зображена розгорнута гібридна архітектура чат-бота, інтегрованого з Telegram. З публічної мережі Telegram користувач потрапляє в мережу IBM Public Cloud і на інтеграційне рішення, створене на базі відомої бібліотеки Node-Red для інтеграції з Watson Assistant.

У процесі спілкування Watson Assistant статичну інформацію вибирає з IBM Cloud Object Storage або пропонує клієнту перейти на відповідну сторінку корпоративного сайту. Звернення до сервісів АБС відбувається через IBM Cloud Functions. Для захисту каналу між IBM Public Cloud і точкою виклику сервісів використовують IBM Secure Gateway. За ним стоїть API Gateway, де прописані правила маршрутизації запитів до АБС або сервісів інших провайдерів.

Для внутрішнього користувача побудований Web UI чат-бот на Vue.js та Node.js як back-end. Node.js використовує Watson SDK для спілкування з Watson Assistant, а Web UI більше сфокусований на презентації даних.

Усі компоненти, що містяться в банку, задеплоєні в OpenShift.

Label 1. Публічна мережа, через яку клієнти під’єднуються до чат-бота через соціальну мережу Telegram або мобільний застосунок

Label 2. Мережа IBM Public Cloud. В центрі розташовані Watson Assistant та інтеграційні компоненти

Label 3. Мережа між IBM Public Cloud і локальною мережею клієнта. Захист трафіку здійснюється за допомогою IBM Secure Gateway

Label 4. Приватна мережа клієнта on-premises

Label 5. Інтеграційна шина IBM Integration Bus

Label 6. Компоненти банківської системи та сервіси інших провайдерів

Label 7. Back-end та front-end корпоративного чат-бота, що звертається до Watson Assistant у Public Cloud

Замість висновку

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

Щоби не пропустити нові статті Павла Щербухи — підписуйтеся на нього у телеграм-боті Стрічки DOU .

Опубліковано: 22/12/20 @ 01:00
Розділ Різне

SEO Блог