Ako sme pre SKP nahrádzame 20-ročný core systém

Dvadsať rokov zmien v jednom systéme

SKP beží na legacy systéme, ktorý za sebou má zhruba dvadsať rokov vývoja, úprav, dopĺňania pravidiel a prirodzeného technologického dlhu.

Systém stále plní svoju úlohu, no čoraz viac naráža na limity. Pri každej zmene je náročné zistiť, čo všetko sa jej dotkne. To je pri regulovanej doméne zásadný problém, pretože zmena legislatívy alebo procesu nemôže byť postavená na odhadoch.

Skutočnou výzvou preto nebolo napísať nový kód. Bolo ňou navrhnúť komplexnú doménu nanovo na základe požiadaviek ktoré reflektujú súčasné potreby poisťovní a SKP, a pritom nestratiť know-how uložené v starom systéme, nezastaviť prevádzku a nenechať v audite sivé miesta. V praxi to znamenalo päť konkrétnych úloh, ktoré popisujú nasledujúce kapitoly.

Systém, ktorý sa nedá vypnúť

SKP si nemôže dovoliť prestávku v systéme. Nejde o aplikáciu, ktorá sa dá vypnúť, prepísať a po pár mesiacoch spustiť znova. Vymáhanie pohľadávok beží priebežne, splátkové kalendáre sa tiahnu mesiace až roky a upomienky nepočkajú, kým bude hotové nové riešenie.

Preto sme od začiatku riešili aj to, ako bude nový systém bezpečne koexistovať s existujúcim prostredím. Prechod pripravujeme po moduloch. Dáta do nového systému spätne prelievame po jednotlivých moduloch a integrácie riešime po funkčných oblastiach aplikácie. Samotné prepnutie na ostrú prevádzku prebehne naraz pri release.

Pravidlá, ktoré neboli nikde zapísané

Jedným z najväčších rizík bola roztrúsená znalosť pôvodného systému. Niektoré pravidlá boli zapísané, iné žili v praxi a ďalšie sa dali pochopiť až pri detailnom skúmaní konkrétnych scenárov.

Najviditeľnejšie sa to prejavilo pri integráciách. Nový systém sa musí napájať na synchrónne aj asynchrónne rozhrania, ktoré vznikali pred viac než pätnástimi rokmi a ich správanie nebolo nikde zdokumentované. Špecifikáciu týchto rozhraní sme skladali spätne, kombináciou reverse engineeringu a overovania správania na konkrétnych scenároch.

Paralelne sme si cez workshopy s klientom vytvárali obraz celej domény. Nestačilo prejsť existujúce obrazovky a spísať zoznam funkcií. Potrebovali sme pochopiť, čo sa deje pri zmene regulácie, kde vzniká pohľadávka, ako sa pracuje s rolami a oprávneniami, ktoré kroky musia byť auditovateľné a kde sú najväčšie riziká pre prevádzku. Výsledkom bola spoločná mapa domény, vďaka ktorej sa dalo rozhodovať, čo ide do prvého rozsahu, čo počká a čo treba navrhnúť úplne nanovo.

Špecifikáciu sme po schválení neodložili. Priebežne ju aktualizujeme, aby vždy zodpovedala tomu, ako systém reálne funguje. Každá podstatná funkcionalita má popísané pravidlá, scenáre, väzby a očakávané správanie. Keď príde zmena regulácie, tím nemusí hľadať odpoveď v pamäti jednotlivcov. Pozrie sa do špecifikácie a zistí, ktorých procesov, obrazoviek, dát a integrácií sa zmena dotkne.

Počítali sme pritom s tým, že ani dôkladná analýza neodhalí všetko vopred. Časť biznis logiky sa ukázala až vo chvíli, keď stáli základy systému a pracovalo sa s reálnymi scenármi.

Prepísanie by problém nevyriešil

Mohli sme starý systém prepísať do novšej technológie. To by však neriešilo podstatu problému. Preto sme sa spolu s klientom vydali náročnejšou cestou: redizajn regulovanej domény na zelenej lúke.

K starému systému sme pristupovali ako k zdroju poznania, nie ako k plánu stavby. Boli v ňom zachytené roky výnimiek, pravidiel, rozhodnutí a praktických potrieb. Zároveň však niesol technologické a procesné obmedzenia, ktoré sme nechceli preniesť ďalej. Tam, kde dával odpoveď na otázku „prečo sa to robí takto“, bol pre nás cenný. Tam, kde iba odrážal historické obmedzenia, sme hľadali lepší spôsob.

Rovnaký prístup sme uplatnili pri rozhraní. Používatelia v ňom trávia celé dni, preto sme kládli dôraz na konzistentnosť a jednoduchú orientáciu: jednotný dizajnový systém naprieč všetkými modulmi, tabuľky s filtrami tam, kde referenti pracujú s veľkým množstvom záznamov, a osobná agenda, ktorá každému používateľovi ukazuje jeho úlohy, priority a termíny na jednom mieste.

