Modernizacija naslijeđenih sustava bez Big Banga: Migracijski plan u 6 faza za aplikacije u srednjim poduzećima

Zamjena ustaljene aplikacije na papiru često zvuči jednostavnije nego u praksi. U srednjim poduzećima poslovni softver obično je usko povezan s realnim procesima: obrada narudžbi, skladište, proizvodnja, servis, obračun, usklađenost. Upravo zato klasični „Big Bang“ često ne uspijeva: datum kada je sve novo stvara maksimalnu nesigurnost – stručno, tehnički i organizacijski.

Modernizacija naslijeđenih sustava bez Big Banga znači planirati modernizaciju kao kontroliranu preinaku tijekom rada. Umjesto „sve novo“ radi se o nizu etapa koje smanjuju rizik, pažljivo prenose podatke i sučelja te ne opterećuju operativu. Ključ je plan migracije koji ne obuhvaća samo arhitekturu, već i podršku, izdanja, prava pristupa, monitoriranje, obuke i puteve odlučivanja.

Slijedeći plan u 6 etapa formuliran je tako da IT-rukovodstvo, administratori, tehnički voditelji projekata i poslovne jedinice dobiju zajedničku orijentaciju: što treba kad biti razjašnjeno, koji artefakti su potrebni i koje će odluke kasnije imati skupe posljedice?

Modernizacija naslijeđa bez Big Banga: Zašto se Big Bang u praksi rijetko pokaže održivim

Big-Bang promjena okuplja mnogo promjena u jednom trenutku: novo korisničko sučelje, novi modeli podataka, nova prava pristupa, nova sučelja, novi parametri rada. Čak i ako svaka pojedina komponenta „funkcionira“, kombinacija pod opterećenjem u produkciji često je izvor rizika: neplanirani rubni slučajevi, nedostajući podaci, različita logika osnovnih podataka, netestirani putovi integracije.

Tipični simptomi u projektima koji su preveliki:

• Neprecizne odgovornosti: Tko odlučuje u slučaju sukoba ciljeva između poslovne jedinice i operacija? Bez jasnih uloga detaljna pitanja eskaliraju u temeljne rasprave.
• Praznine u testiranju zbog raznolikosti procesa: Temeljni procesi se testiraju, ali posebni slučajevi iz 10 godina prakse nisu. Upravo ti posebni slučajevi završavaju pri Go-liveu u Service Desku.
• Migracija podataka „u zadnjoj fazi“: Odluke o mapiranju se odgađaju. Kasnije se pokaže da povijesni podaci, reference ili duplikati blokiraju migraciju.
• Operativa se uključuje prekasno: monitoriranje, backupi, ponovno pokretanje, prozori održavanja, rutine patchiranja – sve se to ne može smisleno u zadnjem tjednu „nadograditi“.

Postepena modernizacija nije sporiji put, već planiraniji: raspoređuje rizik kroz vrijeme, stvara mjerljive međudostave i omogućuje da stvarna saznanja iz upotrebe utječu na sljedeće etape.

Temeljno načelo: Strangler Pattern i „žive“ granice integracije

U mnogim uspješnim modernizacijama primjenjuje se Strangler Pattern: nove funkcionalnosti ili moduli grade se oko starog sustava i postupno preuzimaju odgovornost dok stari dio više nije potreban. Važno je pravilno prenijeti to u operativu: nije presudan sam arhitektonski pattern, već čiste granice integracije.

Granice integracije su mjesta gdje sustavi razmjenjuju podatke ili zajednički pristupaju podacima. To uključuje sučelja (na primjer REST, datoteke, messaging), zajedničke baze podataka, modele identiteta i prava pristupa te pozadinske zadatke. Modernizacija postaje upravljiva kada se te granice svjesno oblikuju:

• Stabilan ugovor prema van: partnerski ili okolni sustavi ne bi trebali morati obrađivati mnoge promjene istovremeno.
• Mjerljivost: Tokovi podataka moraju biti promatrivi (logovi, metrike, stope pogrešaka), kako bi operativni tim i vodstvo projekta rano prepoznali rizike.
• Mogućnost rollbacka: Ako neka etapa uzrokuje probleme, sustav se mora moći vratiti u stabilno stanje bez stvaranja „kaosa s podacima“.

