Modernizacija legacy sistema bez Big Bang pristupa: Migracioni plan u 6 faza za aplikacije u srednjim preduzećima

Ponedjeljak ujutro, 8:27. Telefonski lanac ne počinje porukom o grešci, već rečenicom koja u srednjim preduzećima redovno eskalira: „Od ažuriranja ne izlaze narudžbe.“ U sistemu za tikete stoje tri simptoma koja se ne poklapaju: ein Exportjob radi „zeleno“, partner prijavljuje nedostajuće zapise, i u poslovnoj jedinici su iznenada vrijednosti statusa prazne. Niko nije promijenio taj modul – ali nešto je u međudejstvu starog sistema, međujoba i importa puklo.

Upravo u ovom području napetosti modernizacija naslijeđenih sistema bez Big Bang postaje praktično pitanje, a ne metoda za raspravu. Dva cilja djeluju u suprotnim smjerovima: maksimalna stabilnost u tekućem radu (nema zastoja, planirani prozori održavanja, reproducibilni ponovni pokretanja) i primjetan napredak modernizacije (nove funkcije, bolji podaci, manje prekida medija). Oba su dostižna – ali rijetko istovremeno u maksimalnom režimu.

Članak je koncipiran kao karta procjene: gdje pristup u etapama zaista smanjuje rizike, gdje uvodi novu kompleksnost, i za koju početnu situaciju je Big-Bang-Cutover uprkos upozorenjima i dalje vjerovatan? U središtu je plan migracije u 6 etapa za tipične aplikacije u srednjim preduzećima – s artefaktima koje IT-drift, poslovni odjel i vođenje projekta kasnije zaista trebaju: routing-pravila, odgovornost za podatke, putevi grešaka, monitoring, Runbooks i Cutover-Proben.

Modernizacija naslijeđenih sistema bez Big Bang u praksi

Cilj A: Sigurnost rada i predvidljivost. Uprava IT-a i administracija moraju ograničiti rizike: deploymenti trebaju biti kontrolisani, incidenti brzo izolovani, putevi ponovnog pokretanja testirani. Svaka dodatna tranzicijska komponenta u početku povećava operativni opseg: više krajnjih tačaka, više jobova, više stanja, više mjesta za timeout-e i greške u ovlašćivanju.

Cilj B: Tempo modernizacije i poslovna korist. Poslovni odjeli prihvataju tranzicijske faze ako u razumnim intervalima vide poboljšanja: novi korak procesa, jasnije izvještavanje, manje ručnih lista. Ako se projekt mjesecima „samo interno restrukturira“, prioritet i prihvatanje opadaju – i iznenada se opet pojavi strogi rok.

Big Bang obećava jasno „Prije/Nakon“. Međutim, rizik se koncentrira na jedan termin. Postepena migracija raspoređuje rizik na više tačaka prebacivanja – ali se plaća tranzicijskom kompleksnošću (paralelni rad, routing, sinhronizacija). Nije metoda presudna, već da li možete operacionalizirati odgovarajući tip rizika u svakodnevnom radu.

Zašto Big Bang u praksi često zakaže — i kada je ipak prikladan

Kod Big Bang-a se mnoge stvari mijenjaju istovremeno: korisničko sučelje, ovlaštenja, model podataka, sučelja, batch-jobovi, operativni parametri. Svaka komponenta može djelovati „završeno“ sama za sebe – kombinacija pod stvarnim opterećenjem je glavni izvor rizika. Kritično je to u okruženjima u kojima su poslovna pravila tokom godina dospjela na mnoge lokacije: u pozadinskim servisima, eksportima, Excel-workaroundima, partnerskim skriptama ili dodatnim alatima.

Najčešće tačke loma rijetko su „kod“; češće su to okolnosti:

• Testabilnost: Varijante procesa iz svakodnevnog rada ne mogu se potpuno pokriti za zadani datum. UAT (User Acceptance Test, poslovno prihvatanje) postaje usko grlo.
• Migracija podataka: mapiranja, duplikati, historijske specijalne vrijednosti i implicitna pravila postaju vidljivi tek kasno – tada nastaje žurba umjesto iterativnog učenja.
• Operativna primopredaja: Monitoring, Runbooks (operativne upute), procedure vraćanja i on-call rutine se „na kraju brzo“ dopunjavaju. Rezultat: funkcionalno prihvatljivo, ali operativno skupo.

