Kuidas valida rakenduste moderniseerimise partnerit

Sissejuhatus

Kuidas valida ettevõtte rakenduste moderniseerimise partner, kes aitab valmistuda pilve, andmete ja tehisintellekti kasutuselevõtuks

Ettevõtte moderniseerimine ei pea algama täieliku ümberkirjutamisega. Tõhusam lähenemisviis on sageli moderniseerida rakendusi, andmeid ja infrastruktuuri kontrollitud etappides, hoida kriitilised operatsioonid töös ning luua alus, mis toetab pilvepõhiseid teenuseid ja tulevasi tehisintellekti kasutusjuhtumeid.

Etapiviisiline moderniseerimistee ühendab rakenduste arhitektuuri, ettevõtte andmed ja tehisintellekti valmiduse.

Miks pilve-, andmete ja tehisintellekti valmisolek on üks moderniseerimisprobleem

Ettevõtted käsitlevad pilve migratsiooni, andmete moderniseerimist ja tehisintellekti kasutuselevõttu sageli eraldiseisvate projektidena. Praktikas on need omavahel tihedalt seotud. Töökoormuste pilve viimine võib parandada paindlikkust ja tegevuse tõhusust, kuid see üksi ei muuda rakenduse arendamist lihtsamaks. Andmed võivad endiselt olla lõksus hapra liidese taga, äriloogika võib endiselt asuda monoliitses süsteemis ning meeskonnad võivad endiselt karta muuta tootmissüsteemi, millega kaasneb tulude või regulatiivne risk.

Tehisintellekt tõstab latti veelgi kõrgemale. Mudelid ja agendid on kasulikud vaid siis, kui nad pääsevad usaldusväärsete liideste kaudu ligi täpsele, reguleeritud ja õigeaegsele teabele. Kui rakenduskihi muutmine on keeruline ja andmekiht on killustunud, muutub tehisintellekti algatus tavaliselt vaid pealiskaudseks eksperimendiks, mis tugineb samadele vanadele piirangutele. Seetõttu tuleb moderniseerimise probleemi vaadelda süsteemina: arhitektuur, infrastruktuur, andmevood, liidesed, rakendamise tavad ja operatiivne vastupidavus – need kõik mõjutavad seda, kas organisatsioon on tõepoolest valmis järgmiseks automatiseerimislaineks.

Miks täielik ümberkirjutamine on tavaliselt vale lähtepunkt

Täielik ümberkirjutamine kõlab ahvatlevalt, sest see lubab uut arhitektuuri ilma vanade kompromissideta. Väikese rakenduse puhul võib see olla mõistlik. Missioonikriitilise ettevõtteplatvormi puhul on tegelik süsteem aga tavaliselt suurem kui koodibaas. See hõlmab aastaid kogunenud ärieeskirju, erandeid, integratsioone, operatiivseid harjumusi, turvakontrolle, aruandluse sõltuvusi ja andmesuhteid, mida on raske korraga taastada.

Oht ei seisne ainult selles, et uue süsteemi valmimine võtab liiga kaua aega. Ümberkirjutamine võib sundida ettevõtet muutma liiga paljusid muutujaid korraga: rakenduse loogikat, andmeid, integratsioone, infrastruktuuri, kasutuselevõtu protsesse ja kasutajate käitumist. Mida kauem asendamisprogramm kestab, seda rohkem muutub vana platvorm, muutes funktsionaalsuse võrdväärsuse liikuvaks sihtmärgiks. Üleminek muutub seega suure surve all toimuva sündmuseks, mitte rutiinseks tehniliseks sammuks.

Järkjärguline programm muudab riskiprofiili. Meeskonnad saavad jätta olemasoleva platvormi kasutusse, moderniseerida esmalt need osad, millel on suurim äriline väärtus, testida uut arhitektuuri reaalse liikluse tingimustes ja luua tagasipöördumispunktid enne järgmise etapi algust. See ei kõrvalda keerukust, kuid muudab ühe pöördumatu panuse testitavate otsuste jada.

Kuidas näeb välja järkjärguline ettevõtte moderniseerimine

Kõige tugevamad moderniseerimisprogrammid algavad pigem tõenditest kui eelnevalt kindlaksmääratud sihtarhitektuurist. Enne monoliidi teenusteks jagamist või töökoormuste pilve viimist vajab meeskond praeguse süsteemi kaarti: millised komponendid on ärikriitilised, millised sõltuvused on haprad, millised integratsioonid peavad jääma võrgus ja millised platvormi osad põhjustavad tegelikult kulude, jõudluse või tarnimisega seotud probleeme.

