Modernizējiet sistēmu, kurai neviens neuzdrošinās pieskarties, pa vienai funkcijai.
Gadu desmitiem uzkrāti biznesa noteikumi glabājas COBOL, PL/I, Oracle Forms un agrīnā Java un .NET kodā. Mēs šos noteikumus atjaunojam, izveidojam testu drošības tīklu un funkciju pēc funkcijas pārnesam aiz fasādes slāņa, ar paralēlu darbību un rezultātu saskaņošanu, pirms kaut kas tiek izslēgts.
Organizācijām, kuru kritiski svarīgās sistēmas darbojas vairākās valstīs un kuras nevar atļauties ne dīkstāvi, ne pazaudētus noteikumus.
Lietojumprogrammu portfelis tiek izvērtēts un mērķis saskaņots. Biznesa noteikumus no koda atjauno ar MI palīdzību, un cilvēki tos pārbauda. Raksturošanas testi veido drošības tīklu. Katru funkciju izveido no jauna aiz fasādes slāņa un darbina paralēli vecajai sistēmai; neatbilstības tiek izvērtētas un novērstas, pirms biznesa īpašnieks apstiprina pārslēgšanu un vecā daļa tiek izņemta no lietošanas.
Pirms un pēc
Kas mainās Jūsu darbā
Šodien
Ar sistēmu
Šodien
Šodien: Katra izmaiņa ir risks
Nelielas normatīvo aktu izmaiņas prasa mēnešus, jo neviens nevar paredzēt, ko vēl izmaiņa ietekmēs.
Ar sistēmu
Ar sistēmu: Izmaiņas ar testu nodrošinājumu
Raksturošanas testi fiksē, ko sistēma dara šodien, tāpēc katras izmaiņas ietekme ir redzama pirms laidiena.
Šodien
Šodien: Zināšanas aiziet pensijā
Cilvēki, kas saprot kodu, drīz dosies pensijā, un dokumentācija jau sen vairs neatbilst sistēmai.
Ar sistēmu
Ar sistēmu: Noteikumi pierakstīti un pārbaudīti
No koda atjaunotie biznesa noteikumi tiek aprakstīti vienkāršā valodā, un jomas eksperti tos apstiprina.
Šodien
Šodien: Vienreizējas nomaiņas plāni iestrēgst
Pilnīgas nomaiņas programmas sola vienu pārejas datumu, kas arvien pārvietojas, kamēr izmaksas aug.
Ar sistēmu
Ar sistēmu: Vērtība pa daļām
Funkcijas aiz fasādes slāņa tiek pārnestas pa vienai. Katra daļa sāk darboties atsevišķi, un to var atsaukt.
Šodien
Šodien: Dati ieslēgti vecās struktūrās
Jauni pakalpojumi un MI lietojumi nevar piekļūt datiem bez trausliem izvilkumiem un nakts pakešapstrādes.
Ar sistēmu
Ar sistēmu: Dati pieejami caur API
Pārnestās jomas piedāvā savus datus caur dokumentētām API, un tie tiek saskaņoti ar veco sistēmu, līdz tā tiek izņemta no lietošanas.
Darba plūsma
Kā darbojas darba plūsma
Pakāpeniskas aizstāšanas pieeja (strangler fig): jaunā sistēma aug ap veco, funkciju pēc funkcijas. Lielākā daļa īstā darba notiek ciklā starp paralēlo darbību un pārbūvi.
Ilustratīva darba plūsma
7 soļi · 3 cilvēka kontrolpunkti
Apzīmējumi
Sistēma
MI aģents
Cilvēks
Cilvēka kontrolpunkts
Izņēmumu ceļš
Mantoto sistēmu modernizācija: ilustratīva darba plūsma ar saskaņošanas ciklu
Lasīt diagrammu kā tekstu
Galvenais ceļš ved no portfeļa izvērtēšanas un biznesa noteikumu atjaunošanas caur raksturošanas testu drošības tīkla izveidi un vienas funkcijas pārbūvi aiz fasādes līdz vecās un jaunās sistēmas paralēlai darbībai un visbeidzot pārslēgšanai un vecās daļas izņemšanai no lietošanas.
Cilvēki apstiprina mērķa arhitektūru, pārbauda katru atjaunoto noteikumu un apstiprina katru pārslēgšanu: tie ir cilvēka kontrolpunkti.
Ja paralēlajā darbībā rezultāti atšķiras, daļa atstāj galveno ceļu, inženieri un jomas eksperti to izvērtē, un tā atgriežas pārbūves solī, līdz vecās un jaunās sistēmas rezultāti sakrīt.
01
1. solis: Portfeļa izvērtēšanaCilvēks
Lietojumprogrammu uzskaite, atkarību un datu plūsmu kartēšana un lēmums par katru lietojumprogrammu: izņemt, saglabāt, pārvietot, pārnest uz jaunu platformu, izveidot no jauna vai aizstāt. Jomas tiek kartētas, lai atrastu vietas, kur sistēmu var sadalīt.
Cilvēka kontrolpunkts
Jūsu arhitektūras padome apstiprina mērķa arhitektūru un daļu secību.
02
2. solis: Biznesa noteikumu atjaunošanaMI aģents
Koda analīze ar MI palīdzību nolasa COBOL, PL/I, JCL, Oracle Forms un vecāku Java vai .NET kodu un sagatavo dokumentācijas, izsaukumu grafu un biznesa noteikumu kataloga melnrakstus.
Cilvēka kontrolpunkts
Inženieri un jomas eksperti pārbauda katru izgūto noteikumu, pirms to izmanto kā specifikāciju. Nepārbaudīti noteikumi tiek attiecīgi atzīmēti.
03
3. solis: Drošības tīkla izveideSistēma
Raksturošanas testus ģenerē no anonimizētiem ekspluatācijas ievaddatiem un rezultātiem, lai pašreizējā uzvedība, ieskaitot tās īpatnības, būtu fiksēta, pirms kaut kas mainās.
04
4. solis: Daļas pārbūve aiz fasādesSistēma
Vecās sistēmas priekšā tiek novietots maršrutēšanas fasādes vai API slānis. Viena funkcija tiek izveidota no jauna kā jauns serviss, un tās dati tiek pārnesti un sinhronizēti.
05
5. solis: Paralēla darbība un saskaņošanaSistēma
Vecā un jaunā sistēma apstrādā tos pašus darījumus. Rezultāti un dati tiek salīdzināti automātiski, un katra atšķirība tiek parādīta pa noteikumiem un ierakstiem.
06
6. solis: Neatbilstību izvērtēšanaCilvēks
Inženieri un jomas eksperti izlemj, vai katra atšķirība ir kļūda jaunajā servisā, kļūda vecajā vai paredzēta izmaiņa, un nosūta daļu atpakaļ pārstrādei.
Izņēmumu ceļš: Rezultāti atšķiras· Atgriežas pie 4. soļa
07
7. solis: Pārslēgšana un izņemšana no lietošanasCilvēks
Funkcijas plūsma caur fasādi tiek pārvirzīta uz jauno servisu. Pēc stabila perioda vecais koda ceļš un tā dati tiek izņemti no lietošanas un arhivēti.
Cilvēka kontrolpunkts
Biznesa īpašnieks apstiprina katru pārslēgšanu, balstoties uz saskaņošanas rezultātiem. Atgriešana caur fasādi paliek pieejama līdz izņemšanai no lietošanas.
Komponenti
Ko mēs izveidotu
01
Portfeļa un atkarību karte
Uzskaite, saskarņu un datu plūsmu kartēšana un jomu modelis, kas parāda, kur sistēmu var sadalīt daļās.
Salesforce kā jaunā klientu apkalpošanas sistēmaPlatformaSalesforce
Integrācijas platforma un API vārteja
Mērķa mākonis vai datu centrs
Kontroles
Iebūvētās kontroles
Piekļuves robežas
Koda analīze notiek Jūsu kontrolētā vidē, un pirmkods netiek sūtīts pakalpojumiem, ko neesat apstiprinājuši. Testiem izmantotie ekspluatācijas dati tiek anonimizēti, pirms tie atstāj ekspluatācijas zonu.
Cilvēka pārbaude
Atjaunotos noteikumus inženieri un jomas eksperti pārbauda, pirms tie kļūst par specifikācijām. Katru pārslēgšanu biznesa īpašnieks apstiprina, balstoties uz saskaņošanas rezultātiem, un atgriešana paliek pieejama.
Auditējamība
Katrs noteikums katalogā ir izsekojams līdz kodam, no kura tas iegūts, un personai, kas to pārbaudīja. Saskaņošanas pārskati tiek glabāti kā pierādījumi katrai pārslēgšanai.
Datu aizsardzība
Datu migrācija notiek pēc dokumentētas atbilstības shēmas ar ierakstu skaitu un kontrolsummām, un personas dati testu kopās tiek samazināti līdz nepieciešamajam. Glabāšanas noteikumi pāriet līdzi datiem.
MI pārredzamība
Ja MI sagatavo dokumentāciju vai kodu, rezultāts tiek marķēts, pārskatīts un glabāts versiju kontrolē tāpat kā jebkurš cits inženiertehniskais artefakts.
Rādītāji
Ko mēs mērītu
Par šiem rādītājiem mēs ar Jums vienojamies izvērtēšanas laikā un sekojam tiem katrai daļai, ne tikai programmai kopumā.
Ko mēs mērītu
Rādītājs
Kāpēc tas ir svarīgi
Kā mēs to mērītu
01Izmaiņu izpildes laiks
Kāpēc tas ir svarīgiSkaidrākā pazīme, ka sistēmu kļūst vieglāk mainīt.
Kā mēs to mērītuLaiks no apstiprināta izmaiņu pieprasījuma līdz ekspluatācijai, vecajām un modernizētajām daļām.
02Saskaņošanas statuss
Kāpēc tas ir svarīgiParāda, vai jaunais serviss tiešām darbojas tāpat kā vecais tur, kur tam tā jādarbojas.
Kā mēs to mērītuTo darījumu un ierakstu daļa, kas paralēlās darbības laikā sakrīt, un atvērtās atšķirības pa cēloņiem.
03Noteikumu pārklājums
Kāpēc tas ir svarīgiNezināmi noteikumi ir galvenais risks jebkurā aizstāšanā.
Kā mēs to mērītuTo atjaunoto biznesa noteikumu daļa, ko pārbaudījuši jomas eksperti un aptver testi.
04Mantotās sistēmas apjoms
Kāpēc tas ir svarīgiModernizācija atmaksājas, kad vecie komponenti patiešām tiek izslēgti.
Kā mēs to mērītuNo lietošanas izņemtās funkcijas, koda ceļi, pakešuzdevumi un licences, katrai daļai.
Kamēr nav sākotnējā mērījuma, mērķus nenosakām.
Ieviešana
Kā mēs to ieviestu
01. posms
Izvērtēšana
Portfelis, atkarības, jomas un riski. Mēs izvēlamies pirmo daļu, kas ir svarīga biznesam, bet ko var atsaukt.
Posma noslēguma kritēriji
Mērķa arhitektūra apstiprināta
Daļu secība saskaņota
Piekļuve testiem un datiem nodrošināta
02. posms
Pirmā daļa
Noteikumu atjaunošana, drošības tīkls, fasāde un viena no jauna izveidota funkcija, kas darbojas paralēli vecajai sistēmai.
Posma noslēguma kritēriji
Saskaņošana saskaņotās pielaides robežās
Biznesa īpašnieks apstiprina pārslēgšanu
Atgriešana pārbaudīta
03. posms
Daļu pa daļai
Nākamās funkcijas iet to pašu ceļu, katra ar savu paralēlo darbību un lēmumu par pārslēgšanu.
Posma noslēguma kritēriji
Katra daļa saskaņota un pārslēgta
Zināšanas nodotas Jūsu komandai
04. posms
Izņemšana no lietošanas
Vecie koda ceļi, pakešuzdevumi un datu krātuves tiek arhivēti un izslēgti.
Pielāgoti ERP paplašinājumi un ražotņu sistēmas, kas tiek pārnestas kopā ar migrāciju uz SAP S/4HANA.
Ilustratīvs piemērs
Apdrošinātāja polišu sistēma trim Baltijas valstīm
Situācija
Apdrošinātāja polišu pamatsistēma aprēķina prēmijas tā darbībai Latvijā, Lietuvā un Igaunijā. Katrā valstī rindā gaida produktu un normatīvo aktu izmaiņas, un divi no izstrādātājiem, kas pārzina kodu, drīz dosies pensijā.
Sistēma
Noteikumus atjauno un pārbauda katrai valstij atsevišķi. Fasāde vispirms vienas valsts aprēķinus novirza uz jaunu servisu, kas darbojas paralēli vecajai sistēmai, līdz rezultāti sakrīt.
Cilvēka kontrole
Katras valsts jomas eksperti pārbauda savus noteikumus. Katras valsts biznesa īpašnieks apstiprina pārslēgšanu; atgriešana caur fasādi paliek pieejama.
Ko mēs mērītu
Saskaņošanas statuss katrai valstij, noteikumu pārklājums un izpildes laiks nākamajai normatīvo aktu izmaiņai.
Latvija
Modernizācija pēc Eiropas un Latvijas noteikumiem
Grupas ar uzņēmumiem Latvijā, Lietuvā un Igaunijā bieži izmanto vienu mantoto pamatsistēmu vairākām valstīm, un katrai valstij rindā gaida savas normatīvo aktu izmaiņas. Mēs modernizāciju plānojam tā, lai valstu varianti tiktu pārnesti pa vienai daļai, un vecā un jaunā sistēma tiktu saskaņotas katrai jurisdikcijai, pirms kaut kas tiek izslēgts.
Modernizētie servisi tiek izvietoti platformās, kas projektētas, ņemot vērā Nacionālās kiberdrošības likuma drošības pienākumus; šis likums, kas pārņem NIS2 direktīvu, ir spēkā kopš 2024. gada 1. septembra. Datu akta noteikumi par pakalpojumu sniedzēja maiņu ir iemesls jau no pirmās daļas saglabāt datus pārnesamus. Ja ierakstos ir personas dati, migrācijas atbilstības shēmas un testu dati atbilst VDAR.
Tāpēc, ka vienreizēja pāreja koncentrē visu risku vienā datumā, un bizness gadiem gaida jebkādu ieguvumu. Pārejot funkciju pēc funkcijas, katra daļa pierāda sevi paralēlā darbībā, sāk darboties atsevišķi un vajadzības gadījumā to var atsaukt.
02Vai MI var pārtulkot mūsu COBOL kodu uz Java?
Tulkošana rindu pa rindai parasti rada kodu, ko mainīt ir tikpat grūti kā oriģinālu. Mēs izmantojam MI, lai nolasītu un dokumentētu veco kodu un sagatavotu noteikumu un testu melnrakstus, un pēc tam pienācīgi projektējam jaunos servisus. Katru atjaunoto noteikumu pirms izmantošanas pārbauda cilvēki.
03Mūsu eksperti dodas pensijā. Kā Jūs saglabājat viņu zināšanas?
Ar strukturētām sesijām, kurās eksperti pārskata atjaunotos noteikumus un raksturošanas testus. Viņu zināšanas nonāk dokumentācijā un testos, kas paliek Jūsu komandai, nevis mūsu galvās.
04Vai tas attiecas arī uz SAP ECC?
Jā. Tie paši principi attiecas uz pielāgotā koda sakārtošanu un migrāciju uz SAP S/4HANA: izvērtēt, kas vēl tiek lietots, atjaunot un pārbaudīt svarīgāko un virzīties kontrolētos soļos.
05Cik ilgi vecā un jaunā sistēma darbojas paralēli?
Līdz saskaņošanas rezultāti atbilst ar biznesa īpašnieku saskaņotajai pielaidei, un pietiekami ilgi, lai aptvertu periodiskus procesus, piemēram, mēneša slēgšanu vai gada aprēķinus.
Pastāstiet, kura sistēma Jūs bremzē un kas no tās ir atkarīgs. Mēs ieteiksim pirmo daļu un to, kā to droši pārbaudīt, neatkarīgi no tā, kurām valstīm tā kalpo.