Ratepay își reînnoiește propriul sistem de bază

Furnizorul de servicii de plată își va înlocui vechiul IT în mai puțin de 18 luni. Ratepay a închis ultima bază de date din lumea veche acum câteva săptămâni. un Ghid practic.

Fintech-urile și startup-urile se bucură de reputația de a fi deosebit de flexibile și de a face viața dificilă companiilor consacrate datorită IT-ului lor agil. Unul dintre motive: IT depășit. Dar atacatorii digitali nu observă întotdeauna că presupusul lor IT modern se poate transforma în moștenire.

Cum se creează vechiul IT

Luise Linden, CTO la ratepay

Moștenirea IT este ca o minge de fire. Oricine trage un fir cu greu poate prezice ce se va întâmpla atunci. Astfel de situații apar în IT atunci când dezvoltatorii programează aproape de logica de bază și, prin urmare, încurcă IT-ul din ce în ce mai complex. La început ar putea fi în regulă, astfel încât noile funcții să poată intra online mai repede. Cei care se implică în mod conștient în această datorie tehnică pot câștiga de fapt avantaje pe termen scurt, cum ar fi un timp mai rapid pe piață. Cu toate acestea, este crucial să achitați datoriile odată ce acestea și-au asumat. În caz contrar, există un risc de IT care este din ce în ce mai greu de întreținut, în care se acumulează erori și care ocupă din ce în ce mai mult timp.

Ratepay nu a fost cruțat. Oferta se adresează în principal comercianților cu amănuntul online care doresc să ofere clienților lor cât mai multe metode de plată posibil, inclusiv achiziționarea în cont și în rate. Deoarece astfel de cereri rămân uneori deschise, ei caută parteneri care îi pot scuti de acest risc și, de asemenea, se ocupă de procesele din aval pentru aceștia. Pentru a face acest lucru, Ratepay trebuie să evalueze aceste riscuri în timp real, astfel încât clienții să își poată finaliza achizițiile fără să aștepte. În acest scop, sistemul interogă date de la agențiile de credit relevante, dar folosește și propriile metode și învățare automată pentru a putea decide rapid dacă își asumă sau nu un risc pentru grupuri de mărfuri diferite, cum ar fi biletele de avion, mobilierul sau îmbrăcămintea.

Cu toate acestea, sistemul de bază dezvoltat intern, care a crescut peste un deceniu și controlează procesele din aval, a provocat dificultăți tot mai mari. Aceasta include, de exemplu, unde logo-ul clientului apare pe factură și dacă aceștia sunt acceptați sau utilizați. Sistemul de bază ia în considerare, de asemenea, diferite structuri tarifare, prelucrează datele și le transmite către sistemele conectate. În timp, totul a devenit destul de confuz. De aceea sistemul ar trebui înlocuit. În procesul de licitație, sa dovedit util să descriem problema în primul rând cu precizie (vezi caseta) în loc să specificăm de la început o soluție specifică. Ca rezultat, echipa de proiect a putut evalua mai multe sugestii în același timp și a fost sigur că va construi o arhitectură de ultimă generație.

Arhitectura IT a noului sistem de bază Ratepay

Sursa: Ratepay, Senacor

Construiți sistemul de bază

Dezvoltarea personală a unui sistem de bază înseamnă în primul rând alegerea arhitecturii potrivite. Cu toate acestea, acest lucru presupune că înțelegeți care sunt cerințele tehnice care trebuie mapate. Problema: în timpul fazei de pornire, părțile individuale ale programului din primul sistem nu au fost complet documentate. Prin urmare, echipa de proiect a trebuit să citească peste 200.000 de linii de cod SQL pentru a reconstrui funcționalitățile descrise în acel moment și, în același timp, pentru a dezlega procesele parțial întrețesute. Acest lucru a dus la un model de proces care ar putea fi împărțit în blocuri de sarcini tehnic bine încapsulate și descris în microservicii individuale.

Fiecare microserviciu îndeplinește o sarcină precis definită. Acest lucru le face ușor de întreținut și de extins. De exemplu, API-ul de plată acceptă comenzi în timp real de pe un site web al dealerului și comandă microservicii speciale pentru a colecta interogări Schufa, pentru a calcula riscul și pentru a decide dacă unui client i se permite să plătească comanda sa în cont sau în rate. Toate acestea se întâmplă în mai puțin de o jumătate de secundă. De îndată ce un comerciant cu amănuntul trimite mărfurile, microserviciile mai puțin critice în timp încep în așa-numitul aval. Un autobuz de evenimente distribuie datele între servicii într-un mod controlat de eveniment (vezi graficul).

Toate serviciile rulează în aval de care comerciantul cu amănuntul nu mai are nevoie în timp real după ce un client și-a plasat comanda. Aceasta include, de exemplu, calcularea comisioanelor și a planurilor de tranșă, trimiterea de facturi și memento-uri, efectuarea de înregistrări în SAP și gestionarea gestionării numerarului. Un portal de dealeri este, de asemenea, situat în zona din aval. Ca ultimă moștenire a sistemului vechi, dezvoltatorii au oprit monolitul bazei de date la începutul verii și au înființat un nou depozit de date pentru raportare.

Know-how sigur

Arhitectura asincronă a noului sistem de bază oferă multe avantaje. Serviciile individuale pot fi activate unul după altul. În timpul proiectului, acest lucru a permis migrarea în trepte mai mici și a redus riscul care vine adesea cu un big bang. În plus, sistemul poate fi extins și adaptat mai ușor, deoarece numai serviciile afectate direct trebuie atinse și întreaga platformă nu se oprește dacă trebuie adaptat ceva. Pentru a rămâne independent, este recomandabil să vă asigurați că cunoștințele necesare curg în organizație în timp ce proiectul este încă în desfășurare (proprietate).

Lucrul într-un mod modular se potrivește și cu metodele agile. Microserviciile permit împărțirea sarcinilor mari în cele mici, pentru a obține rezultate inițiale mai rapid. Astfel de servicii mici pot fi, de asemenea, puse în funcțiune între ele pentru a observa cum se comportă sistemul ca întreg. Orice greșeli sunt observate mai devreme și echipa poate învăța mai ușor de la ele. În dezvoltarea de software, „eșuarea rapidă” este un principiu care poate ajuta și echipele individuale să iasă din structuri rigide. Adesea monolitii nu se găsesc numai în IT, ci și în organizație - și acolo împiedică cele mai bune idei.

Cinci reguli pentru pensionarea moștenită

Descrieți problema și nu soluția: spuneți ce vă trece prin minte, apoi evaluați ce potențiali furnizori de servicii vă sugerează să faceți.
Obțineți instrumentele chirurgicale potrivite: clarificați în prealabil cât timp, bani și ce abilități veți avea nevoie în echipă pentru ca proiectul să funcționeze.
„Spuneți nu în mod implicit”: rămâneți la domeniul de aplicare definit cât mai aproape posibil și nu vă permiteți să fiți taxat prea mult. Aceasta întârzie proiectele sau chiar le lasă să eșueze.
Asigurați-vă propriul know-how achiziționat extern: puneți-vă împreună echipa de experți interni și externi și asigurați-vă că organizația are mai târziu suveranitate sau proprietate asupra dezvoltărilor ulterioare.
Evitați „Big Bang-ul”: migrația treptată este mai ușor de planificat și mult mai ușor de anulat dacă ceva nu merge bine.

Luise Linden, CTO la Ratepay

Volker Broer, partener la Senacor Technologies