Sellest lähtuvalt saab programmi järjestada hallatavate muudatuste järgi. Tüüpilised mustrid hõlmavad:

· Sõltuvuste kaardistamine ja moderniseerimise hindamine, et tuvastada komponendid, mis tekitavad kõige suuremat operatsioonilist või tarnimisriski.

· „Strangler“-mudeli järgi moderniseerimine, kus vana süsteemi ümber võetakse kasutusele uued komponendid ja liiklus suunatakse järk-järgult nende poole.

· Paralleelne töö, kus vanad ja uued rakendused töötavad koos, kuni käitumine, jõudlus ja andmete järjepidevus on tõestatud.

· API-de ja sündmuste toetamine, et avalikustada funktsionaalsust ja andmeid ilma, et iga kasutaja peaks vanade süsteemide sisemist toimimist mõistma.

· Eraldi andmete migratsiooni töövoog andmete kooskõlastamiseks, valideerimiseks ja ajalooliste andmete ülekandmiseks, selle asemel et käsitleda andmeid lõpliku üleminekuülesandena.

· Etapiviisiline üleminek, millel on igas etapis selged tagasipööramise tingimused, jälgitavus ja tootmiskeskkonnas valideerimine.

See järjekord on oluline, sest mitte iga vana süsteemi osa ei vaja ümberkirjutamist. Mõned komponendid võivad jääda stabiilseks aastateks, kui kõige problemaatilisemad sõltuvused on eemaldatud. Hea moderniseerimine on valikuline: see muudab seda, mis takistab äritegevust, ja säilitab seda, mis veel toimib.

Rakenduskihi moderniseerimine pilvevalmiduse saavutamiseks

Pilvevalmidust kirjeldatakse sageli infrastruktuuri küsimusena, kuid tavaliselt määrab just rakenduse arhitektuur, kas pilv loob tegelikku väärtust. Lihtsalt tihedalt seotud monoliidi ümberpaigutamine võib jätta organisatsioonile samad väljalaske-pudelikaelad ja rikkevaldkonnad teises andmekeskuses.

Kasulikum eesmärk on luua piirid, mis võimaldavad meeskondadel süsteemi osi iseseisvalt kasutusele võtta, skaleerida ja taastada. Sõltuvalt rakendusest võib see tähendada monoliidi modulaarseks muutmist, piiratud arvu teenuste eraldamist, töökoormuste konteinerimist, sobivate komponentide viimist hallatavatesse pilveteenustesse ja süsteemi ümbritseva tarneprotsessi parandamist. CI/CD, automatiseeritud testimine, jälgitavus ja korratavad infrastruktuurimuudatused on sama olulised kui hostingumudel ise.

Eesmärgiks ei peaks olema mikroteenused iseenesest. Eesmärgiks on platvorm, mida on lihtsam muuta, lihtsam käitada ja turvalisem arendada, samal ajal kui äri jätkab töötamist.

Andmete moderniseerimine enne tehisintellekti lisamist

Ettevõtte tehisintellekti programmid toovad sageli esile andmeprobleeme, mida varem taluti. Rakendusel võib olla piisavalt teavet tänapäevaste töövoogude toetamiseks, kuid see võib siiski olla kehv allikas analüütika, automatiseerimise või masinõppe jaoks. Andmed võivad olla dubleeritud erinevates andmebaasides, peidetud sisemiste API-de taha, uuendatud ebajärjekindla ajakava järgi või esitatud erinevates süsteemides erinevalt.

Seetõttu tuleks moderniseerimisel käsitleda andmetele juurdepääsu ja andmete kvaliteeti esmatähtsate arhitektuuriliste küsimustena. See võib hõlmata ärisündmuste avalikustamist, usaldusväärsete API-de määratlemist, operatiivandmete eraldamist analüütilistest töökoormustest, ajalooliste andmete kooskõlastamist ning reguleeritud andmevoogude loomist, mis säilitavad andmete päritolu ja valideerimise. Konkreetne tehnoloogia võib varieeruda, kuid eesmärk on ühesugune: muuta olulised ettevõtte andmed kättesaadavaks, usaldusväärseks ja kasutatavaks ka väljaspool rakendust, mis need algselt loonud on.

Kui see alus on olemas, muutub tehisintellekt palju praktilisemaks. Mudeleid saab ühendada stabiilse teabekihiga, selle asemel et kaevata andmeid ebastabiilsetelt ekraanidelt või sõltuda ühekordsetest eksportidest. Meeskonnad saavad järk-järgult lisada andmete hankimise, automatiseerimise, ennustamise või agendipõhiseid töövooge, sest aluseks olev rakendus ja andmearhitektuur suudavad neid toetada.

