Kādā brīdī gandrīz katrā migrācijas sarunā parādās viens un tas pats jautājums: cik tas maksās?
Tas izklausās vienkārši. Praksē tas gandrīz nekad tā nav.
Lielākā daļa organizāciju spēj novērtēt infrastruktūru, izveidot aptuvenus termiņus un saprast komandas kapacitāti. Taču, tiklīdz runa ir par reālo migrācijas darba apjomu, pārliecība strauji samazinās. Iemesls nav pieredzes trūkums. Problēma ir tajā, ka faktiskās izmaksas neatrodas tur, kur tās sākotnēji tiek meklētas.
Sākotnējā plānošana parasti fokusējas uz redzamiem elementiem, piemēram, datubāzes izmēru, shēmu skaitu vai infrastruktūru. Tie ir izmērāmi un saprotami, tāpēc rada sajūtu, ka situācija ir kontrolējama. Taču lielākajā daļā enterprise sistēmu tie nav faktori, kas nosaka galveno darba apjomu. Patiesā sarežģītība slēpjas dziļāk, procedurālajā loģikā.
Oracle vidēs biznesa loģika bieži ir iestrādāta PL/SQL pakotnēs, procedūrās, funkcijās, trigeros un citos Oracle specifiskos konstrukciju veidos. Šī loģika ir veidota gadiem ilgi un atspoguļo reālos biznesa procesus. Tajā ir ietvertas regulatīvās prasības, izņēmuma gadījumi un vēsturiski pieņemtie lēmumi. Bieži vien bez konsekventas dokumentācijas. Daudzās sistēmās vairs nav neviena cilvēka, kurš pilnībā saprot, kā viss darbojas kopā.
Tieši šeit pazūd prognozējamība.
No plānošanas viedokļa procedurālais kods rada nenoteiktību, kuru ir grūti iekļaut sākotnējos aprēķinos. Komandas bieži analizē shēmas vispirms un tikai vēlāk iedziļinās loģikā. Tajā brīdī budžeti jau ir apstiprināti un termiņi noteikti. Jauna informācija vairs nepalīdz plānam, tā to destabilizē.
Papildus tam sarežģītība neaug lineāri. Divas līdzīga izmēra sistēmas var prasīt pilnīgi atšķirīgu darba apjomu. Tas ir atkarīgs no tā, kā loģika ir strukturēta, cik cieši komponentes ir savstarpēji saistītas un cik lielā mērā tiek izmantotas Oracle specifiskas funkcijas. Tāpēc pieejas, kas balstās uz koda apjomu vai objektu skaitu, bieži neatspoguļo realitāti.
Testēšana pievieno vēl vienu dimensiju. Migrācija nav tikai koda pārnešana. Tā ir pārliecināšanās, ka sistēma pēc migrācijas uzvedas identiski. Tas nozīmē vienību testus, regresijas testus un biznesa validāciju. Testēšanas apjoms ir tieši saistīts ar loģikas sarežģītību, nevis datubāzes izmēru, un tieši tāpēc tas bieži tiek novērtēts par zemu.
Ja šī sarežģītība netiek saprasta sākumā, organizācijas to kompensē ar rezervēm. Budžeti tiek palielināti, termiņi pagarināti un plānošana kļūst piesardzīgāka. Paradokss ir tajā, ka jo mazāka skaidrība sākumā, jo dārgāks un lēnāks projekts kļūst vēl pirms tā uzsākšanas.
Prognozējamākie migrācijas projekti sākas citādi. Pirms tiek pieņemti lēmumi par budžetu un termiņiem, tie koncentrējas uz sistēmas izpratni. Tiek analizēts, cik liela daļa koda ir automatizējama, kur atrodas sarežģītākās vietas, cik daudz darba būs manuāli un kāds būs testēšanas apjoms. Šie nav teorētiski jautājumi, uz tiem var atbildēt tikai, analizējot pašu kodu.
Šī pāreja, no pieņēmumiem uz faktiem, būtiski maina visu projekta dinamiku. Budžeti kļūst pamatotāki, termiņi realistiskāki un riski redzami agrīni, kad tos vēl var vadīt. Un pats svarīgākais, lēmumus kļūst vieglāk pieņemt, jo tie balstās datos, nevis pieņēmumos.
Migrācija pati par sevi nav neprognozējama. Tā kļūst neprognozējama tad, kad lēmumi tiek pieņemti pirms sistēma ir saprasta.
Atšķirība starp kontrolētu un sarežģītu migrāciju visbiežāk nav tehnoloģijās. Tā ir tajā, vai pirms izpildes sākuma bija pietiekama skaidrība.
Jo pēc tam šo skaidrību iegūt kļūst ievērojami dārgāk.