Kada Big Bang ipak može imati smisla? Kada je aplikacija jasno ograničena, ima malo integracija, obim i kvalitet podataka su pregledni i Cutover/Rollback se u probama realno mogu odigrati. Ta kombinacija u srednjem poslovanju nije pravilo – ali postoji.

Strangler Pattern plus Routing: Obrasac iza „ohne Big Bang“

Das Strangler Pattern (također Strangler Fig Application) opisuje ideju postupnog „preuzimanja“ legacy sistema: novi dijelovi preuzimaju funkcije jedan po jedan dok središte legacyja postane suvišno. Za porijeklo termina smatra se dokumentovana metafora „Strangler Fig“ za evolucijsko zamjenjivanje.^[Quelle]

Za operacije i upravljanje projektom manje je važan naziv od posljedica: trebate jednu Routing- odnosno Gateway-sloj koji korisnike i okolne sisteme ne prisiljava stalno na nove krajnje točke. Routing ovdje znači: kontrolisana tačka odlučuje hoće li zahtjev ili korak procesa ići u novi modul ili u stari sistem. Ta tačka mora biti konfigurabilna, davati logove/metrike i u slučaju nužde moguća za povratno prebacivanje.

Net-Base opisuje kombinaciju Strangler-pristupa, paralelnog rada i pravila za konzistentnost podataka kao održiv put – i svrstava zamjenu izričito kao prelazno i operativno pitanje, ne kao „mi gradimo novo i gotovo“.^[Quelle]

Karta procjene: Etapna migracija vs. Big Bang u jednoj tabeli

Aspekt	Postepena Migration (ohne Big Bang)	Big Bang
Rizik pri Go-live	Raspoređeno preko više tačaka prebacivanja; uz to dodatni prelazni rizici (Routing, sinhronizacija, stanja)	Snažno koncentrirano na jedan termin; u slučaju problema veliki pritisak zbog zastoja
Operativni napor tokom prebacivanja	Veći: dva okruženja paralelno, dodatni putevi grešaka, prelazni monitoring	Kraći vrhunac; nakon toga idealno jedno okruženje (ako je predaja dosljedna)
Poslovna korist	Rano moguće kroz vertikalne preseke procesa; povratne informacije ulaze u sljedeće etape	Vidljivo kasno; korist dolazi tek nakon dana prelaska
Migracija podataka	Više probnih pokretanja, postupno preuzimanje vođstva moguće; uz to rad na usklađivanju i konfliktima

Veliki opseg; visoki zahtjevi za Freeze, mapiranje, validaciju, Backout Pritisak na donošenje odluka Mnoge male odluke rano (System of Record, Umschaltregeln, Fehlerpolitik) Manje odluka do skoro samog kraja; zatim pod vremenskim pritiskom Tipično pogodno za Mnoge integracije, velika varijabilnost procesa, mali prostor za Cutover Jasna razgraničenja, malo integracija, vrlo disciplinirana priprema za Cutover/testiranje

Plan migracije u 6 faza za aplikacije srednjih preduzeća

Faze su odabrane tako da prisiljavaju na odluke koje bi kasnije bile skupe. Radne cjeline se mogu paralelizovati, ali se ne smiju proizvoljno preskakati bez stvaranja rizika.

Faza 1: Inventarizacija koja prikazuje ovisnosti i operativnu realnost

Pregled sistema u obliku dijagrama je početak, ali nije inventarizacija koja nosi projekt modernizacije. Presudno je: Koje ovisnosti zaista postoje, koje su samo pretpostavke i šta se dešava u slučaju greške?

• Integracijska mapa: vrste sučelja (REST/HTTP, fajlovi, EDI, SFTP, direktni DB-pristupi), frekvencije, vlasnici, posljedice grešaka.
• Katalog poslova i batch-eva: Pozadinski poslovi često su „živčani sistem“ okruženja. Bez ovog kataloga teško je planirati paralelni rad.
• Lista podataka-objekata: kupac, narudžba, artikl, račun, osnovni podaci, vrijednosti statusa: Koji objekti su kritični, koji su samo izvedeni?
• Operativna realnost: Deployments, prozori održavanja, Backup/Restore, stanje nadgledanja, Incident- i Change-proces.