Plan migracije u 6 etapa

Etape su namjerno formulirane tako da redom nameću pouzdane odluke. Pojedine stavke se mogu paralelizirati – ali se ne smiju preskakati, jer će to kasnije biti skuplje.

Etapa 1: Inventarizacija koja povezuje operacije i poslovnu stranu

Modernizacija rijetko ne uspije zbog „premalo tehnologije“, već zbog pogrešnih pretpostavki o ovisnostima. Dobra inventarizacija stoga nije puki arhitektonski dokument, već pragmatičan skup karata i rizika koji svi sudionici mogu pročitati.

Provjereni sadržaji za Etapu 1:

• Mapa aplikacija: Koje aplikacije, servisi, poslovi (jobs) i prateći sustavi ovise o jezgrenom sustavu? Koji od njih su poslovno kritični, a koji su samo „lijepo imati“?
• Karta integracija: Koja su sučelja prisutna (izvoz datoteka, EDI, REST, SOAP, pristup bazi podataka, SFTP)? Tko je vlasnik, koji podatkovni objekti teku, koja je učestalost?
• Inventar podataka: Koji su skupovi podataka primarni (System of Record), koji izvedeni (izvješća, izvoz)? Kako su uređeni pohrana i brisanje?
• Operativna realnost: Kako se provode deploymenti? Postoje li planirani prozori za održavanje? Kako izgleda koncept backupa? Koja su realna vremena za oporavak?
• Prioritizacija bolnih točaka: Ne „sve je staro“, nego: Gdje su promjene rizične? Gdje postoje uska grla u izvedbi? Gdje nedostatak mogućnosti integracije blokira?

Važno: Ova etapa idealno završava zajedničkom prioritetizacijom. IT i poslovna jedinica određuju koja će se procesna područja prvo modernizirati (na primjer unos narudžbi ili portal za kupce), i koja će se područja stabilizirati (na primjer logika knjiženja), kako bi se izbjegli sporedni konflikti.

Etapa 2: Definiranje ciljane slike – ali kao okvir za odluke, ne kao konačno stanje

U srednjem poduzetništvu ciljna slika brzo postane „lista želja“. Korisnije je ciljna slika kao okvir za odluke koji skraćuje kasnije rasprave. To uključuje eksplicitne vodilje: Što ostaje on-prem, što može ići u oblaku? Koja je baza podataka zadana? Kako će se identiteti integrirati? Kako će se nove komponente upravljati u radu?

Praktično to znači:

• Principi arhitekture: npr. „sučelja prvo“, „bez direktnih pristupa bazi od strane trećih sustava“, „verzioniranje API-ja“.
• Operativna načela: npr. „svaka nova komponenta ima Monitoring i Runbook“, „Deployments su reproduktivni“, „prozori za patchiranje se mogu planirati“.
• Načela podataka: npr. „System of Record je jednoznačan“, „povijesni podaci migriraju se ili arhiviraju prema definiranim pravilima“.

Središnja odluka u ovoj etapi je buduća strategija integracije. Mnogi timovi podcjenjuju da integracijski rad (sučelja, modeli podataka, obrada pogrešaka) često čini većinu složenosti. Tko ovdje rano postavi standarde, smanjuje kasnije trzavice u radu.

Ako želite naknadno uvesti ili stabilizirati sučelja za postojeći softver, pomaže tretirati temu kao samostalan tok modernizacije – ne kao sporedni zadatak na kraju.

Etapa 3: Odvajanje sučelja i podataka – „Preinaka na srčano-žilnom sustavu“

U mnogim naslijeđenim okruženjima baza podataka je tajni medij integracije: izvještaji direktno čitaju, prateći sustavi pišu u tablice, pozadinski zadaci zaobilaze poslovna pravila. To čini promjene opasnima, jer nitko ne može sa sigurnošću reći koji će upiti ili vanjski procesi sutra prestati raditi.

