Ratepay го обновува сопствениот основен систем

Давателот на услуги за плаќање ќе го замени својот наследен ИТ за помалку од 18 месеци. Ratepay ја затвори последната база на податоци од стариот свет пред неколку недели. практичен водич.

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

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

Луис Линден, CTO при отплата

Наследниот ИТ е како топче предиво. Секој што ќе повлече конец тешко може да предвиди што ќе се случи тогаш. Ваквите ситуации се јавуваат во ИТ кога програмерите програмираат близу до основната логика и со тоа го прават ИТ заплеткањето сè покомплексно. Отпрвин може да биде во ред, така што новите функции можат побрзо да одат на Интернет. Оние кои свесно се вклучуваат во овој технички долг, всушност можат да стекнат предности на краток рок, како што е побрзо промет на пазарот. Сепак, клучно е да се отплатат долговите откако тие ќе ги преземат. Инаку, постои ризик од ИТ кој е сè потежок за одржување, во кој се натрупуваат грешки и што одзема се повеќе време.

Ratepay не беше поштеден. Понудата е насочена првенствено на трговците на мало преку Интернет кои сакаат да им понудат на своите клиенти што повеќе начини на плаќање, вклучително и купување на сметка и на рати. Бидејќи ваквите барања понекогаш остануваат отворени, тие бараат партнери кои можат да ги ослободат од овој ризик и исто така да се справат со низводните процеси за нив. За да го направите ова, Ratepay треба да ги процени овие ризици во реално време, така што клиентите можат да ги завршат своите набавки без да чекаат. За таа цел, системот бара податоци од релевантните кредитни агенции, но исто така користи свои методи и машинско учење со цел да може брзо да се одлучи дали или не да се ризикува за различни групи на стоки како авионски билети, мебел или облека.

Сепак, внатрешно развиениот основен систем, кој порасна повеќе од една деценија и ги контролира низводните процеси, сè повеќе предизвикуваше потешкотии. Ова вклучува, на пример, каде логото на клиентот се појавува на фактурата и дали клиентите се прифатени или прифатени. Основниот систем исто така зема предвид различни структури на надоместоци, ги обработува податоците и ги проследува до поврзаните системи. Со текот на времето, сето тоа стана прилично збунувачко. Затоа системот треба да се замени. Во процесот на тендери, се покажа корисно примарно прецизно да се опише проблемот (видете ја рамката) наместо да се специфицира специфично решение од самиот почеток. Како резултат, проектниот тим беше во можност да процени неколку предлози истовремено и да биде сигурен во градењето на најсовремена архитектура.

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

Извор: Ratepay, Senacor

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

Самиот развој на основен систем првенствено значи избор на вистинска архитектура. Сепак, ова претпоставува дека разбирате кои технички барања треба да бидат мапирани. Проблем: За време на фазата на стартување, одделните програмски делови од првиот систем не беа целосно документирани. Затоа, проектниот тим мораше да прочита повеќе од 200.000 редови SQL-код со цел да ги реконструира функционалностите прикажани во тоа време и во исто време да ги раздели делумно испреплетените процеси. Ова резултираше во процес на модел кој може да се расчлене на технички цврсто капсулирани блокови со задачи и да се опише во одделни микросервиси.

Секој микросервис исполнува точно дефинирана задача. Тоа ги прави лесни за одржување и проширување. На пример, Платежниот API прифаќа нарачки во реално време од веб-страницата на дилерот и нарачува специјални микросервиси за собирање на пребарувања на Шуфа, пресметување на ризикот и одлучување дали на клиентот му е дозволено да плаќа за својата нарачка на сметка или на рати. Сето ова се случува за помалку од половина секунда. Веднаш штом трговецот на мало ќе ја испрати стоката, микро-услугите што се помалку критични за време започнуваат во т.н. низводно. Автобус за настани ги дистрибуира податоците помеѓу услугите на начин контролиран од настани (види графикон).

Сите услуги работат низводно што на малопродавачот повеќе не му требаат во реално време откако клиентот ќе ја нарача својата нарачка. Ова вклучува, на пример, пресметување на надоместоци и планови за рати, испраќање фактури и потсетници, правење објави во SAP и управување со управување со готовина. Портал за дилер се наоѓа исто така во областа низводно. Како последна наследност на наследниот систем, развивачите го исклучија монолитот на базата на податоци на почетокот на летото и поставија нов склад за податоци за известување.

Безбедно знаење и знаење

Асинхроната архитектура на новиот јадрен систем нуди многу предности. Индивидуалните услуги можат да се активираат една по друга. За време на проектот, ова овозможи миграција во помали чекори и го намали ризикот што често доаѓа со голема експлозија. Покрај тоа, системот може полесно да се прошири и прилагоди, затоа што треба да се допрат само услугите кои се директно засегнати и целата платформа да не застане ако нешто треба да се адаптира. За да останете независни, препорачливо е да се осигура дека потребното знаење и струја се влева во организацијата додека проектот сè уште работи (сопственост).

Работата на модуларен начин се вклопува и во агилните методи. Микросервисите дозволуваат големи задачи да се расчленат на мали со цел побрзо да се постигнат првите резултати. Таквите мали услуги, исто така, можат да се ставаат во функција од време на време, со цел да се набудува како системот се однесува како целина. Било какви грешки се забележуваат порано и тимот може полесно да учи од нив. Во развојот на софтвер, „брзо не успеваат“ е принцип што исто така може да им помогне на одделните тимови да излезат од крути структури. Монолитите честопати се наоѓаат не само во ИТ, туку и во организација - и таму ги попречуваат најдобрите идеи.

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

Опишете го проблемот, а не решението: кажете што ви паѓа на ум, а потоа проценете што потенцијалните даватели на услуги ви предлагаат.
Добијте ги вистинските хируршки инструменти: Објаснете пред тоа колку време, пари и какви вештини ќе ви требаат во тимот за да успее проектот.
„Кажи не по дифолт“: Држете се до дефинираниот опсег што е можно поблиску и не дозволувајте да ви наплаќаат премногу. Ова ги одложува проектите или дури им дозволува да пропаднат.
Направете свое сопствено знаење однадвор: составете го вашиот тим од внатрешни и надворешни експерти и осигурете се дека организацијата подоцна има суверенитет или сопственост над понатамошните случувања.
Избегнете ја „Големата експлозија“: Постепено мигрирање е полесно да се планира и многу полесно да се врати ако нешто тргне наопаку.

Луис Линден, CTO во Ratepay

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