Rezultat ne smije glasiti „sve je naraslo“, već treba pripremiti odluke: Gdje su tačke loma? Koje integracije treba najprije stabilizovati? Koji procesi pogoduju kao rezovi faza?

Faza 2: Ciljni model kao okvir za odlučivanje – sa vodilicama za operacije i sigurnost

Ciljni model pomaže samo ako skraćuje diskusije. Zato trebate vodilice koje se u praksi mogu provjeriti: Šta ubuduće više ne smije da se dešava (npr. direktni DB-upisi iz sekundarnih sistema)? Šta svaka nova komponenta mora isporučiti (npr. monitoring i Runbook)?

Metodički je fokus na procesima više od pitanja stila: BSI u svojoj migracijskoj uputi za moderniziranu IT-Grundschutz metodologiju naglašava analizu strukture duž poslovnih procesa kao i izvlačenje zahtjeva za zaštitom iz procesa i informacija.^[Quelle] Praktična posljedica: Ako zahtjevi za zaštitom, uloge i obaveze dokazivanja proizlaze iz toka informacija, i faze modernizacije bi trebale biti rezane duž tih tokova – a ne duž tabela ili tehničkih slojeva.

• Arhitektonski principi: „sučelja prvi“, API-Versionierung, bez skrivenih integracijskih puteva.
• Operativni principi: Rollback definisan, Deployments reproducibilni, svaka komponenta sa logovima/metrikama/alarmiranjem.
• Sicherheitsprinzipien: Princip najmanjih privilegija (minimalna prava), centralizovani identitet, revizijski trag za kritične akcije.

Važna je granica: Ciljno stanje ne rješava konflikte. Ono ih čini vidljivim i prisiljava na prioritete – upravo to je njegova uloga.

Faza 3: Stabilizacija granica integracije – rutiranje, API-ji i kontrolisani ugovori o podacima

Mnoge legacy-okoline imaju jednu tihu istinu: baza podataka je medij integracije. Izvještaji pristupaju direktno, sporedni sistemi pišu u tabele, batch-jobovi zaobilaze poslovna pravila. To djeluje „praktično“, ali čini svaku promjenu rizičnom, jer niko ne može sigurno reći ko koja polja i kako koristi.

Faza 3 uspostavlja stabilnost na rubovima:

• API-fasada: standardizovani pristupi (tipično HTTP/REST) s verzionisanjem i jasnom konvencijom grešaka. Za operacije su bitni timeouti, ponovni pokušaji, rate-limiti i reproduktibilni signali grešaka.
• Routing/Gateway: mjesto koje usmjerava korisničke grupe, procesne korake ili tipove objekata na staro ili novo. Za operativu važno: konfiguracija, auditabilnost, rollback-mehanika, jasni log-signali.
• Ugovori o podacima: obavezna polja, statusne vrijednosti, validacije – kao eksplicitna pravila umjesto implicitnih pretpostavki.

Trade-off ove faze: stvara dodatne komponente prije nego što poslovni odjel vidi mnogo „novog“. Ko ovdje štedi, kupuje prividnu brzinu, ali kasnije proizvodi prelazne slučajeve koji su skupi za otklanjanje grešaka.

Faza 4: Modernizacija u vertikalnim procesnim rezovima – end-to-end upravljivo

Česta zabluda: „Prvo moderniziramo tehnologiju, pa će korist doći automatski.“ U praksi poslovni odjel dugo ništa ne vidi, prioritet opada i na kraju se opet nameće konačni rok.

Bolje funkcionišu vertikalni rezovi: proces se realizuje end-to-end – korisničko sučelje, pravila, pristupi podacima, sučelja, monitoring, putevi podrške. Net-Base preporučuje etape eksplicitno orijentisane prema procesima (npr. izrada ponude, prijem robe, reklamacija) umjesto vođenih podacima ili tabelama, jer je etapa stvarno produktivna i nadglediva samo tada.^[Quelle]

To ima nuspojavu koju rukovodioci projekata cijene: svaka etapa proizvodi stvarne objekte za prihvat. Ne „refaktorirali smo“, već „ovaj procesni korak radi u produkciji, s metrikama i putem podrške“.

