Modernizuokite sistemą, kurios niekas nedrįsta liesti, po vieną funkciją.
Dešimtmečių verslo taisyklės slypi COBOL, PL/I, Oracle Forms ir ankstyvųjų Java bei .NET programose. Atkuriame šias taisykles, sukuriame testų apsaugos tinklą ir funkciją po funkcijos perkeliame už fasado, lygiagrečiai vykdydami senąją ir naująją sistemas ir sutikrindami rezultatus prieš ką nors išjungdami.
Lietuvos institucijoms ir įmonėms, kurių svarbiausios sistemos negali sustoti, o jose užkoduotos taisyklės negali būti prarastos.
Įvertinamas sistemų portfelis ir sutariamas tikslas. Verslo taisyklės atkuriamos iš kodo padedant DI ir patikrinamos žmonių. Charakterizavimo testai sudaro apsaugos tinklą. Kiekviena funkcija perkuriama už fasado ir vykdoma lygiagrečiai su senąja sistema; skirtumai išanalizuojami ir ištaisomi, kol verslo savininkas patvirtina perjungimą ir senoji dalis išjungiama.
Prieš ir po
Kas pasikeičia Jūsų darbe
Dabar
Su sistema
Dabar
Dabar: Kiekvienas pakeitimas yra rizika
Nedideli reguliavimo pakeitimai užtrunka mėnesius, nes niekas negali numatyti, ką dar pakeitimas paveiks.
Su sistema
Su sistema: Pakeitimai, paremti testais
Charakterizavimo testai užfiksuoja, ką sistema daro šiandien, todėl kiekvieno pakeitimo poveikis matomas prieš išleidimą.
Dabar
Dabar: Žinios išeina į pensiją
Kodą suprantantys žmonės artėja prie pensijos, o dokumentacija seniai nebeatitinka sistemos.
Su sistema
Su sistema: Taisyklės užrašytos ir patikrintos
Iš kodo atkurtos verslo taisyklės aprašomos paprasta kalba, o jas patvirtina srities ekspertai.
Dabar
Dabar: Vieno didelio perjungimo planai stringa
Visiško pakeitimo programos žada vieną perjungimo datą, kuri vis nukeliama, o išlaidos auga.
Su sistema
Su sistema: Vertė dalimis
Funkcijos po vieną perkeliamos už fasado. Kiekviena dalis pradedama naudoti atskirai ir gali būti atšaukta.
Dabar
Dabar: Duomenys įkalinti senose struktūrose
Naujos paslaugos ir DI panaudojimo atvejai duomenų nepasiekia be trapių eksportų ir naktinių paketinių užduočių.
Su sistema
Su sistema: Duomenys pasiekiami per API
Perkeltos sritys savo duomenis teikia per dokumentuotas API, o jie sutikrinami su senąja sistema, kol ši išjungiama.
Darbo procesas
Kaip vyksta darbo procesas
Smaugiančiojo figmedžio (strangler fig) principas: naujoji sistema auga aplink senąją funkcija po funkcijos. Ciklas tarp lygiagretaus vykdymo ir perkūrimo yra ta vieta, kur atliekama didžioji tikro darbo dalis.
Iliustracinis darbo procesas
7 žingsniai · 3 žmogaus patikros
Legenda
Sistema
DI agentas
Žmogus
Žmogaus patikra
Išimties kelias
Senųjų sistemų modernizavimas: iliustracinis darbo procesas su sutikrinimo ciklu
Skaityti diagramą kaip tekstą
Pagrindinis kelias eina nuo portfelio įvertinimo ir verslo taisyklių atkūrimo, per charakterizavimo testų apsaugos tinklą ir vienos funkcijos perkūrimą už fasado, iki lygiagretaus senosios ir naujosios sistemų vykdymo ir galiausiai perjungimo bei senosios dalies išjungimo.
Žmonės patvirtina tikslinę architektūrą, patikrina kiekvieną atkurtą taisyklę ir patvirtina kiekvieną perjungimą: tai žmogaus patikros.
Kai lygiagretus vykdymas rodo, kad rezultatai skiriasi, dalis pasuka iš pagrindinio kelio į inžinierių ir srities ekspertų atliekamą skirtumų analizę ir grįžta į perkūrimo žingsnį, kol senosios ir naujosios sistemų rezultatai sutampa.
01
1 žingsnis: Portfelio įvertinimasŽmogus
Programų inventorius, priklausomybių ir duomenų srautų žemėlapis bei sprendimas kiekvienai programai: atsisakyti, palikti, perkelti į kitą infrastruktūrą, perkelti į kitą platformą, perkurti ar pakeisti. Sričių žemėlapis parodo vietas, kuriose sistemą galima skaidyti dalimis.
Žmogaus patikra
Jūsų architektūros taryba patvirtina tikslinę architektūrą ir dalių eiliškumą.
02
2 žingsnis: Verslo taisyklių atkūrimasDI agentas
DI padedama kodo analizė skaito COBOL, PL/I, JCL, Oracle Forms ir senesnį Java ar .NET kodą ir parengia dokumentacijos, iškvietimų grafų ir verslo taisyklių katalogo juodraščius.
Žmogaus patikra
Inžinieriai ir srities ekspertai patikrina kiekvieną išgautą taisyklę, prieš ją naudojant kaip specifikaciją. Nepatikrintos taisyklės taip ir pažymimos.
03
3 žingsnis: Apsaugos tinklo kūrimasSistema
Charakterizavimo testai generuojami iš nuasmenintų gamybinės aplinkos įvesčių ir išvesčių, todėl dabartinis elgesys, įskaitant jo keistenybes, užfiksuojamas dar prieš ką nors keičiant.
04
4 žingsnis: Dalies perkūrimas už fasadoSistema
Prieš senąją sistemą įdedamas maršrutizavimo fasadas arba API sluoksnis. Viena funkcija perkuriama kaip nauja paslauga, jos duomenys perkeliami ir sinchronizuojami.
05
5 žingsnis: Lygiagretus vykdymas ir sutikrinimasSistema
Senoji ir naujoji sistemos apdoroja tas pačias operacijas. Rezultatai ir duomenys palyginami automatiškai, o kiekvienas skirtumas pateikiamas pagal taisyklę ir įrašą.
06
6 žingsnis: Skirtumų analizėŽmogus
Inžinieriai ir srities ekspertai sprendžia, ar kiekvienas skirtumas yra naujosios paslaugos klaida, senosios sistemos klaida ar numatytas pakeitimas, ir grąžina dalį perdaryti.
Išimties kelias: Rezultatai skiriasi· Grįžtama į 4 žingsnį
07
7 žingsnis: Perjungimas ir išjungimasŽmogus
Funkcijos srautas per fasadą nukreipiamas į naująją paslaugą. Po stabilaus laikotarpio senasis kodo kelias ir jo duomenys išjungiami ir archyvuojami.
Žmogaus patikra
Kiekvieną perjungimą, remdamasis sutikrinimo rezultatais, patvirtina verslo savininkas. Grąžinimas per fasadą išlieka galimas iki išjungimo.
Komponentai
Ką sukurtume
01
Portfelio ir priklausomybių žemėlapis
Inventorius, sąsajų ir duomenų srautų žemėlapis ir sričių modelis, rodantis, kur sistemą galima skaidyti dalimis.
Salesforce kaip nauja klientų aptarnavimo sistemaPlatformaSalesforce
Integracijų platforma ir API šliuzas
Tikslinė debesija ar duomenų centras
Kontrolės priemonės
Nuo pradžių numatytos kontrolės priemonės
Prieigos ribos
Kodo analizė vykdoma Jūsų kontroliuojamoje aplinkoje, o išeitinis kodas nesiunčiamas į paslaugas, kurių nepatvirtinote. Testams naudojami gamybiniai duomenys nuasmeninami, prieš jiems paliekant gamybinę zoną.
Žmogaus peržiūra
Atkurtas taisykles patikrina inžinieriai ir srities ekspertai, prieš joms tampant specifikacijomis. Kiekvieną perjungimą, remdamasis sutikrinimo rezultatais, patvirtina verslo savininkas, o grąžinimas išlieka galimas.
Atsekamumas
Kiekviena katalogo taisyklė atsekama iki kodo, iš kurio ji gauta, ir iki ją patikrinusio žmogaus. Sutikrinimo ataskaitos saugomos kaip kiekvieno perjungimo įrodymas.
Duomenų apsauga
Duomenų perkėlimas vyksta pagal dokumentuotą susiejimą su įrašų skaičiais ir kontrolinėmis sumomis, o asmens duomenų kiekis testų rinkiniuose mažinamas. Saugojimo taisyklės keliauja kartu su duomenimis.
DI skaidrumas
Kai DI rengia dokumentacijos ar kodo juodraščius, rezultatas pažymimas, peržiūrimas ir versijuojamas kaip bet kuris kitas inžinerinis artefaktas.
Rodikliai
Ką matuotume
Šiuos rodiklius sutariame su Jumis įvertinimo metu ir stebime kiekvienai daliai, o ne tik visai programai.
Ką matuotume
Rodiklis
Kodėl tai svarbu
Kaip tai matuotume
01Pakeitimo įgyvendinimo trukmė
Kodėl tai svarbuAiškiausias ženklas, kad sistemą keisti darosi lengviau.
Kaip tai matuotumeLaikas nuo patvirtinto pakeitimo prašymo iki gamybinės aplinkos, atskirai senosioms ir modernizuotoms dalims.
02Sutikrinimo būsena
Kodėl tai svarbuParodo, ar naujoji paslauga ten, kur turi, tikrai elgiasi kaip senoji.
Kaip tai matuotumeLygiagretaus vykdymo metu sutampančių operacijų ir įrašų dalis bei neišspręsti skirtumai pagal priežastį.
03Taisyklių aprėptis
Kodėl tai svarbuNežinomos taisyklės yra pagrindinė bet kokio pakeitimo rizika.
Kaip tai matuotumeAtkurtų verslo taisyklių, kurias patikrino srities ekspertai ir kurias apima testai, dalis.
04Senųjų komponentų apimtis
Kodėl tai svarbuModernizavimas atsiperka tada, kai senieji komponentai iš tikrųjų išjungiami.
Kaip tai matuotumeIšjungtos funkcijos, kodo keliai, paketinės užduotys ir licencijos, stebimos kiekvienai daliai.
Kol nėra pradinio lygio, tikslinių reikšmių nenustatome.
Diegimas
Kaip diegtume
01 etapas
Įvertinimas
Portfelis, priklausomybės, sritys ir rizikos. Pasirenkame pirmąją dalį, kuri svarbi verslui, bet kurią galima atšaukti.
Etapo užbaigimo kriterijai
Patvirtinta tikslinė architektūra
Sutartas dalių eiliškumas
Suderinta prieiga prie testų ir duomenų
02 etapas
Pirmoji dalis
Taisyklių atkūrimas, apsaugos tinklas, fasadas ir viena perkurta funkcija, vykdoma lygiagrečiai su senąja sistema.
Etapo užbaigimo kriterijai
Sutikrinimo rezultatai neviršija sutarto nuokrypio
Verslo savininkas patvirtina perjungimą
Išbandytas grąžinimas
03 etapas
Dalis po dalies
Kitos funkcijos eina tuo pačiu keliu, kiekviena su savo lygiagrečiu vykdymu ir perjungimo sprendimu.
Etapo užbaigimo kriterijai
Kiekviena dalis sutikrinta ir perjungta
Žinios perduotos Jūsų komandai
04 etapas
Išjungimas
Senieji kodo keliai, paketinės užduotys ir duomenų saugyklos archyvuojami ir išjungiami.
Valstybės informacinės sistemos ir savivaldybių paslaugų sistemos, kuriose teisės aktų reikalavimai užkoduoti dešimtmečių senumo kode, o pakeitimai vis ateina.
Individualūs ERP plėtiniai ir gamyklų sistemos, perkeliami kartu su SAP S/4HANA diegimu.
Iliustracinis pavyzdys
Draudimo sutarčių sistema draudimo bendrovėje
Situacija
Draudikas sutartis, įmokas ir žalas tvarko dešimtmečių senumo sistemoje su individualiu kodu. Laukia keli reguliavimo ir produktų pakeitimai, o du kodą išmanantys programuotojai netrukus išeina į pensiją.
Sistema
Taisyklės atkuriamos ir patikrinamos kiekvienai produktų grupei. Fasadas pirmiausia nukreipia vienos produktų grupės įmokų skaičiavimą į naują paslaugą, kuri veikia lygiagrečiai su senąja sistema, kol rezultatai sutampa.
Žmogaus kontrolė
Kiekvienos produktų grupės ekspertai patikrina savo taisykles. Perjungimą patvirtina tos grupės verslo savininkas, o grąžinimas per fasadą išlieka galimas.
Ką matuotume
Sutikrinimo būsena kiekvienai produktų grupei, taisyklių aprėptis ir kito reguliavimo pakeitimo įgyvendinimo trukmė.
Lietuva
Modernizavimas pagal Lietuvos ir ES taisykles
Kai senojoje sistemoje užkoduoti Lietuvos teisės aktų reikalavimai, o pakeitimų eilė ilgėja, kiekvienas pakeitimas tampa rizika. Modernizavimą planuojame dalimis: kiekviena funkcija perkeliama atskirai, o senoji ir naujoji sistemos sutikrinamos prieš ką nors išjungiant.
Modernizuotos paslaugos perkeliamos į platformas, suprojektuotas atsižvelgiant į Kibernetinio saugumo įstatymo reikalavimus. Šio įstatymo pakeitimai, kuriais perkelta TIS 2 direktyva (NIS2), įsigaliojo 2024 m. spalio 18 d., o jo įgyvendinimą prižiūri Nacionalinis kibernetinio saugumo centras (NKSC). Europos Sąjungos Duomenų akto taisyklės dėl perėjimo tarp duomenų tvarkymo paslaugų yra priežastis duomenis nuo pirmosios dalies laikyti perkeliamus. Kai įrašuose yra asmens duomenų, perkėlimo susiejimai ir testiniai duomenys tvarkomi pagal BDAR.
Nes vienas perjungimas visą riziką sutelkia į vieną datą, o verslas metų metus laukia bet kokios naudos. Perkeliant funkciją po funkcijos, kiekvienos dalies tinkamumas patikrinamas lygiagrečiai vykdant, pradedama naudoti atskirai ir prireikus gali būti atšaukta.
02Ar DI gali išversti mūsų COBOL kodą į Java?
Vertimas eilutė po eilutės paprastai sukuria kodą, kurį keisti taip pat sunku kaip originalą. DI naudojame senajam kodui skaityti ir dokumentuoti bei taisyklių ir testų juodraščiams rengti, o naujas paslaugas projektuojame iš naujo. Kiekvieną atkurtą taisyklę prieš naudojant patikrina žmonės.
03Mūsų ekspertai išeina į pensiją. Kaip išsaugote jų žinias?
Per struktūruotas sesijas, kuriose ekspertai peržiūri atkurtas taisykles ir charakterizavimo testus. Jų žinios lieka dokumentacijoje ir testuose, kurie priklauso Jūsų komandai, o ne mūsų galvose.
04Ar tai taikoma ir SAP ECC?
Taip. Tie patys principai taikomi individualaus kodo tvarkymui ir perėjimui prie SAP S/4HANA: įvertinti, kas dar naudojama, atkurti ir ištestuoti tai, kas svarbu, ir judėti kontroliuojamais žingsniais.
05Kiek laiko senoji ir naujoji sistemos veikia greta?
Kol sutikrinimo rezultatai atitinka su verslo savininku sutartą nuokrypį, ir pakankamai ilgai, kad būtų apimti periodiniai procesai, pavyzdžiui, mėnesio ar metų uždarymas.