Modernizacija legacy sustava ne mora značiti big bang migraciju u kojoj se sve poslovne funkcije i podaci mijenjaju odjednom. Sigurniji pristup je postupno izdvajanje poslovnih cjelina: najprije razumijete stvarno ponašanje starog sustava, zatim uvodite novu komponentu uz jasnu granicu, provjeravate prijenos podataka i povrat, a staru vezu gasite tek kada novi put pouzdano preuzima posao.
Takav pristup ne uklanja sav rizik. Umjesto jednog velikog prekida, uvodi niz manjih odluka koje se mogu mjeriti, provjeriti i po potrebi vratiti. Njegova vrijednost nije samo u novijoj tehnologiji, nego u tome što tvrtka može promijeniti važno poslovno pravilo bez istodobnog ugrožavanja cijelog poslovanja.
Stari sustav može biti težak za promjenu, ali često sadrži godine poslovnih pravila koja nisu zapisana nigdje drugdje. Dokumentacija može opisivati kako je proces zamišljen. Stvarni podaci, logovi, izvještaji i postupci korisnika pokazuju kako proces doista funkcionira.
Big bang migracija pretpostavlja da će tim prije puštanja u rad razumjeti, prepisati i provjeriti sve bitne iznimke. Problem nastaje kada se iznimka otkrije tek u radu: kod storna, povrata, naknadne promjene cijene, zaključavanja razdoblja ili oporavka nakon prekida integracije. Tada tehnički nedostatak brzo postaje poslovni problem, primjerice pogrešan saldo, neobrađen dokument ili zastoj u isporuci.
Postupna modernizacija legacy sustava smanjuje opseg svake pojedine promjene. Ne pokušava dokazati da je cijeli novi sustav spreman od prvog dana. Dokazuje da jedna jasno omeđena poslovna funkcija može sigurno prijeći na novi put.
Prije odabira tehnologije napravite operativnu sliku procesa koji mijenjate. Cilj nije izraditi savršenu dokumentaciju svega, nego prepoznati uvjete pod kojima poslovni rezultat može biti pogrešan ili nejasan.
Za odabranu poslovnu cjelinu popišite:
Posebno izdvojite rijetke događaje. Oni se možda ne pojavljuju svaki dan, ali često nose najveći migracijski rizik. Kraj godine, korekcija već proknjiženog dokumenta, djelomični povrat, promjena matičnog podatka nakon transakcije ili ponavljanje obrade nakon prekida mogu otkriti skrivena pravila i ovisnosti.
Ovaj korak može biti dio ERP i procesnog screeninga . Screening nije zamjena za odluku o arhitekturi, ali može pomoći razjasniti poslovnu granicu, vlasnike procesa i rizike prije nego što tim počne prepisivati funkcionalnost.
Strangler pattern uvodi novu komponentu uz stari sustav i postupno joj predaje promet ili funkcionalnost. Naziv pristupa nije važniji od odluke koju traži: nova komponenta mora imati granicu koju poslovanje i tim mogu razumjeti.
Dobar prvi kandidat obično ima tri obilježja:
Loš prvi kandidat je središnji obračun koji ovisi o mnogim drugim procesima, nema pouzdane testne podatke i ne može se vratiti bez utjecaja na cijelo poslovanje. Takvu cjelinu nije nužno zauvijek ostaviti netaknutom, ali nije razumno njome dokazivati prvi val modernizacije.
Prije izdvajanja definirajte ugovor na granici. Ugovor određuje koje podatke novi dio prima, koje rezultate vraća, tko je vlasnik podatka i kako se postupa kada podatak nedostaje ili nije valjan. Novi dio ne bi smio izravno čitati deset internih tablica legacy sustava. Takva prečica može ubrzati početak, ali samo premješta staru ovisnost u novi sustav i otežava kasnije gašenje.
Ako je poslovna cjelina već povezana s više procesa, korisno je promatrati je u kontekstu povezanog poslovanja . Pitanje nije samo kamo ide podatak, nego koji poslovni događaj pokreće promjenu i koji sustav nakon prijelaza nosi odgovornost za rezultat.
Migracija podataka nije završena kada skripta jednom prođe bez tehničke pogreške. Mora biti ponovljiva nad svježom kopijom podataka, imati izmjereno trajanje i ostaviti trag o razlikama koje su pronađene.
Za svaki važan objekt definirajte provjere koje odgovaraju poslovnoj namjeni podataka. To mogu biti:
Financijski saldo, stanje zalihe ili otvorene obveze ne provjeravaju se samo brojem redaka. Dvije baze mogu imati jednak broj zapisa, a različit poslovni rezultat. Zato svaka probna migracija treba proizvesti popis razlika s vlasnikom odluke.
Neke razlike jesu pogreška u prijenosu. Neke nastaju jer se podaci namjerno čiste. Treće pokazuju da novo pravilo nije isto kao staro. Bez takve podjele tim lako prihvati razliku kao tehničku pojedinost, iako ona mijenja poslovni smisao podatka.
Tijekom prijelaza stari i novi sustav često neko vrijeme rade paralelno. Dual run može pomoći u provjeri rezultata, ali nije besplatan. Stvara sinkronizaciju, dvostruke kontrole i pitanje koji je sustav mjerodavan kada se podaci razlikuju.
Zato prijelazno stanje treba imati rok, opseg i plan gašenja. Za svaki korak zapišite:
Povrat nije znak neuspješnog projekta. To je unaprijed dogovorena zaštita poslovanja dok se nova komponenta provjerava. Povrat mora biti konkretan: tko ga može aktivirati, koje transakcije obuhvaća, kako se obrađuju zapisi nastali tijekom prekida i kada se ponovno procjenjuje spremnost za prijelaz.
Nije svaka stara komponenta kandidat za prepisivanje. Neke funkcije ima smisla zamijeniti standardnim rješenjem. Druge treba omotati stabilnim API-jem kako bi novi dijelovi sustava prestali ovisiti o internim tablicama. Treće je razumno zadržati dok ne izgube poslovnu važnost ili dok se ne promijene povezane ovisnosti.
Prioritet dajte dijelu koji stvara poslovni rizik ili usporava važnu promjenu. To može biti proces s mnogo ručnih koraka, integracija koja često zahtijeva intervenciju, izvještaj kojem nitko ne vjeruje ili pravilo čija izmjena traži koordinaciju previše timova. Kod koji timu estetski najviše smeta nije nužno prvi poslovni prioritet.
Dobar okvir za odluku pita četiri stvari:
Broj migriranih ekrana, servisa ili redaka koda pokazuje opseg rada, ali ne i je li poslovanje postalo lakše mijenjati. Korisniji signali su:
Gašenje je dio vrijednosti, a ne završna administrativna stavka. Nova platforma koja trajno radi uz legacy sustav može udvostručiti trošak, kontrole i operativni teret. Za svaki val modernizacije zato definirajte ne samo što uvodite, nego i koju staru vezu, licencu, ručni posao ili rizik uklanjate.
Sljedeći korak neka ne bude popis svih zastarjelih komponenti. Odaberite jednu poslovnu granicu, odredite vlasnika podataka, pripremite ponovljivu probnu migraciju i unaprijed napišite uvjete za dual run, povrat i gašenje. Dovoljno malen prvi val može se vratiti, a dovoljno važan uklanja jednu stvarnu staru obvezu.