Mida otsida rakenduste moderniseerimise partnerilt

Erinevus moderniseerimise tarnija ja moderniseerimise partneri vahel ilmneb küsimustes, mida nad esitavad enne tehnoloogia pakkumist. Tõsine partner peaks suutma selgitada, mis võib jääda muutumatuks, mida tuleb esimesena muuta, kuidas äri jätkab tegevust ülemineku ajal ja kuidas iga etapp tootmiskeskkonnas valideeritakse.

Kasulikud hindamiskriteeriumid hõlmavad kogemust kriitilise tähtsusega süsteemidega, etapiviisilist rakendamist, pilvearhitektuuri, andmete migratsiooni, integratsioonimahukaid keskkondi, tagasipööramise planeerimist ja pikaajalist operatiivset vastutust. Meeskond peaks suutma mugavalt töötada olemasoleva, ebatäiusliku süsteemi raames, selle asemel et nõuda, et edasiminek on võimalik alles pärast täielikku ümberehitamist.

Näiteks käsitleb Zoolatech vanade süsteemide moderniseerimist etapiviisilise ümberkujundamisena, mitte ühekordse ümberkirjutamisena. Oluline oskus ei seisne lihtsalt töökoormuste uude keskkonda viimises, vaid arhitektuuri moderniseerimise, pilvetehnoloogia, andmete migratsiooni ja kontrollitud tootmisse ülemineku ühendamises, hoides samal ajal veebis need äri osad, mida ei saa peatada.

Ettevõtte näide: vana MES-süsteemi üleminek pilvepõhistele mikroteenustele

Hea näide on reguleeritud keskkonnas tegutseva ettevõtte tootmise juhtimissüsteemi moderniseerimisprogramm. Lähtpunktiks oli kümne aasta vanune monoliitne platvorm. Kogu süsteemi korraga asendamine oleks koondanud liiga palju tehnilisi ja operatiivseid riske ühte programmi, seega keskenduti töös üleminekule pilvepõhisele mikroteenuste arhitektuurile, säilitades samal ajal olemasoleva ettevõtte toote tegeliku olukorra.

Muutus hõlmas Java ja Spring Bootiga loodud kaasaegseid rakendusteenuseid, kasutuselevõttu AWS-is, Kubernetes-põhist pilveinfrastruktuuri ning andmete migratsiooni osana laiemast arhitektuurimuutusest. Selle näite tähtsus ei seisne konkreetses tehnoloogilises lahenduses, vaid järjekorras: rakenduse arhitektuuri, pilveinfrastruktuuri ja andmete ülekandmist käsitleti omavahel seotud töövoogudena, mitte eraldiseisvate migratsioonidena.

MasterControl MESi avalik ümberkujundamine illustreerib just seda tüüpi ettevõtte moderniseerimist, mis on oluline pilve, andmete ja tulevase tehisintellekti valmisoleku seisukohalt: tõeline tootmisplatvorm areneb arhitektuuri muutmise ja andmete migreerimise kaudu, ilma et probleemi taandataks lihtsaks infrastruktuuri ümberpaigutamiseks.

Parem küsimus kui „Kas peaksime selle ümber kirjutama?“

Ettevõtete juhid peavad harva tegema valikut kahe äärmuse vahel: „säilitada vana süsteem igavesti“ või „asendada kõik kohe“. Tulemuslikum küsimus on: millised piirangud takistavad rakendust muutumast lihtsamini hallatavaks, integreeritavaks ja usaldusväärse andmeallikana kasutatavaks?

See küsimus viib moderniseerimise tegevuskavani, mida saab mõõta ärilistes mõistes. Habras integratsioon on võimalik eraldada. Kõrge kuluga teenust on võimalik ümber kujundada. Andmete pudelikaela on võimalik rakendusest eraldada. Väljalaskeprotsessi on võimalik automatiseerida. Monoliiti on võimalik järk-järgult vähendada, selle asemel et käsitleda seda üheainsa lammutusprojektina.

Pilve-, andmete ja tehisintellekti valmisolek ei ole eesmärgid, milleni jõutakse ühe tehnoloogia vahetamisega. Need on tulemused arhitektuurist, mis suudab ohutult areneda. Parim moderniseerimispartner ei ole seetõttu ettevõte, mis lubab kõige kiiremat ümberkirjutamist. See on ettevõte, mis suudab kindlaks teha väikseima muutuste jada, mis vähendab riski, hoiab kriitilised toimingud käigus ja loob ruumi järgmise põlvkonna ettevõttevõimekustele.