A Ratepay megújítja saját alaprendszerét

A pénzforgalmi szolgáltató kevesebb, mint 18 hónap múlva lecseréli régi IT-jét. A Ratepay néhány hete leállította a régi világ utolsó adatbázisát. gyakorlati útmutató.

A Fintechek és a startupok olyan rugalmasságot élveznek, hogy mozgékony informatikájuk miatt különösen rugalmasak és megnehezítik a megalapított vállalatok életét. Az egyik ok: elavult informatika. A digitális támadók azonban nem mindig veszik észre, hogy állítólag modern informatikájuk maga is örökséggé válhat.

Hogyan jön létre az informatika

Luise Linden, a ratepay CTO-ja

A Legacy IT olyan, mint egy fonalgömb. Aki szálat húz, aligha tudja megjósolni, mi fog akkor történni. Ilyen helyzetek fordulnak elő az informatikában, amikor a fejlesztők az alapvető logikához közel programoznak, és ezáltal az informatikát egyre összetettebbé varázsolják. Eleinte rendben lehet, hogy az új funkciók gyorsabban csatlakozzanak az internethez. Azok, akik tudatosan bekapcsolódnak ebbe a technikai adósságba, rövid távon valóban előnyökre tehetnek szert, például gyorsabb piacra jutási időre. Mindazonáltal elengedhetetlen az adósságok törlesztése, miután azok felvállalták. Ellenkező esetben fennáll az egyre nehezebben fenntartható informatikai kockázat, amelyben a hibák felhalmozódnak, és amelyek egyre több időt vesznek igénybe.

A Ratepay-t nem kímélték. Az ajánlat elsősorban azokat az online kiskereskedőket célozza meg, akik a lehető legtöbb fizetési módot szeretnék felajánlani ügyfeleiknek, ideértve a számlán és részletekben történő vásárlást is. Mivel az ilyen igények néha nyitottak maradnak, olyan partnereket keresnek, akik mentesíthetik őket ebből a kockázatból, és kezelhetik számukra a downstream folyamatokat is. Ehhez a Ratepay-nek valós időben értékelnie kell ezeket a kockázatokat, hogy az ügyfelek várakozás nélkül teljesíthessék vásárlásaikat. Ebből a célból a rendszer lekérdezi az érintett hitelügynökségek adatait, de saját módszereit és gépi tanulását is alkalmazza annak érdekében, hogy gyorsan eldönthesse, vállal-e kockázatot az olyan áruk különböző csoportjaira, mint a repülőjegy, a bútor vagy a ruházat.

Azonban a belső fejlesztésű, egy évtized alatt megnövekedett központi rendszer, amely irányítja a downstream folyamatokat, egyre nagyobb nehézségeket okozott. Ide tartozik például, hogy hol jelenik meg az ügyfél logója a számlán, és elfogadják-e vagy használják-e az ügyfeleket. Az alaprendszer különféle díjstruktúrákat is figyelembe vesz, feldolgozza az adatokat és továbbítja azokat a csatlakoztatott rendszerekhez. Az idő múlásával minden elég zavaros lett. Ezért ki kell cserélni a rendszert. A pályáztatás során hasznosnak bizonyult a probléma elsődleges pontos leírása (lásd a keretet), ahelyett, hogy eleve konkrét megoldást adna meg. Ennek eredményeként a projektcsapat egyszerre több javaslatot is kiértékelhetett, és biztos lehetett a korszerű építészet felépítésében.

Az új Ratepay alaprendszer informatikai architektúrája

Forrás: Ratepay, Senacor

Építse fel az alaprendszert

Az alaprendszer saját fejlesztése elsősorban a megfelelő architektúra kiválasztását jelenti. Ez azonban feltételezi, hogy megérti, mely műszaki követelményeket kell feltérképezni. A probléma: Az indítási szakaszban az első rendszer egyes programrészei nem voltak teljesen dokumentálva. A projektcsapatnak ezért több mint 200 000 sor SQL-kódot kellett elolvasnia az akkor ábrázolt funkcionalitások rekonstrukciója és egyúttal a folyamatok szétválasztása érdekében, amelyek egy része összefonódott. Ennek eredményeként egy olyan folyamatmodell jött létre, amely funkcionálisan szorosan beágyazott feladatblokkokra osztható és leírható az egyes mikroszolgáltatásokban.