Stoga je u Etapi 3 riječ o kontroliranom odvajanju. Tipični elementi:

• API-fasada: Definirano sučelje (na primjer REST), preko kojeg nove i postojeće komponente čitaju i zapisuju podatke. REST ovdje znači: HTTP-bazirano sučelje s jasnim krajnjim točkama i strukturiranim JSON-podacima; važne su verzioniranje i konvencije za pogreške.
• Adapter za stare sučelja: Gdje izravna zamjena nije moguća, grade se prijelazni adapteri (konverteri datoteka/EDI, Message-Bridge, Proxy).
• Ugovori o podacima: Koja polja su obvezna, koja opcionalna? Koji kodovi/statusi su dopušteni? Ta pravila moraju biti dokumentirana i testabilna.

Organizacijski je Etapa 3 trenutak u kojem timovi trebaju lagani set API-Governance: konvencije imenovanja, verzioniranje, pravila deprecacije, strategija testiranja, proces odobravanja. Bez governance-a nastaje „kaos sučelja“: mnogo sličnih krajnjih točaka, nejasna odgovornost, Breaking Changes bez prethodne najave.

Još jedan fokus: Kvaliteta podataka. Modernizacija otkriva probleme s podacima koji su prije bili „weginterpretiert“. Zato biste već ovdje trebali uspostaviti jednostavne provjere: postotak duplikata, kršenja stranih ključeva, nevažeće vrijednosti statusa, neočekivane NULL vrijednosti. To je manje BI-tema, a više operativni i migracijski rizik: loši podaci povećavaju opseg testiranja, opterećenje podrške i stopu pogrešaka u paralelnom radu.

Etapa 4: Funkcionalna modernizacija kroz vertikalne presjeke

Najčešća pogrešna procjena kod postupne migracije: moderniziraju se tehnički slojevi, ali bez funkcionalno upotrebljivih međurezultata. To vodi dugim razdobljima u kojima poslovne jedinice „ne vide ništa“, dok se napor i rizik povećavaju.

Umjesto toga dokazuju se vertikalni presjeci: jasno ograničen proces modernizira se od kraja do kraja – uključujući korisničko sučelje, poslovna pravila, pristup podacima i sučelja. Primjeri su definirani podproces poput unosa reklamacije, modul korisničkog portala ili workflow odobravanja.

Na što bi IT i vodstvo projekta trebali obratiti pozornost:

• Kriteriji prihvaćanja: Ne samo „radi“, nego: Koji koraci procesa su pokriveni? Koje uloge? Koji slučajevi pogrešaka? Koji pragovi performansi?
• Upravljanje izdanjima: Kako se isporučuje bez opterećenja korisnika? Jasan ritam, čiste bilješke o izdanju, definirane opcije povrata (rollback) i komunikacijski kanal smanjuju vrhove podrške.
• Konfiguracija umjesto specijalnih slučajeva: Ako proces ima deset varijanti, velika je napast svaku varijantu „hardkodirati“. Često se isplati najprije definirati konfigurabilan model (npr. model statusa, pravila validacije), kako bi kasnija proširenja ostala planirana.

U ovoj fazi također postaje jasno je li cilj održiv: Odgovara li model dopuštenja? Radi li logging tako da su slučajevi podrške rekonstruabilni? Jesu li timeouti, retries i tekstovi pogrešaka tako oblikovani da pomažu u radu umjesto da samo proizvode „Greška 500“?

Faza 5: Paralelni rad, planiranje cutovera i migracija podataka bez iznenađenja

Paralelni rad je sigurnosna mreža modernizacije – ali samo ako je svjesno koncipiran. Paralelni rad ne znači nužno „dva sustava rade sve dvaput“. Obično to znači: neko vrijeme staro i novo postoje paralelno, dok su podaci sinkronizirani ili su odgovornosti jasno razdvojene.