Každá akcia musí mať stopu

V regulovanej doméne nestačí vedieť, že sa niečo stalo. Treba vedieť kto, kedy, čo a v akom kontexte urobil. Pri vymáhaní pohľadávok to platí dvojnásobne. Každá upomienka, úhrada či zmena splátkového kalendára musí mať jasnú a dohľadateľnú stopu, ktorá je spätne vysvetliteľná pre interný tím, právne oddelenie aj prípadný audit.

Všetky kľúčové udalosti sa preto zbiehajú v centrálnom logu. Každý záznam nesie informáciu o tom, kto akciu vykonal, kedy a v akom kontexte, či už ide o zmenu stavu pohľadávky, úpravu limitov alebo export dát. Log sa dá filtrovať a exportovať, takže podklady pre interný tím, právne oddelenie aj audit sa dajú pripraviť jednoducho, bez asistencie vývojárov. Samotný prístup k logu je pritom riadený oprávneniami a vyhradený pre manažérske a administrátorské roly.

Súčasťou systému je aj správa delegovaných agend. Keď referent zastupuje kolegu, systém eviduje, kto konal za koho a v akom období. To pomáha nielen pri audite, ale aj pri každodennej prevádzke a riešení nejasností.

Ako sme z veľkého celku spravili dodateľný plán

Pri rozsiahlom enterprise systéme sa na začiatku všetko javí ako rovnako dôležité. S takýmto zadaním sa však nedá plánovať dodávka.

Rozdelili sme ho preto s klientom na oblasti, ktoré sa dali analyzovať, navrhnúť a vyvíjať samostatne, a dohodli sme sa, čo musí obsahovať prvá vlna. Podmienka bola, aby bola použiteľná hneď po nasadení, nie až po doplnení zvyšku.

Zmenilo to aj spôsob, akým klient o projekte uvažuje. Kým na začiatku patrilo do prvej fázy všetko, po niekoľkých kolách už sám určoval, ktoré funkcie idú hneď a ktoré počkajú.

Samotná dodávka pritom nešla klasickým vodopádom. Analýza, dizajn a development bežali v úzkom závese, miestami paralelne. Prinieslo to viac zmenových požiadaviek, než by vznikalo pri rigidnom pláne, no bola to vedomá voľba: nové zistenia sa dali zapracovať hneď, keď vznikli, a nie o fázu neskôr, keď by ich zapracovanie bolo násobne drahšie.

Java, Spring Boot a integračné kontrakty

Nový systém je postavený na Java a Spring Boot, s REST/OpenAPI rozhraniami, jasne definovanými integračnými kontraktmi, premysleným modelom rolí a oprávnení a s QA procesmi a testovaním od začiatku vývoja.

Podstatné je, že systém zostáva zrozumiteľný, dá sa ďalej rozvíjať a vzniká ako udržateľný kód, do ktorého sa oplatí dlhodobo investovať. SKP potrebuje istotu, že o pár rokov nebude riešiť rovnaký problém len v modernejšom balení.

Čo SKP získava

SKP získava systém, ktorý je novým základom pre ďalší rozvoj a začiatok modernizácie celej spoločnosti. Vymáhanie pohľadávok, finančná správa záväzkov, splátkové kalendáre, upomienkovanie, evidencia a vytváranie komunikácie aj úschova dokumentácie dostávajú jedno prehľadné miesto namiesto roztrúsených procesov.

Súčasťou systému je aj osobná agenda každého referenta. Úlohy ako odoslanie výzvy na zaplatenie, príprava žaloby či kontrola platby majú priradeného vlastníka, termín a prioritu, takže tím vidí nielen stav pohľadávok, ale aj stav vlastnej práce.

Spolu so systémom vznikla živá špecifikácia kľúčových procesov, auditná stopa pri citlivých akciách a zrozumiteľný plán, čo patrí do prvej vlny a čo bude nasledovať ďalej.

MVP bolo doručené v dohodnutom termíne a projekt pokračuje smerom k plnému nasadeniu. Nový systém rešpektuje, ako SKP funguje dnes, a zároveň jej dáva priestor meniť procesy a reagovať na reguláciu bez toho, aby sa pri každej zmene muselo nanovo zisťovať, čoho všetkého sa dotkne.

Čo nás projekt naučil

Najväčšie legacy projekty často nebrzdí stará technológia, ale nejasnosť: ako procesy fungujú, kto čo vlastní, čo sa stane pri zmene pravidiel a kde sa nachádza pravda o systéme.

Pri SKP sa potvrdilo, že dobrá modernizácia začína schopnosťou pochopiť doménu, pomenovať pravidlá a urobiť z komplexity niečo, s čím sa dá pracovať. Až potom má zmysel písať nový kód.