Plan modernizacije gotov, proračun preliminarno prihvaćen. Izvođač postavlja prvo pitanje: „Gdje je dokumentacija sustava?”. Ispostavlja se da postoji wiki zadnji put ažuriran prije pet godina, nekoliko shema „negdje na mrežnom disku” i kod koji sam sebi služi kao dokumentacija. Procjena raste za trećinu. Jer izvođač ne naplaćuje posao, nego neizvjesnost.
Ovaj tekst opisuje praksu koja tu neizvjesnost skida sa stola: prije nego što itko dirne kod stare aplikacije, rekonstruira se znanje o njoj. Donedavno je takva etapa značila tjedne rada analitičara i malo tko se na nju odlučivao. Danas AI obavlja većinu te analize u radnim danima. I to mijenja redoslijed cijelog projekta.
Najprije mapa, zatim kod
Modernizacija sustava bez aktualne dokumentacije podsjeća na renovaciju zgrade bez plana instalacija. Može se, ali svako rušenje zida je lutrija: možda iza njega nema ničega, a možda je cijev o kojoj ovisi pola kata. U aplikacijama ta cijev zna biti integracija sa skladištem koje se sjećao samo autor koda ili noćni izvoz koji potiho koristi računovodstvo.
Zato je razuman redoslijed obrnut od intuitivnog. Ne počinje se pisanjem novog koda, pa ni procjenom. Počinje se mapom.
Što AI izvlači iz koda, baze i logova
Moderni alati za analizu znaju pročitati tri izvora istine o sustavu: izvorni kod, strukturu baze podataka i logove iz produkcijskog rada. Njihovim križanjem nastaje mapa sustava koja obuhvaća četiri sloja.
Prvi su moduli: od čega se sustav sastoji i za što svaki dio odgovara, opisano jezikom razumljivim i osobama izvan IT-a. Drugi su tokovi podataka: odakle podaci ulaze, što se s njima događa usput, gdje završavaju. Treći su integracije, odnosno sva mjesta na kojima aplikacija razgovara s drugim sustavima: računovodstvom, skladištem, trgovinom, partnerima. One najčešće pucaju pri promjenama.
Četvrti sloj je najmanje očit: mrtvi kod. Analiza logova pokazuje koje funkcije godinama nisu pozvane i u koje tablice nitko ne piše od 2019. U starijim sustavima takav balast često čini priličan dio cjeline. Svaka linija koju ne treba prenositi stvarna je ušteda u projektu.
Što mapa mijenja u odluci „prepisati ili modernizirati”
O samoj odluci pisali smo zasebno, u tekstu o četiri kriterija: okvir za odlučivanje. Mapa sustava tim kriterijima daje tvrde podatke. Bez nje se tehnološki dug procjenjuje po osjećaju, a rizik na temelju anegdota. S njom se crno na bijelo vidi: koji moduli nose poslovnu vrijednost, koji su mrtvi, gdje sjede integracije koje podižu rizik svake promjene.
Rezultati znaju iznenaditi u oba smjera. Ponekad se sustav koji „treba prepisati od nule” pokaže u tri četvrtine zdravim i dovoljno je zamijeniti dva modula. Ponekad obrnuto: aplikacija izgleda nevino, a mapa otkriva desetak nedokumentiranih veza koje djelomičnu modernizaciju čine skupljom od prepisivanja. U oba slučaja odluka pada na podacima, ne na emocijama. A izvođač koji umjesto zagonetke dobije mapu naplaćuje posao umjesto rizika.
Po našem mišljenju rekonstrukcija mape trebala bi biti zasebna, prva etapa ugovora o modernizaciji, s vlastitom primopredajom. Čak i ako nakon te etape odlučite da modernizaciju radi netko drugi ili je uopće ne radite, dokumentacija ostaje u tvrtki i dalje radi.
Kako provjeriti ono što je AI generirao
Automatski generirana dokumentacija nije proročište. Treba je provjeriti. Najučinkovitija metoda je jednostavna: pregled s osobom koja sustav najbolje poznaje, često jedinom takvom u tvrtki. Razlika u odnosu na klasični pristup leži u ulozi te osobe. Ne tražite od nje da zapiše znanje, što nitko ne voli i što se vuče mjesecima. Tražite recenziju gotovog opisa, a pokazivanje „ovdje se slaže, ovdje ne” ide višestruko brže od pisanja od nule.
Dobra je praksa proći kroz nekoliko najvažnijih procesa od početka do kraja: narudžba, faktura, reklamacija. Ako mapa ispravno opisuje kritične tokove i nasumično provjerene detalje, može joj se vjerovati i u ostalim područjima. To se može napraviti u jednom danu.
Što AI neće rekonstruirati
Ovdje poštena ograda: kod govori što sustav radi, ali ne govori zašto. Čudna iznimka u obračunu rabata može biti pogreška, a može biti i trgovački dogovor iz 2016. koji i dalje vrijedi za jednog velikog klijenta. To nijedna analiza koda neće razriješiti. Poslovne namjere od prije desetljeća rekonstruiraju se intervjuima: kratkim razgovorima s ljudima iz prodaje, računovodstva i operacija, vođenima već s mapom u ruci. Mapa sugerira što pitati, ali odgovore ima čovjek.
Zasebna tema je i okruženje aplikacije: serveri, mreža, sigurnosne kopije. O dokumentiranju tog sloja pisali smo u tekstu o auditu dokumentacije infrastrukture.
U ESKOM AI etapu mapiranja provodimo timom specijaliziranih AI agenata pod nadzorom iskusnih inženjera: analiza tipičnog poslovnog sustava traje radne dane, a rezultat je dokumentacija čitljiva upravi i tehničkom timu. Ako nakon nje padne odluka o modernizaciji, daljnji radovi teku u automatiziranom procesu razvoja softvera s punim opsegom testova — jediničnih, integracijskih, E2E, UI, sigurnosnih i testova performansi.
Od čega početi kod sebe
Odaberite jedan sustav: onaj čiju modernizaciju odgađate najdulje ili onaj kojeg se najviše bojite dotaknuti. Naručite rekonstrukciju njegove mape kao samostalnu, malu etapu, prije nego što ikoga zamolite za procjenu pregradnje. Na besplatnoj konzultaciji savjetovat ćemo kako takvu etapu isplanirati i što od nje očekivati.
Dogovorite besplatnu konzultaciju putem kontaktnog obrasca →