Jei jūsų verslas sėkmingai išgyveno augimo fazę, greičiausiai esate priklausomi nuo kažkokios programinės įrangos, kuri „šiaip jau veikia“, bet akivaizdžiai sensta. Tai sistema, valdanti jūsų inventorių, logistikos grafiką ar sąskaitų klientams išrašymą. Tačiau kartu tai yra sistema, prie kurios bet kuri programuotojų komanda bijo liestis.
Pakeisti bent vieną kodo eilutę tokioje sistemoje prilygsta „Jenga“ žaidimui per uraganą. Kiekvienas prašymas naujai funkcijai pasitinkamas atodūsiais, ilgais terminais ir įspėjimais, kad „viskas gali lūžti“.
Jūs puikiai žinote, kad programinė įranga jus stabdo, bet negalite sau leisti rizikos, kad sistema nustos veikti. Augančiam verslui net ir kelios valandos prastovos gali reikšti tūkstančius eurų prarastų pajamų ir negrįžtamai sugadintą klientų pasitikėjimą.
Šis gidas atvirai papasakos apie pasiteisinusią, strateginę sistemą, kaip inkrementiškai modernizuoti jūsų trapią seną („legacy“) programinę įrangą – be jokių trigdžių, nuostolių ir „Big bang“ perrašymo (visko perrašymo nuo nulio) rizikos.
Prapultis, kurios vardas „Big Bang“ perrašymas
Kai senos sistemos tampa pernelyg trapios, natūralus daugelio įkūrėjų ir vadovų instinktas yra paspausti „Reset“ mygtuką. Komanda pasiūlo „Big bang“ perrašymą: išmesti seną kodą velniop ir pastatyti visiškai naują sistemą nuo nulio.
Ant popieriaus tai skamba labai logiškai. Tai žada švarų lapą, modernią architektūrą, greitus kodo rašymo ciklus ir elegantišką vartotojo patirtį. Realybėje – „Big bang“ perrašymas yra klasikiniai, milžiniški ir be galo brangūs spąstai.
Fundamentali visiško perrašymo yda yra ta, kad senos sistemos savyje turi paslėptą verslo logiką. Per penkerius, dešimt ar penkiolika metų prie sistemos dirbusi komanda užlopė šimtus kritinių kraštutinumų (edge cases), prisitaikė prie besikeičiančių įstatymų ir giliai į kodą įsiuvo rankinius apėjimus. Didžioji dalis šių gilių operacinių žinių niekur nėra dokumentuota.
Bandydami perrašyti visą sistemą nuo nulio, jūs šaudote į judantį taikinį. Egzistuojanti sistema privalo ir toliau veikti ir keistis, kad palaikytų kasdienes operacijas. Naujoji sistema yra pasmerkta amžinai stengtis pasivyti senąją.
Rezultatas beveik identiškas visada: projektas vėluoja, tragiškai viršija biudžetą, o po išleidimo pasirodo kaip nestabilus produktas be visų funkcionalumų. Tai didžiausios rizikos ir mažiausios investicinės grąžos (ROI) loterija, kurios daugelis MVĮ tiesiog negali sau leisti.
Paralyžiaus kaina ir „laukimo mokestis“
Pasirinkimas nieko nedaryti yra lygiai toks pat pavojingas, kaip ir bandymas desperatiškai viską perrašinėti. Gyvenimas su pasenusiomis, byrančiomis sistemomis yra lėtas nukraujavimas, kuris jūsų finansinėse ataskaitose atsispindi keliais būdais.
1. Priklausomybės nuo senų programuotojų mokestis
Kai jūsų kodas yra senas ir neįskaitomas, tik jį rašę programuotojai geba jį palaikyti. Jei šie asmenys palieka įmonę – jūsų operacinė gyvybė akimirksniu tampa pažeidžiama. Pasamdyti modernius programuotojus, kad jie kapstytųsi po pasenusias ir trapias sistemas, yra išskirtinai sunku ir be proto brangu.
2. Užblokuotas inovacijų greitis
Versle greitis yra esminis konkurencinis pranašumas. Jei jūsų konkurentai gali išridenti automatizuotą klientų portalą per dvi savaites, o jūsų komandai reikia trijų mėnesių kančių tiesiog norint atnaujinti pagrindinį API „endpoint’ą“, jūs natūraliai atiduodate rinkos dalį. Jūsų programinė įranga turi būti augimo variklis, o ne stabdis.
3. Katastrofinio sistemos lūžio rizika
Trapios sistemos anksčiau ar vėliau lūžta. Pavargusios duomenų bazės nustoja veikti, seni trečiųjų šalių API yra išjungiami be jokio įspėjimo, o saugumo spragos kaupiasi. Jei jūsų pagrindinė platforma „nulūžta“ piko metu, kritinio atstatymo kaštai akimirksniu pralenks suplanuoto ir strateginio modernizavimo kainą.
Sprendimas: „Strangler pattern“ (Smaugiko modelis)
Mes atmetame šį netikrą pasirinkimą tarp byrančios sistemos palaikymo ir neprognozuojamo perrašymo nuo nulio. Vietoj to, mes taikome labai kontroliuojamą ir chirurginę architektūrinę strategiją – „Strangler pattern“ (pavadintą pagal smaugikų šeimos medžius, kurie pamažu apauga medį šeimininką, kol jį visiškai pakeičia).
Užuot perstatinėję visą platformą iškart, mes perimame srautą ties pačia sistemos riba ir po atskirą modulį ar detalę laipsniškai migruojame į modernią architektūrą. Jūsų vartotojams ir darbuotojams viskas atrodo kaip viena vientisa sistema, tačiau užkulisiuose senoji architektūra yra sistemiškai utilizuojama ir pakeičiama.
Pastatę „interceptor’ių“ (pavyzdžiui, „API Gateway“ ar „Reverse proxy“) priešais jūsų senąją sistemą, mes galime laisvai nukreipti srautą. Jei vartotojas naudojasi sena funkcija, ją sklandžiai aptarnauja sena duomenų bazė. Bet jei jis paspaudžia ant funkcionalumo, kurį jau atnaujinome, jis nukreipiamas tiesiai į naują, greitą infrastruktūrą.
Šis metodas iki minimumo sumažina techninę riziką, nesutrikdo kasdienių verslo operacijų ir tiesiogiai suriša kūrimo išlaidas su realiomis ROI metrikomis.
Funkcijų prioritizavimas greičiausiai grąžai (ROI) gauti
Inkrementinė migracija bus sėkminga tik tada, jei teisingai sudėliosite prioritetus. Niekada nepradėkite nuo pačios sudėtingiausios duomenų bazės ar pagrindinio transakcijų variklio.
Klasifikuodami senos sistemos dalis, mes remiamės griežta matrica, kuri apskaičiuoja svarbą verslui ir implementacijos riziką:
| Funkcijų kategorija | Rizikos lygis | Poveikis verslui | Migracijos prioritetas | Strateginis veiksmas |
|---|---|---|---|---|
| Greitos pergalės („Quick wins“) (pvz., ataskaitų portalai, „onboardingas“) | Žemas | Aukštas | Prioritetas 1 | Migruojama pirmiausiai tam, kad įrodytų pasirinktos technologijos naudą ir duotų greitą ROI. |
| Žemai kabantys vaisiai (pvz., vidiniai admin įrankiai) | Žemas | Žemas | Prioritetas 2 | Migruojami darbams įpusėjus, kad būtų galima atjungti antrinius senos sistemos serverius. |
| Sistemos stuburas (pvz., pagrindinė DB, finansiniai varikliai) | Aukštas | Aukštas | Prioritetas 3 | Migruojami mažais žingsniais tik pačiose vėlyviausiose fazėse su griežta kontrole ir testais. |
| Pasenusios funkcijos (pvz., nenaudojami „legacy“ API) | Žemas | Nėra | Praleisti | Visiškai eliminuoti. Nešvaistykite biudžeto tuštumų atstatinėjimui. |
Prioritizuojant „greitas pergales“, gaunami trys kritiniai rezultatai:
- Jūsų klientai ar darbuotojai pastebi akivaizdžius našumo ir patogumo pokyčius.
- Jūsų vidinės komandos atgauna pasitikėjimą technine sistema.
- Projektas natūraliai pats save finansuoja, atnešdamas operacinį neefektyvumą naikinantį našumą.
Verslas nesustoja: 0 trigdžių architektūra
Kad ši migracija nesugriautų jūsų kasdienių operacijų, mūsų techninė strategija remiasi dviem pagrindiniais elementais: perėmimu (interception) ir duomenų sinchronizacija.
Realaus laiko duomenų tiltai
Migracijos metu tiek senoji, tiek atnaujinta duomenų bazė privalo veikti vienu metu. Mes sukuriame lengvus, įvykiais paremtus (event-driven) duomenų tiltus.
Jei klientas atnaujina savo pristatymo adresą per atnaujintą vartotojo sąsają, tie duomenys akimirksniu įrašomi į pamatinę modernią duomenų bazę ir tuo pačiu metu yra nukopijuojami į senąją. Ši abipusė sinchronizacija (bi-directional sync) užtikrina absoliutų duomenų vientisumą per abi sistemas.
Saugumo tinklelis ir „Rollback“ paruošimas
Jei paleidžiame naujai modernizuotą modulį ir atsiranda giliai paslėptas nelauktas techninis „košmaras“, mūsų maršrutizavimo (routing) sluoksnis leidžia akimirksniu grąžinti srautą į seną (bet saugią ir veikiančią) sistemą paspaudus vieną „virtualų“ mygtuką.
Toks lygio kontrolės valdymas sunaikina stresą, lydintį masinius programinės įrangos išleidimus, ir paverčia milžinišką perėjimą į paprastų ir nuobodžių atnaujinimų seką.
Mūsų požiūris: Efektyvi modernizacija nešvaistant biudžetų
„codus“ netiki perpūstomis korporatyvinėmis architektūromis ar nevaldomai dideliais projektų terminais. Mes esame fokusuota ir chirurgiškai tiksli komanda, sprendimus pritaikanti smulkaus ir vidutinio verslo (MVĮ) biudžetams.
Mūsų modernizavimo procesas yra orientuotas į skaidrumą ir radikalų rizikos mažinimą:
- Chirurgija, o ne buldozeris: Jei tam tikra jūsų senos sistemos dalis veikia stabiliai, saugiai ir atlieka savo funkciją – mes paliekame ją ramybėje. Viską fokusuojame išimtinai į „prasčiausias dalis“, kurios trukdo jūsų kasdieniam produktyvumui arba blokuoja naujų pajamų srautus.
- Biudžetą gerbiantys etapai: Migraciją skaldome į nepriklausomus funkcinius blokus. Kiekvienas etapas palieka po savęs veikiantį, produkcinėje aplinkoje apčiuopiamą turtą. Taip realią pridėtinę vertę (ir grąžą – ROI) matote kiekviename projekto posūkyje.
- Modernus technologijų pasirinkimas: Architektūrą formuojame iš modernių, pilno steko (full-stack) technologijų. Tai panaikina tam tikrą „aklavietę“ (vendor lock-in) prie vieno tiekėjo ir paverčia jūsų sistemą patrauklia bet kuriai rimtai inžinierių komandai ateityje.
Apibendrinant: Nustokite nuomotis savo technologinę skolą
Sena ir prastai veikianti programinė įranga pati savaime yra sėkmingo verslo įrodymas – jūs sugebėjote išaugti ir pralenkti savo originalią infrastruktūrą. Tačiau leisti trapiai, atgyvenusiai technologijai diktuoti, kaip jūs augsite ateityje – yra labai blogas operacinis pasirinkimas.
Pasirinkę kontroliuojamą ir laipsniškai augantį smaugiko modelį, jūs eliminuosite visiškos katastrofos riziką bandant paleisti vieną milžinišką sistemą iškart, apsaugosite esamus pelno srautus ir papildysite savo įmonę aukščiausios vertės inžineriniu turtu.
Jei šiandien jūsų komanda daugiau laiko praleidžia bintuodama trūkinėjančią programinę įrangą nei augindama verslą – laikas nustoti lopyti spragas ir pastatyti aukštesnės klasės fundamentą.