Ratepay оновлює власну базову систему

Постачальник платіжних послуг замінить застарілі ІТ менш ніж за 18 місяців. Ratepay закрив останню базу даних зі старого світу кілька тижнів тому. практичне керівництво.

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

Як створюється застаріла ІТ

Луїза Лінден, технічний директор зі ставки оплати

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

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

Однак внутрішньо розроблена основна система, яка зросла за десятиліття і контролює подальші процеси, все частіше викликала труднощі. Сюди входить, наприклад, де логотип клієнта відображається на рахунку-фактурі та чи приймаються або використовуються клієнти. Основна система також бере до уваги різні структури плати, обробляє дані та передає їх у підключені системи. З часом все це стало досить заплутаним. Ось чому систему слід замінити. У процесі тендеру виявилося корисним в першу чергу точно описати проблему (див. Рамку), замість того, щоб вказати конкретне рішення з самого початку. Як результат, команда проекту змогла одночасно оцінити кілька пропозицій та бути впевненою у побудові сучасної архітектури.

ІТ-архітектура нової базової системи Ratepay

Джерело: Ratepay, Senacor

Побудуйте основну систему

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

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

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

Безпечне ноу-хау

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

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

П’ять правил для застарілих пенсій

Опишіть проблему, а не її рішення: скажіть, що вам на думці, а потім оцініть, що пропонують вам зробити потенційні постачальники послуг.
Отримайте правильні хірургічні інструменти: заздалегідь чітко покажіть, скільки часу, грошей і яких навичок вам знадобиться в команді, щоб проект працював.
«Скажи ні за замовчуванням»: дотримуйтесь визначеного обсягу якомога ближче і не дозволяйте стягувати із вас занадто багато. Це затримує проекти або навіть дозволяє їм провалитися.
Зробіть ноу-хау, придбане зовні, власним: об’єднайте свою команду внутрішніх та зовнішніх експертів і переконайтеся, що пізніше організація матиме суверенітет або право власності на подальший розвиток.
Уникайте “Великого вибуху”: міграцію поступово легше спланувати і набагато простіше скасувати, якщо щось піде не так.

Луїза Лінден, технічний директор компанії Ratepay

Фолкер Броер, партнер Senacor Technologies