Načrt modernizacije pripravljen, proračun načelno potrjen. Izvajalec zastavi prvo vprašanje: »Kje je dokumentacija sistema?«. Izkaže se, da obstaja wiki, nazadnje posodobljen pred petimi leti, nekaj shem »nekje na omrežnem disku« in koda, ki je sama sebi dokumentacija. Ocena zraste za tretjino. Ker izvajalec ne ocenjuje dela, temveč negotovost.
To besedilo opisuje prakso, ki to negotovost umakne z mize: preden se kdorkoli dotakne kode stare aplikacije, se obnovi znanje o njej. Še nedavno je takšna faza pomenila tedne dela analitika in le malokdo se je odločil zanjo. Danes AI večino te analize opravi v delovnih dneh. In to spremeni vrstni red celotnega projekta.
Najprej zemljevid, potem koda
Modernizacija sistema brez aktualne dokumentacije spominja na prenovo stavbe brez načrta napeljav. Da se, a vsako klesanje stene je loterija: morda za njo ni ničesar, morda pa cev, od katere je odvisno pol nadstropja. V aplikacijah je ta cev pogosto integracija s skladiščem podatkov, ki jo je poznal samo avtor kode, ali nočni izvoz, ki ga potihem uporablja računovodstvo.
Zato je razumen vrstni red obraten od intuitivnega. Ne začne se s pisanjem nove kode niti z oceno stroškov. Začne se z zemljevidom.
Kaj AI izvleče iz kode, baze in dnevnikov
Sodobna orodja za analizo znajo prebrati tri vire resnice o sistemu: izvorno kodo, strukturo baze podatkov in dnevnike produkcijskega delovanja. Iz njihovega križanja nastane zemljevid sistema, ki zajema štiri plasti.
Prva so moduli: iz česa je sistem sestavljen in za kaj vsak del odgovarja, opisano v jeziku, razumljivem tudi ljudem zunaj IT. Druga so tokovi podatkov: od kod podatki vstopajo, kaj se z njimi dogaja spotoma, kje pristanejo. Tretja so integracije, torej vsa mesta, kjer se aplikacija pogovarja z drugimi sistemi: računovodstvom, skladiščem, trgovino, partnerji. Prav te ob spremembah najpogosteje počijo.
Četrta plast je najmanj očitna: mrtva koda. Analiza dnevnikov pokaže, katere funkcije že leta niso bile klicane in v katere tabele nihče ne piše od leta 2019. V starejših sistemih je takšen balast pogosto precejšen del celote. Vsaka vrstica, ki je ni treba prenesti, je realen prihranek v projektu.
Kaj zemljevid spremeni pri odločitvi »prepisati ali modernizirati«
O sami odločitvi smo pisali posebej, v besedilu o štirih kriterijih: odločitveni okvir. Zemljevid sistema tem kriterijem da trde podatke. Brez njega se tehnološki dolg ocenjuje po občutku, tveganje pa na podlagi anekdot. Z njim se črno na belem vidi: kateri moduli nosijo poslovno vrednost, kateri so mrtvi, kje sedijo integracije, ki povečujejo tveganje vsake spremembe.
Rezultati so lahko presenetljivi v obe smeri. Včasih se sistem, ki ga je »treba prepisati od začetka«, izkaže za tri četrtine zdravega in je dovolj zamenjati dva modula. Včasih obratno: aplikacija je videti nedolžno, zemljevid pa razkrije ducat nedokumentiranih povezav, zaradi katerih je delna modernizacija dražja od prepisa. V obeh primerih odločitev pade na podatkih, ne na čustvih. Izvajalec, ki dobi zemljevid namesto uganke, pa oceni delo namesto tveganja.
Po našem mnenju bi morala biti obnova zemljevida ločena, prva faza modernizacijske pogodbe, z lastnim prevzemom. Tudi če se po tej fazi odločite, da bo modernizacijo izvedel kdo drug ali je sploh ne boste izvedli, dokumentacija ostane v podjetju in dela naprej.
Kako preveriti, kar je ustvarila AI
Samodejno ustvarjena dokumentacija ni orakelj. Treba jo je preveriti. Najučinkovitejša metoda je preprosta: pregled z osebo, ki sistem pozna najbolje, pogosto edino takšno v podjetju. Razlika glede na klasični pristop je v vlogi te osebe. Ne prosite je, naj znanje zapiše, česar nihče ne mara in kar se vleče mesece. Prosite jo za recenzijo pripravljenega opisa, in kazanje »tu se ujema, tu ne« gre večkrat hitreje kot pisanje od začetka.
Dobra praksa je iti skozi nekaj najpomembnejših procesov od začetka do konca: naročilo, račun, reklamacija. Če zemljevid pravilno opisuje kritične tokove in naključno preverjene podrobnosti, mu je mogoče zaupati tudi na preostalih področjih. To se da narediti v enem dnevu.
Česa AI ne bo obnovila
Tu poštena opomba: koda pove, kaj sistem počne, ne pove pa, čemu. Nenavadna izjema pri obračunu popusta je lahko napaka, lahko pa trgovski dogovor iz leta 2016, ki še vedno velja za eno veliko stranko. Tega nobena analiza kode ne bo razrešila. Poslovne namene izpred desetletja se obnavlja z intervjuji: kratkimi pogovori z ljudmi iz prodaje, računovodstva in operative, opravljenimi že z zemljevidom v roki. Zemljevid namigne, kaj vprašati, odgovore pa ima človek.
Posebna tema je tudi okolje aplikacije: strežniki, omrežje, varnostne kopije. O dokumentiranju te plasti smo pisali v besedilu o reviziji dokumentacije infrastrukture.
V ESKOM AI fazo kartiranja vodimo z ekipo specializiranih agentov AI pod nadzorom izkušenih inženirjev: analiza tipičnega poslovnega sistema traja delovne dni, rezultat pa je dokumentacija, berljiva za upravo in tehnično ekipo. Če po njej pade odločitev o modernizaciji, nadaljnja dela potekajo v avtomatiziranem procesu razvoja programske opreme s polnim naborom testov — enotnih, integracijskih, E2E, UI, varnostnih in zmogljivostnih.
Kje začeti pri sebi
Izberite en sistem: tistega, katerega modernizacijo odlagate najdlje, ali tistega, ki se ga najbolj bojite dotakniti. Naročite obnovo njegovega zemljevida kot samostojno, majhno fazo, preden kogarkoli prosite za oceno prenove. Na brezplačnem svetovanju vam bomo svetovali, kako takšno fazo načrtovati in kaj pričakovati po njej.
Dogovorite se za brezplačno svetovanje prek kontaktnega obrazca →