Чому мейнфрейми все ще важливі в цифрову еру банкінгу – Інтерв’ю з Дженніфер Нельсон

Дженніфер Нельсон — CEO компанії izzi Software.

Відкрийте для себе найкращі фінтех-новини та події!

Підпишіться на розсилку FinTech Weekly

Читають керівники в JP Morgan, Coinbase, Blackrock, Klarna та багатьох інших

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

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

Та попри їхню критично важливу роль мейнфрейми часто неправильно розуміють. У сьогоднішніх умовах, коли “cloud-first” є типовим гаслом, може здаватися нелогічним захищати старі технології. Але називати мейнфрейм “legacy system” — це надто спрощує набагато складнішу правду. Щоб зрозуміти чому, потрібно розглянути баланс між спадковими (heritage) системами та сучасним поштовхом до гібридної інфраструктури.

Аргументи на користь модернізації з обережністю

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

Але модернізація — це не просто технічний проєкт. Це стратегічне рішення, яке несе ризики, якщо його виконувати поспіхом. Дані, які безпечно зберігалися всередині мейнфрейм-середовища роками, стають уразливими з моменту, коли їх переносять в інше місце. Додатки, оптимізовані під мейнфрейм, можуть “збитися” під час міграції, спричиняючи дорогі проблеми із затримками (latency). Ці ризики — не теоретичні: вони загрожують щоденним операціям, дотриманню регуляторних вимог і навіть довірі споживачів.

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

Розрив у навичках із реальними наслідками

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

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

Безпека все ще залежить від людей

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

Розробники, які не повністю розуміють наслідки підвищених привілеїв (elevated permissions), можуть залишати “відчинені двері” — не через злий намір, а через неповне навчання чи зручність. Компанії, які не оновлюють доступ, коли співробітники змінюють ролі, можуть без потреби створювати ризик для конфіденційних даних. Навіть із витонченою технологією базові принципи гігієни безпеки залишаються критично важливими — і надто часто їх ігнорують.

Представляємо Дженніфер Нельсон

Щоб у контексті розглянути ці виклики й можливості, ми звернулися до Дженніфер Нельсон — CEO Izzi Software. Нельсон побудувала кар’єру навколо мейнфрейм-систем: 15 років у Rocket Software і п’ять років у BMC, перш ніж розширити свій погляд через старші інженерні ролі поза IBM Z ecosystem. У 2024 році вона заснувала Izzi Software — компанію, присвячену придбанню та розвитку бізнесів, збудованих на платформах IBM Z і IBM Power.

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

Приємного перегляду інтерв’ю!

1. Коли фінтех прагне “cloud-native для всього”, ви стверджували, що мейнфрейм залишається критично важливим для стабільності глобального банкінгу. Що, на вашу думку, найбільше помиляють більшість інноваторів у ролі застарілих систем сьогодні?

Перша помилка — називати мейнфрейм legacy system; ніби, раз його запустили більш ніж 60 років тому, він автоматично застарів. Це все одно, що назвати операційну систему Windows legacy-платформою. Це просто не відповідає реальності. Мейнфрейми сьогодні актуальніші, ніж на момент, коли їх уперше винайшли.

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

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

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

Люди думають, що хмара змінила правила гри, і що мейнфрейми в порівнянні вже застарілі. Концепція хмарних обчислень у межах мережі справді є сучасною та для багатьох змінює правила гри. Але якщо ви знайомі з технологією мейнфреймів, то користувачі помітять: у неї є багато тих самих характеристик, що й у хмари. Наприклад, коли ви входите в мейнфрейм, ви заходите в TSO — скорочення від “time sharing option” (варіант розподілу часу). У вас є власна сесія TSO або Microsoft Teams ‘instance’.

Ви всі використовуєте ті самі процесори на мейнфреймі. Але коли ви не запускаєте програму чи batch job, місткість надається тим, кому вона потрібна. Ви також заходите в LPAR, або logical partition, повністю з виділеним сховищем, безпекою й конфіденційністю. Користувачі в одному LPAR не можуть отримати доступ до даних в іншому LPAR, якщо це не налаштовано спеціально. Саме такою є хмара по суті: спільний доступ до ресурсів, коли ви їх не використовуєте, і захист даних, виділених під ваш інстанс. Але мейнфрейм використовує ці підходи роками.

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

З багатьох факторів ризику я можу звести їх до двох.

Перший ризик — споживання даних. Дані на мейнфреймі — це одні з найзахищеніших даних у світі. Коли ви знімаєте їх із мейнфрейму або робите видимими для когось, хто їх приймає (ingesting), виникає ризик для приватності даних і регуляторних вимог. Хто їх переглядає? Куди вони рухаються, коли залишають мейнфрейм?

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

3. Ви піднімали тривогу щодо розриву в навичках у мейнфрейм-експертизі. Наскільки серйозний інституційний ризик, коли менше інженерів знають, як керувати й захищати системи, від яких і далі залежать фінансові установи?

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

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

4. Розмови про безпеку часто зосереджуються на інструментах, але ви зазначили, що фронтлайн усе ще за людьми. Які операційні “сліпі зони” ви найчастіше бачили під час керування мейнфрейм-середовищами?

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