Faza 5: Paralelni rad i konzistentnost podataka – kritični put

Paralelni rad nije projektni trik, već planirani način rada. Funkcioniše samo ako su vlasništvo nad podacima i politika upravljanja greškama jasno određeni. Net-Base svrstava paralelni rad kao svjestan režim sa kriterijima za prekid i opisuje tipične modele preusmjeravanja (prema grupama korisnika, lokacijama/mandantima, koracima u procesu ili tipovima objekata) zajedno s pripadajućim rizicima.^[Quelle]

Ključni pojam je System of Record: sistem koji za određeni podatkovni objekt drži vodeću istinu. Bez te odluke nastaju nekonzistencije koje se kasnije u radu manifestuju kao „Daten spinnen“ — i tada ih je vrlo teško objasniti.

Tipični obrasci sinhronizacije u paralelnom radu (s operativnim posljedicama):

• Dual Write: Opišu se oba sistema. Rizik: konflikti i dvostruke posljedice; zahtijeva idempotenciju (višestruko izvršavanje bez višestrukog efekta) i definirana pravila za rješavanje konflikata.
• CDC (Change Data Capture): Izmjene se izvlače iz baze podataka i prenose. Rizik: složenost otklanjanja grešaka i operativnog upravljanja; zahtijeva karantenu/dead-letter (spremište za neobradljive događaje) i koncepte za ponovno pokretanje.
• Event-/API-basiert: Promjene prolaze preko definiranih događaja ili API-ja. Rizik: latencija, ponovni pokušaji, djelomični kvarovi; s druge strane obično bolje nadgledivo i upravljivo.

Važna granica: nijedna varijanta nije „besplatna“. Ili plaćate u implementaciji, ili u operativnom radu, ili u ručnom razrješavanju konflikata. Realno planiranje počinje tamo gdje se ti troškovi prihvate kao dio plana.

Etapa 6: Cutover, stabilizacija, primopredaja u radu – i stvarno gašenje

Cutover nije kraj projekta. To je prelazak u novu operativnu normalu. Etapa 6 obuhvata tri stvari: prebacivanje, stabilizaciju (Hypercare) i kontrolisanu dekomisiju legacy-dijelova (uključujući arhiviranje/dokaze).

Cutover-Runbook ovdje nije formalnost, već redukcija rizika. Praktičan slijed koraka koji se može vježbati:

1. Odrediti Cutover-Freeze: Koji se podaci od kada više ne smiju mijenjati? Kako se to komunicira i tehnički osigurava?
2. Zadnji probni pokus: Migracija i usklađivanje u okolini bliskoj produkciji sa aktuelnim podacima (anonimizovano, ako je potrebno).
3. Backup- i RESTore-checkpoint: Prije prebacivanja napraviti definiranu sigurnosnu kopiju; procedura za vraćanje podataka spremna i testirana.
4. Preusmjeravanje sučelja: Routing/Gateway i integracije preusmjeriti na nove putanje; odgovornosti po sučelju jasno definirati.
5. Izvršiti validacijske izvještaje: sume, količine, uzorci, referentne liste; klasificirati odstupanja (kritično vs. prihvatljivo vs. za naknadnu obradu).
6. Pokrenuti Hypercare: jasan proces za incidente, prioritetizacija, kratki dnevni status; rad na uzrocima umjesto nagomilavanja tiketa.
7. Provesti plan isključenja: deaktivirati stare poslove, dekomisionirati legacy-endpointe, ispuniti obaveze arhiviranja i čuvanja.

Tipična zamka je „polovičan“ završetak: novo rješenje je u produkciji, ali stari poslovi i dalje rade, partneri neprimjetno koriste legacy-datoteke, ili izvještaji još uvijek direktno pristupaju starim tabelama. To stvara duplirani rad i održava rizike u sistemu, iako je projekt službeno „završen“.

Tačke odlučivanja koje podržavaju plan puta (i često dolaze prekasno)

Identitet, uloge, servisni nalozi: Wenn das nicht sitzt, explodiert Support