Ključno je pitanje: Koji podaci su gdje vodeći? ‚Vodeći‘ znači: gdje nastaje istina za objekt (na primjer kupac, narudžba, artikl, račun)? Bez te jasnoće nastaju nekonzistentnosti koje snose podrška i poslovni odjeli.

Za fazu 5 preporučuju se tri tehničke i organizacijske smjernice:

• Strategija sinkronizacije: Bazično na događajima (Events/Messaging), API-bazirano (novi sustav poziva staru logiku ili obrnuto) ili vremenski kontrolirano (Jobs). Svaka varijanta ima operativne posljedice: Monitoring, tolerancija pogrešaka, naknadna obrada.
• Cutover-Runbook: Slijed koraka za prebacivanje: zamrzavanje podataka (koji se podaci od kada više ne smiju mijenjati?), importni prolazi, izvještaji validacije, preusmjeravanje sučelja, komunikacijski plan, kriteriji za rollback.
• Izvještaji usklađenja: Ne ‚migriramo i nadamo se‘, nego: provjere suma i broja stavki, uzorkovanje, referentne liste. Ti izvještaji trebaju biti pokrenuti više puta u testnim okruženjima prije cutovera.

Migracija podataka rijetko je jednokratni import. Često je potrebno više probnih pokusa s očišćenim mapiranjima, jer se anomalije vide tek u stvarnim podacima: duplikati ključeva, povijesno nastale posebne vrijednosti, nedostajuća obavezna polja. Tko to prihvati i planira kao proces učenja, izbjegava žurne ‚hotfix-migracije‘ tijekom vikenda.

Jedna potcijenjena točka: Audit i sljedivost. U poslovno kritičnim procesima nije dovoljno da podaci „postoje“. Potrebni su sljedivi putovi knjiženja i izmjena (Audit Trail), posebno kada su pogođena prava, cijene, odobrenja ili obračun. To treba uzeti u obzir i pri paralelnom radu i Cutoveru.

Etapa 6: Stabilizacija, predaja u rad i kontrolirano gašenje

Mnoge modernizacije službeno završavaju s Go-liveom – a operativno zapravo počinju tek nakon toga. Etapa 6 je faza u kojoj se odlučuje hoće li novo rješenje biti dugoročno održivo ili su se tehnološki dugovi samo premjestili.

Ključne teme u ovoj etapi:

• Hypercare s jasnim pravilima: Definirana faza stabilizacije nakon puštanja u proizvodnju, s utvrđenim komunikacijskim kanalima, klasifikacijom grešaka i prioritizacijom. Važno: nije svaki zahtjev incident.
• Runbooks i monitoring: Runbooki su operativne upute za ponavljajuće zadatke i incidente (start/stop, tipični obrasci grešaka, logovi, ponovno podizanje). Monitoring obuhvaća metrike i alarmiranje; cilj nije „nadgledati sve“, nego „relevantne signale“ bez zamora od alarma.
• Patch i rutine ažuriranja: Tko uvodi moderne komponente mora učiniti ažuriranja planiranim: prozori održavanja, rollback, sigurnosna ažuriranja, ovisnosti o runtime-okruženjima i bazama podataka.
• Plan gašenja za stari sustav: Gašenje je dio projekta: arhiviranje podataka, zakonsko čuvanje, zaustavljanje poslova, uklanjanje starih sučelja, prilagodba operativnih priručnika.

Dobar pokazatelj uspješne Etape 6: tim nakon nekoliko tjedana ne samo da „gasi požare“, nego ponovno može isporučivati planirano. To uspijeva kada operacija i projekt u Hypercare fazi zajednički određuju prioritete i trajno uklanjaju uzroke (na primjer kroz bolje validacije, jasne poruke o pogreškama, robusne timeout-e sučelja).

Točke odlučivanja koje podupiru raspored

U svim etapama postoje ponavljajuće odluke koje su posebno učinkovite u srednje velikim projektima. Ne tiču se toliko same tehnologije koliko sposobnosti za rad i migraciju.

1) Identitet i prava pristupa rano razjasniti