Minden mikroszolgáltatás pontosan meghatározott feladatot teljesít. Ez megkönnyíti a karbantartást és bővítést. Például a Payment API valós időben fogadja el a megrendeléseket egy kereskedő webhelyéről, és speciális mikrohelyzeteket bíz meg Schufa-lekérdezések összegyűjtésével, a kockázat kiszámításával és annak eldöntésével, hogy az ügyfél fizethet-e megrendeléséért számlán vagy részletekben. Mindez kevesebb, mint fél másodperc alatt megtörténik. Amint egy kiskereskedő elküldi az árut, a kevésbé időkritikus mikrohelyzetek elindulnak az úgynevezett downstream-ben. Egy eseménybusz eseményvezérelt módon osztja el az adatokat a szolgáltatások között (lásd a grafikát).

Minden olyan szolgáltatás lefut, amelyre a kiskereskedőnek már nincs szüksége valós időben, miután az ügyfél megrendelését leadta. Ide tartozik például a díjak és részletfizetési tervek kiszámítása, számlák és emlékeztetők küldése, könyvelés az SAP-ban és a készpénzkezelés kezelése. A forgalmazói portál a downstream területen is található. Az örökölt rendszer utolsó örökségeként a fejlesztők nyár elején kikapcsolták az adatbázis-monolitot, és új adattárházat állítottak fel jelentésre.

Biztonságos know-how

Az új alaprendszer aszinkron architektúrája számos előnyt kínál. Az egyes szolgáltatások egymás után aktiválhatók. A projekt során ez lehetővé tette a migrációt kisebb lépésekben és csökkentette a gyakran nagy durranással járó kockázatot. Ezenkívül a rendszer könnyebben bővíthető és adaptálható, mert csak a közvetlenül érintett szolgáltatásokat kell érinteni, és a teljes platform nem áll le, ha valamit adaptálni kell. A függetlenség megőrzése érdekében célszerű biztosítani, hogy a szükséges know-how beáramlik a szervezetbe, amíg a projekt még fut (tulajdonjog).

A moduláris munkavégzés illeszkedik az agilis módszerekhez is. A mikroszolgáltatások lehetővé teszik a nagy feladatok apróra bontását az első eredmények gyorsabb elérése érdekében. Az ilyen kicsi szolgáltatásokat időről időre be is lehet állítani annak figyelembevétele érdekében, hogy a rendszer hogyan viselkedik egészében. Az esetleges hibákat korábban észrevették, és a csapat könnyebben tanulhat tőlük. A szoftverfejlesztésben a „gyors kudarc” olyan elv, amely az egyes csapatoknak is segítséget nyújthat a merev struktúrákból való kitörésben. A monolitok gyakran nemcsak az informatikában, hanem a szervezésben is megtalálhatók - és ott akadályozzák a legjobb ötleteket.

Öt szabály a régi nyugdíjazásra

Írja le a problémát, és ne a megoldást: mondja el, mi jár a fejében, majd értékelje, mit javasolnak a potenciális szolgáltatók.
Szerezze be a megfelelő műtéti eszközöket: Tisztázza előre, mennyi időre, pénzre és milyen készségekre lesz szüksége a csapatban a projekt működéséhez.
„Alapértelmezésben mondjon nemet”: Tartsa be a lehető legszorosabban a meghatározott hatókört, és ne engedje, hogy túl sokat terheljen. Ez késlelteti a projekteket, vagy akár kudarcot is enged.
Tedd magadévá a külsőleg vásárolt know-how-t: állítsd össze a belső és külső szakértőkből álló csapatodat, és győződj meg arról, hogy a szervezet később rendelkezik-e szuverenitással vagy tulajdonjoggal a további fejlesztések felett.
Kerülje el a „nagy durranást”: A fokozatos migrációt könnyebb megtervezni, és sokkal könnyebb visszavonni, ha valami rosszul esik.

Luise Linden, a Ratepay vezérigazgatója

Volker Broer, a Senacor Technologies partnere