Є також певні базові найкращі практики безпеки, які варто застосовувати в будь-якій IT-мережі. Коли ви надаєте спеціальну авторизацію людині в певній ролі, вам потрібен чіткий процес, щоб прибрати цю авторизацію, коли вона змінює роль, щоб гарантувати видалення доступу. Часто це не проблема, якщо людина або ще є співробітником компанії, або не є поганим актором (bad actor). Але завжди є ризик, якщо лишити надто багато чутливих даних доступними для людей, які більше не потребують цього.

Крім того, набори даних (data sets) системного рівня мейнфреймів дозволяють користувачам виконувати фундаментальні дії в системі. Ви хочете, щоб до цих функцій мали доступ лише певні користувачі. Наприклад, певні елементи контролю безпеки можна вмикати або вимикати лише на глибших рівнях операційної системи. Ви були б здивовані, як часто компанії лишають базові принципи безпеки без перевірки. Існують способи для інженерів виконувати свою роботу без доступу до цих ресурсів на root-рівні, але з цим рівнем доступу працювати простіше, тож компанії лишають “чорний хід” відкритим більше, ніж їм слід.

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

5. Атаки ransomware орієнтовані не лише на кінцеві точки, а й на базову інфраструктуру. Що робить legacy system як категорію одночасно унікально вразливою — і, в деяких випадках, більш стійкою — ніж нові платформи?

Мейнфрейми мають вбудовані рівні безпеки, яких більшості серверів просто бракує. Сам факт того, що ви можете зайти в мейнфрейм, не означає, що тепер у вас є доступ до бізнес-критичних даних — а саме їх ransomware зазвичай блокує. Далі вам потрібно знати, де саме знаходяться дані, і як отримати до них доступ. І потім ці дані можуть бути розділені на сегменти (compartmented), тож зловмисник має доступ лише до частини даних, а не до всього, що йому потрібно для успішної атаки ransomware. А якщо у вас немає доступу до пристрою зберігання (storage device), ви не зможете бачити дані на цьому пристрої.

6. З вашого досвіду, як саме виглядає ефективна модернізація для фінансових установ, які не можуть дозволити собі “rip and replace”, але мають бути підготовлені до майбутнього?

Модернізація означає різне для різних компаній — залежно від того, де саме вони знаходяться щодо додатків, які працюють. Незалежно від того, B2B чи B2C, компанії модернізуються постійно: оновлюють сервери та ноутбуки.

Те саме відбувається й із бізнес-критичними додатками. Бізнес може періодично оновлювати ці додатки, але оскільки традиційні мейнфрейм-додатки були розроблені кількома поколіннями тому, найкраще, що компанії можуть зробити, — повністю оцінити, що робить кожен додаток “від початку до кінця” (end-to-end). Так вони зможуть поетапно впроваджувати свою модернізацію керованими частинами.

Компанії можуть розділити (compartmentalize) додаток на частини, щоб різні можливості та функції оновлювалися й переписувалися поступово з часом — у міру того, як це для них доступно за коштами. Якщо розглядати модернізацію як безперервний процес, бажання покращувати й ітерувати (iterate) стає постійним.

Лідерам завжди потрібне проактивне мислення. Питання мають бути такими: “Що ми можемо зробити вже зараз? Що ми можемо локалізувати цього року? Що ми можемо локалізувати впродовж наступних двох років?” Це краще, ніж підхід “як переписати все це цілком”.

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

Rip-and-replace — один із варіантів. Це звучить “жорстко й безапеляційно”, але по суті це означає лише припинити використовувати одну систему, щоб перейти на іншу. Проте керівництву потрібно мати “витримку” для великої зміни за один раз і затвердити бюджет. Правда в тому, що це радше “replace”, бо процедура може тривати роками.

7. Для техлідерів, які приходять із ментальністю cloud-first, що б ви сказали про найважливіший зсув у мисленні під час взаємодії з mission-critical мейнфрейм-системами?

Вивчіть, що мейнфрейм насправді робить. Hippocratic Oath говорить спершу “не нашкодь”, тож дізнайтеся, за що саме відповідає мейнфрейм, щоб не допустити шкідливих помилок. Коли ті, хто мислить у підході cloud-first, розумітимуть повну картину того, які транзакції надходять у мейнфрейм, характер цих транзакцій і наскільки дохід їхньої компанії залежить від цих транзакцій, вони зможуть збагнути й знати, як уникати пошкодження продуктивності та прибутковості своєї компанії.

Про Дженніфер Нельсон

Дженніфер Нельсон провела більшу частину своєї кар’єри в мейнфрейм-сфері, зокрема 15 років у Rocket Software і п’ять років у BMC. У 2019 році вона перейшла на старші інженерні ролі в глобальних технологічних компаніях поза екосистемою Z Systems, розширивши свій погляд і набір навичок. На початку 2024 року Нельсон почала закладати фундамент для того, що згодом стало Izzi Software — компанії, зосередженої на придбанні та розвитку софтверних бізнесів, збудованих на платформах IBM Z та IBM Power.