Kad nastaju novi moduli, često se sukobljavaju različiti koncepti prava pristupa: povijesno nastale uloge u starom sustavu, Active Directory-grupe, aplikacijske uloge, pristupi vanjskih partnera. Ovdje se isplati rano odrediti smjer: na primjer Single Sign-on preko SAML 2.0 (standard za centralnu prijavu) ili konsolidirani model uloga s recertifikacijom (redovita provjera prava).

Bez čistog plana za identitete, paralelni rad brzo povećava napor: duplu administraciju korisnika, nejasne odgovornosti, slučajeve podrške zbog „pogrešne uloge“. To nije marginalna tema, već gubitak produktivnosti u svakodnevnom radu.

2) Standardizirati okruženja i deploymente

Mnogi legacy sustavi rade stabilno zato što „nitko više ništa ne dira“. Modernizacija povećava učestalost promjena – a time i potrebu za reproducibilnim deploymentima. Presudno je da Dev/Test/Prod ne odlutaju jedni od drugih (razlike u konfiguraciji, nedostajući certifikati, različiti parametri baze podataka). U praksi to znači: versionirati konfiguracije, čisto upravljati tajnim podacima (Secrets), pakirati i dokumentirati releaseove na način koji se može pratiti.

3) Definirati observabilnost kao zahtjev za operativu

Observabilnost znači: u slučaju greške moguće je rekonstruirati što se dogodilo – preko logova, metrika i korelacije. Korelacija znači da se pripadajući koraci mogu povezati kroz sustave (na primjer preko Request-ID). To štedi sate u podršci jer uzroke više nije potrebno „pogađati“.

4) Ne podcjenjivati plan promjena i komunikacije

Postupna migracija živi od toga da korisnici promjene doživljavaju ponovljeno. Bez plana komunikacije i obuke to vodi otporu ili skrivenim procesima (Excel-liste, ručni zaobilazni koraci). Korisno je imati pilotne skupine, jasne povratne petlje i definiran kanal za pitanja. To nije zadatak marketinga, već smanjuje opterećenje podrške i pogreške u podacima.

Kako ukotviti plan u svakodnevnom radu projekta

Plan vrijedi samo ako se prevede u upravljanje i suradnju. Tri praktična mehanizma:

• Kontrolne točke za etape s kontrolnim popisima: Svaka etapa završava jasnim kriterijima: Što je isporučeno (artefakti, odluke), što je otvoreno, koji je rizik prihvaćen?
• Dnevnik odluka: Jednostavna, kontinuirano vođena dokumentacija odluka (Što je odlučeno? Zašto? Koje su posljedice?). To sprječava da timovi mjesecima kasnije ponovno otvaraju temeljna pitanja.
• Zajednička ploča rizika: Ne samo tehnički rizici, već i operativni i organizacijski rizici (nedostajuće uloge, nejasna odgovornost za podatke, praznine u testiranju). Svaki rizik ima vlasnika i mjeru.

Pogotovo u srednje velikim okruženjima, gdje timovi paralelno održavaju više sustava, transparentnost je važnija od perfekcije. Plan treba ubrzati donošenje odluka, a ne stvarati dodatnu birokraciju.

Zaključak: Modernizacija kao kontrolirana pregradnja umjesto oklade na krajnji rok

Modernizacija legacy sustava bez Big Bang pristupa nije kompromis, već metodički pristup za objedinjavanje rizika, operativne sigurnosti i stručnosti. 6-etapni plan osigurava da integracije i podaci ne prolaze „usput“, da paralelni rad ne postane kaos i da je prijelaz u operaciju svjesno isplaniran.

Ako želite modernizirati zrelu aplikaciju, isplati se prvo mapirati plan na vaše ključne procese i integracije: Što je zaista vodeće, koja su sučelja poslovno kritična i koja etapa sljedeća donosi najveće smanjenje rizika?

Ako želite sastaviti konkretan, vašem krajoliku prilagođen plan migracije, temu možete strukturirati s nama u inicijalnom razgovoru: Kontaktirajte nas.

Razgovarajte o projektu ili modernizacijskom pothvatu s Net-Base.