U paralelnom radu sudaraju se koncepti prava pristupa: historijske uloge, AD-grupe, partnerski pristupi, tehnički korisnici. Ako se ova razjašnjenja dogode tek neposredno prije Cutovera, pojavljuju se dva problema istovremeno: sigurnosni rizici (preširoke privilegije, nedostatak mogućnosti praćenja) i opterećenje podrške (korisnik se ne može prijaviti, posao ne radi, partnerski nalog je blokiran).

Pragmatičan cilj: razumljiv model uloga, pravilo za recertifikaciju (redovna provjera prava) i ein Audit-Trail za kritične akcije. Audit-Trail znači: moguće i provjerljivo logiranje izmjena koje su relevantne za obračun, odobrenja ili usklađenost.

Observability: Was muss der Betrieb im Fehlerfall in 15 Minuten wissen?

Observability (vidljivost) je sposobnost razumijevanja stanja sistema i uzroka grešaka preko logova, metrika i korelacije. Korelacija znači povezivanje pripadajućih koraka preko sistema (npr. Request-ID ili Vorgangs-ID). U tranzicionoj arhitekturi to nije dodatak, već sprječava eskalacijsko ping-pong ponašanje između timova.

Praktična formulacija koju se može koristiti kao gate-kriterij: „Za svaki modernizovani procesni rez postoji jasan signal da li je odgovoran stari ili novi sistem, i gdje je bio posljednji uspješni korak.“

Release- und Change-Rhythmus: Kleine Lieferungen sind nur dann gut, wenn sie nicht ständig stören

Modernizacija po etapama povećava frekvenciju isporuka. Bez upravljanja izdanjima to djeluje kao stalna gradilišna zona: korisnici gube povjerenje, operacije pate zbog čestih roll-outova, a uprava projekta dobija rasprave o „stalno novim greškama“.

Korisni su jednostavni standardi: fiksni prozori za održavanje, jasni komunikacijski kanali, definirana odluka o rollbacku i Release Notes s minimumom informacija (šta se mijenja, ko je pogođen, koji je work-around, gdje su logovi/čekovi?). To smanjuje trenje po izdanju.

Der Schlusspunkt: Gute Etappenpläne machen Umschalten langweilig

Modernizacija legacy sistema bez Big Bang-a nije sporiji put, već drugačiji pristup riziku. Ulažete rano u granice integracije, vođenje podataka (System of Record) i vidljivost, kako biste kasnije mogli isporučivati u stručno smislenim rezovima. Cijena je tranziciona kompleksnost. Dobit je Cutover koji ne postaje egzistencijalni test za operacije i poslovne odjele.

Ako želite konkretizirati svoj 6‑etapni plan, počnite s dva provjerljiva pitanja: Koji objekti podataka trebaju jedinstvenu odgovornost (System of Record) – i koji rez procesa je dovoljno mali da se može end-to-end operativno modernizovati? Iz toga često proizlaze pravila rutiranja, potreba za sinhronizacijom i gate-kriteriji brže nego što klasični „sve-novo“ planovi pretpostavljaju.

Izvori i dodatne informacije

Stručne ključne tvrdnje su urednički kontekstualizirane na osnovu sljedećih eksternih izvora.

1. Original Strangler Fig Application (martinfowler.com)
   Strangler-Pattern je evolutivni pristup u kojem novi dijelovi postupno zamjenjuju legacy sistem (metafora ‚Strangler Fig‘).
2. Postepena zamjena naslijeđenih sistema bez Big Banga | Net-Base (net-base-software-gmbh.de)
   Postepena zamjena naslijeđenih sistema opisuje se kao kombinacija Strangler-pristupa, paralelnog pogona i pravila za dosljednost podataka; paralelni pogon se kategorizira kao planirani način rada s modelima prebacivanja i kriterijima za prekid.
3. Vodič za migraciju sigurnosnih koncepata (epflicht.ulb.uni-bonn.de)
   U metodologiji sigurnosti i migracije naglašava se fokus na poslovne procese u strukturnoj analizi i izvlačenje potreba za zaštitom iz procesa i informacija, što podržava procesno-orijentisane etapne preseke.

Za ovu temu su također važni Cutover-planiranje i modernizacija sučelja. Članak ove aspekte jasno kontekstualizira i pokazuje, na šta u praksi treba obratiti pažnju.

Razgovarajte o projektu ili planu modernizacije s Net-Base.