Naslijeđeni softver - sustav koji radi, ali je tehnološki zastario - je glavi bol gotovo svake hrvatske tvrtke s 10+ godina poslovanja. Pravilna odluka između nadogradnje, migracije i kompletnog ponovnog razvoja može razlikovati €20.000 i 6 mjeseci od €200.000 i 2 godine. Tipičan kriterij: ako popravak postojećeg sustava traje više od 50% novog razvoja - bolje krenuti ispočetka. Ako je manje od 30% - migracija je gotovo uvijek racionalnija.
Ovaj članak razlaže kako objektivno procijeniti naslijeđeni sustav, koje tehnike migracije postoje, i kako izbjeći najveće zamke pri ponovnom razvoju.
Tri tipa naslijeđenog softvera (i različiti pristupi)
Ne tretirajte sve “stare” sustave jednako. Postoje tri osnovna scenarija:
Tip 1: Sustav koji radi, ali se ne može mijenjati
- Tehnologija je zastarjela (npr. PHP 5, Visual Basic 6, stari Java-EE)
- Originalni razvojni tim odavno otišao
- Svaka mala izmjena traje tjednima
- Pristup: Refaktoring ili postupna migracija (strangler fig pattern)
Tip 2: Sustav koji se kvari sve češće
- Bug-ovi se pojavljuju kao zarazni
- Performansi padaju, posebno u špici
- Sigurnosne nadogradnje su godinama propuštene
- Pristup: Hitan plan migracije, sa stabilizacijom postojećeg dok se ne završi novi
Tip 3: Sustav koji više ne pokriva poslovne potrebe
- Poslovanje se promijenilo, softver nije
- Pokušaji prilagodbe stvaraju kaos
- Vlasnik više ne razumije što sustav radi
- Pristup: Kompletno preispitivanje - često znači novi razvoj
Realan trošak održavanja naslijeđenog sustava
Najveća greška: misliti da je “ne dirati” sustav najjeftinija opcija.
Skriveni troškovi naslijeđenog sustava:
- Sporiji rad zaposlenih. Sustav koji troši 10 sekundi po operaciji umjesto 1 sekunde, kod 100 operacija dnevno, gubi 15 minuta po zaposleniku - dnevno. Mjesečno: 5 sati po zaposleniku.
- Više grešaka. Stari sustavi imaju više bug-ova. Svaka greška znači manualnu intervenciju.
- Sigurnosni rizik. Stari sustavi imaju nepatchirane sigurnosne rupe. Jedan veliki hack može koštati 10x više od cijele migracije.
- Nemogućnost rasta. Nove funkcionalnosti su skupe ili nemoguće. Konkurencija ide naprijed, Vi ne.
- Talent retention. Developeri ne žele raditi na zastarjelim tehnologijama. Teško je naći nekoga tko će održavati.
Tipičan ukupan godišnji trošak održavanja zastarjelog sustava za malu/srednju tvrtku: €20.000-€80.000+ kroz izgubljeno vrijeme, pogreške i propuštene prilike.
Tri tehnike migracije
Ovisno o veličini sustava i tolerantnosti za rizik, biramo jednu od tri tehnike:
1. Strangler Fig (postupna migracija)
Što: Polako mijenjamo dijelove starog sustava novim, kao što biljka strangler fig postupno obrasta stablo.
Kako: Novi sustav preuzima jednu po jednu funkcionalnost. Stari ostaje paralelno dok se zadnji dio ne migrira.
Kada koristiti: Veliki sustavi s mnogo funkcionalnosti, gdje “big bang” migracija je prerizična.
Trajanje: 12-36 mjeseci.
Trošak: €40.000-€300.000+, ali raspoređeno kroz vrijeme.
Rizik: Niski - uvijek imate radeći sustav.
2. Big Bang (potpuna zamjena u jednom danu)
Što: U određenom trenutku stari sustav se gasi i pokreće novi.
Kako: Razvoj novog sustava paralelno sa starim, intenzivno testiranje, zatim “switch over”.
Kada koristiti: Manji sustavi, ili kada je staro toliko loše da paralelni rad nije isplativ.
Trajanje: 6-18 mjeseci razvoja, zatim 1 dan migracije.
Trošak: €30.000-€150.000.
Rizik: Visoki - ako nešto ne radi nakon switch-a, krizа.
3. Paralelni rad (oba sustava u radu)
Što: Stari i novi sustav rade paralelno mjesecima.
Kako: Podaci se sinkroniziraju, korisnici postupno prelaze na novi.
Kada koristiti: Kritični sustavi gdje downtime nije dopušten, ili kada se mora pokazati da novi sustav daje iste rezultate.
Trajanje: 3-12 mjeseci paralelnog rada.
Trošak: €50.000-€250.000+ (skuplji zbog dvostruke infrastrukture).
Rizik: Najniži - uvijek imate backup.
Kriteriji za odluku: migracija ili novi razvoj?
Šest pitanja koja pomažu odlučiti:
1. Koliko često se sustav mijenja? Često = vredna je investicija u novi. Rijetko = može se “zalijepiti” još godinu dana.
2. Postoji li dokumentacija? Postoji = migracija je realna. Ne = vjerojatno bolje krenuti ispočetka.
3. Koliko je sustav “duboko” u poslovnim procesima? Duboko = veliki trošak migracije, ali bez izbora. Plitko = relativno lako zamijeniti.
4. Imate li resurse za paralelni rad nekoliko mjeseci? Da = strangler fig ili paralelno. Ne = big bang ili produženje statusa quo.
5. Koliki je rizik od curenja podataka ili kvara? Visoki = hitno (sigurnost ide ispred). Niski = imate vremena.
6. Koliko je tvrtka tolerantna na downtime? Nije = paralelni rad obavezan. Jest = big bang ili strangler fig.
Najveće zamke pri ponovnom razvoju
Pet stvari koje često idu krivo:
1. Pokušaj kopirati sve značajke starog sustava 1:1. Mnoge stare značajke se ne koriste, ili rade krivo, ili su iz prošlog poslovnog modela. Mapirajte stvarno korištenje prije nego što gradite.
2. Bez plana za migraciju podataka. Stari sustav ima 5-15 godina podataka. Migracija nije “samo skripta” - često je 20-30% ukupnog opsega projekta.
3. Nedovoljno paralelnog rada. Switch over u prvom mjesecu donosi probleme. Plan barem 2-3 mjeseca paralelnog rada gdje je to moguće.
4. Bez obuke korisnika. Novi sustav ima drugačiju logiku. Bez plana obuke, korisnici reflektiraju otpor i traže “stari način”.
5. Bez plana za nakon migracije. Migracija je trenutak. Operate faza je godine. Plan održavanja i razvoja novih značajki mora biti ugovoren prije početka.
Kako razvojni partner pristupa naslijeđenom sustavu
Pravilan tijek koji koristimo:
Faza 1: Audit naslijeđenog sustava (2-4 tjedna)
- Pregled koda i arhitekture
- Identifikacija ključnih funkcionalnosti i poslovnih pravila
- Procjena rizika i mogućnosti
- Pisani izvještaj s preporukama
Faza 2: Odluka (1-2 tjedna)
- Prezentacija opcija s troškovima i vremenom
- Suradnja s klijentom na izboru pristupa
- Konačni opseg i ugovor
Faza 3: Razvoj/migracija (varira)
- Prema odabranom pristupu (strangler, big bang, paralelni)
- Sa kontinuiranim mjerenjem napretka
Faza 4: Stabilizacija (1-3 mjeseca)
- Postupno preusmjeravanje korisnika
- Aktivno praćenje grešaka
- Brz odgovor na probleme
Često postavljana pitanja
Možemo li sami napraviti audit ili treba vanjski stručnjak? Vlastiti tim može identificirati funkcionalne probleme. Vanjski stručnjak je obavezan za objektivnu tehničku procjenu - jer vlastiti developeri (ako još postoje) imaju emocionalnu vezu sa sustavom.
Što ako prvotni programeri više nisu dostupni? Češći scenarij nego što mislite. Audit traje malo duže (3-5 tjedana umjesto 2-4), ali se može napraviti uvijek. Najteže je s sustavima u tehnologijama koje praktički više nitko ne koristi.
Možemo li migrirati samo dio sustava? Da, to je upravo strangler fig pristup. Migrirate najbolnije dijelove prvo, ostali ostaju u starom sustavu dok ne stigne red.
Koliko traje typical migracijski projekt? Mali sustav: 3-6 mjeseci. Srednji: 8-18 mjeseci. Veliki sustav s povijesnim podacima: 18-36 mjeseci.
Imate naslijeđeni sustav?
Dogovorite besplatan Discovery razgovor. Pregledamo Vaš trenutni sustav, identificiramo rizike i mogućnosti, i predlažemo realan plan migracije - s konkretnim brojkama i vremenom, ne općenitim procjenama.
Javite nam se na [email protected] ili kroz formu na našoj stranici.