Ratepay обновява собствената си основна система

Доставчикът на платежни услуги ще замени старата си информационна техника след по-малко от 18 месеца. Ratepay изключи последната база данни от стария свят преди няколко седмици. практически наръчник.

Fintechs и стартиращите компании се радват на репутацията на особено гъвкави и затрудняват живота на утвърдени компании поради тяхната гъвкава ИТ. Една от причините: остарели ИТ. Но цифровите нападатели не винаги забелязват, че техните уж модерни ИТ могат да се превърнат в наследство.

Как се създава наследствена ИТ

Луиз Линден, технически директор по тарифа

Legacy IT е като топка прежда. Всеки, който дърпа конец, трудно може да предскаже какво ще се случи тогава. Такива ситуации възникват в ИТ, когато разработчиците програмират близо до основната логика и по този начин правят ИТ заплитането все по-сложно. Отначало може да се оправи, така че новите функции да могат да се включат по-бързо онлайн. Тези, които съзнателно се включват в този технически дълг, всъщност могат да спечелят предимства в краткосрочен план, като например по-бързо време за пускане на пазара. Изключително важно е обаче да изплатите дълговете, след като те са поели. В противен случай съществува риск от ИТ, който е все по-труден за поддръжка, при който се натрупват грешки и който отнема все повече и повече време.

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

Вътрешно развитата основна система, която се е разраснала повече от десетилетие и контролира процесите надолу по веригата, все повече причинява трудности. Това включва например къде логото на клиента се появява на фактурата и дали клиентите са приети или приети. Основната система също взема предвид различни структури на таксите, обработва данни и ги препраща към свързаните системи. С течение на времето всичко стана доста объркващо. Ето защо системата трябва да бъде заменена. Когато се търгува, се оказа полезно да се опише основно проблемът (виж карето), вместо да се посочи конкретно решение от самото начало. В резултат на това екипът на проекта успя да оцени няколко предложения едновременно и да бъде сигурен в изграждането на модерна архитектура.

ИТ архитектура на новата основна система Ratepay

Източник: Ratepay, Senacor

Изградете основната система

Разработването на основна система сами означава преди всичко избор на правилната архитектура. Това обаче предполага, че разбирате кои технически изисквания трябва да бъдат картографирани. Проблемът: По време на фазата на стартиране отделните програмни части от първата система не бяха напълно документирани. Следователно екипът на проекта трябваше да прочете повече от 200 000 реда SQL код, за да реконструира функционалностите, изобразени по това време, и в същото време да раздели процесите, някои от които бяха преплетени. Това доведе до модел на процес, който може да бъде разделен на функционално плътно капсулирани блокове на задачи и описан в отделни микроуслуги.

Всяка микрослужба изпълнява точно определена задача. Това ги прави лесни за поддръжка и разширяване. Например API за плащане приема поръчки в реално време от уебсайта на дилъра и възлага специални микросервизи за събиране на заявки на Schufa, изчисляване на риска и решаване дали на клиента е позволено да плати поръчката си по сметка или на вноски. Всичко това се случва за по-малко от половин секунда. Веднага щом търговецът на дребно изпрати стоката, микросервизите с по-малко време, които са критични, започват в т. Нар. По веригата Шината за събития разпределя данните между услугите по контролиран от събития начин (вижте графиката).

Всички услуги се изпълняват надолу по веригата, от които търговецът на дребно вече не се нуждае в реално време, след като клиент направи поръчката си. Това включва например изчисляване на такси и планове за разсрочено плащане, изпращане на фактури и напомняния, извършване на осчетоводяване в SAP и обработка на управление на парични средства. Дилърски портал се намира и в долната част на веригата. Като последното наследство на наследената система, разработчиците изключиха монолита на базата данни в началото на лятото и създадоха ново хранилище за данни за отчитане.

Сигурно ноу-хау

Асинхронната архитектура на новата основна система предлага много предимства. Отделните услуги могат да бъдат активирани една след друга. По време на проекта това позволи миграция с по-малки стъпки и намали риска, който често идва с голям взрив. Освен това системата може да бъде разширена и адаптирана по-лесно, тъй като трябва да се докоснат само пряко засегнатите услуги и цялата платформа не спира, ако нещо трябва да се адаптира. За да останете независими, препоръчително е да се гарантира, че необходимото ноу-хау се влива в организацията, докато проектът все още работи (собственост).

Работата по модулен начин също се вписва в гъвкавите методи. Микроуслугите позволяват големите задачи да бъдат разделени на малки, за да се постигнат по-бързо първите резултати. Такива малки услуги също могат да бъдат пуснати в действие между тях, за да се наблюдава как системата се държи като цяло. Всички грешки се забелязват по-рано и екипът може да се учи по-лесно от тях. При разработването на софтуер „бързо се проваля“ е принцип, който също може да помогне на отделните екипи да излязат от твърдите структури. Монолитите често се срещат не само в ИТ, но и в организацията - и там пречат на най-добрите идеи.

Пет правила за наследствено пенсиониране

Опишете проблема, а не решението: кажете какво ви е на ум, след което оценете какво предлагат потенциалните доставчици на услуги.
Вземете правилните хирургически инструменти: Предварително изяснете колко време, пари и какви умения ще ви трябват в екипа, за да накарате проекта да работи.
„Кажи не по подразбиране“: Придържайте се към дефинирания обхват възможно най-близо и не позволявайте да бъдете таксувани твърде много. Това забавя проектите или дори ги оставя да се провалят.
Направете външно ноу-хау свое собствено: съберете екипа си от вътрешни и външни експерти и се уверете, че по-късно организацията има суверенитет или собственост върху по-нататъшното развитие.
Избягвайте „Големия взрив“: Мигрирането постепенно е по-лесно за планиране и много по-лесно за отмяна, ако нещо се обърка.

Луис Линден, технически директор в Ratepay

Volker Broer, партньор в Senacor Technologies