Modernizimi i softuerit të trashëguar: mirëmbajtje, rindërtim apo zëvendësim?

Vetëm mosha nuk është arsye për ta zëvendësuar softuerin

Një aplikacion dymbëdhjetëvjeçar mund t'i përpunojë porositë në mënyrë të besueshme, ndërsa një dyvjeçar mund të jetë tashmë i vështirë për t'u ndryshuar. Modernizimi bëhet i rëndësishëm kur ndryshimet bllokojnë shërbime të reja, një platformë humbet mbështetjen ose proceset thelbësore varen nga njohuritë e një personi të vetëm. Softueri i konsoliduar përmban gjithashtu përvojë operacionale: çmime të veçanta, regjistrime korrigjuese dhe përjashtime të pazakonta mund të ekzistojnë vetëm në kodin e tij. Rindërtimi vetëm i ndërfaqes dhe rrjedhave standarde të punës mund t'i humbasë këto rregulla.

Inventarizoni proceset, përdoruesit, të dhënat, integrimet dhe përgjegjësit e çdo aplikacioni të rëndësishëm. Regjistroni kohëzgjatjen e ndryshimeve të fundit, transferimet manuale javore, versionet e mbështetura dhe rrugët e testuara të rikuperimit. Një import mujor që kërkon dy ditë rakordim sepse ID-të e klientëve ndryshojnë midis tri sistemeve mund të ketë nevojë për një ndërfaqe të qëndrueshme. Një aplikacion thelbësor në një sistem operativ pa mbështetje kërkon një vendim tjetër: migrim platforme, zëvendësim ose një zgjidhje kalimtare me afat të kufizuar.

Zgjidhni strategjinë që trajton pengesën reale

Strategjitë mund të ndryshojnë sipas sistemit dhe funksionit. Microsoft dallon qasje migrimi dhe vlerëson ngarkesat e punës së bashku me varësitë e tyre. Kalimi në cloud është vendim infrastrukture, jo provë se vetë aplikacioni është modernizuar.

• Mirëmbani dhe stabilizoni: funksionalitet biznesi i përshtatshëm, përbërës të mbështetur dhe pak nevojë për ndryshim; vazhdoni të vëzhgoni varësitë dhe zëvendësimin e ardhshëm.
• Ndryshoni hostimin: kaloni në një hostim tjetër ose zëvendësoni harduerin e vjetër; struktura e aplikacionit dhe shumë probleme operacionale mbeten.
• Ndryshoni platformën: kaloni mjedisin e ekzekutimit ose bazën e të dhënave në një bazë të mbështetur duke ruajtur logjikën kryesore të biznesit; përputhshmëria kërkon sërish testim.
• Ristrukturim i synuar i kodit: përmirësoni dobësi të kufizuara që ndryshohen shpesh, duke i lënë funksionet e tjera në punë.
• Zëvendësoni ose hiqni nga përdorimi: përdorni një produkt standard më të përshtatshëm ose hiqni një funksion të panevojshëm, pasi të zgjidhni migrimin, arkivat dhe proceset që varen prej tij.

Zëvendësoni gradualisht, me një fund për funksionimin paralel

Në modelin Strangler Fig, përbërësit e rinj marrin gradualisht përgjegjësi të kufizuara dhe një ndërmjetës i drejton kërkesat te aplikacioni përkatës. Udhëzimi i Microsoft përshkruan edhe kostot e kalimit, të dhënat e përbashkëta dhe rrezikun që ndërmjetësi të bëhet pengesë performance. Modeli nuk i përshtatet çdo sistemi të vogël ose një sistemi që së shpejti do të zëvendësohet plotësisht.

Për shembull, ndani pamjen e klientëve nga një sistem porosish i konsoliduar, ndërsa ofertat dhe faturat mbeten në aplikacionin origjinal. Para projektit pilot, vendosni cili sistem mund t'i përditësojë adresat dhe si përhapen ndryshimet. Dy rrugë shkrimi të pavarura krijojnë regjistrime kundërthënëse. Një rrjedhë të dhënash e gjurmueshme është një arritje e dobishme; vetëm një ekran i ri nuk është.

Çdo zgjidhje kalimtare ka nevojë për një kusht daljeje nga përdorimi. Përndryshe biznesi paguan pafundësisht për të dyja platformat dhe lidhjen mes tyre. Një projekt pilot mund të kërkojë rakordimin e të gjithë klientëve aktivë, përdorimin e pamjes së re nga ekipi i biznesit dhe konfirmimin se asnjë proces leximi në prodhim nuk ka më nevojë për ndërfaqen e vjetër.

Llogaritni së bashku zhvillimin, kalimin dhe funksionimin

Krahasoni vazhdimin e stabilizuar të funksionimit dhe modernizimin e propozuar për të njëjtën periudhë. Përfshini te të dyja hostimin, licencat, mbështetjen dhe punën e pritshme për ndryshime. Migrimi shton analizën, pastrimin e të dhënave, funksionimin paralel, trajnimin dhe heqjen nga përdorimi. Paraqitini kursimet e pasigurta si intervale.

Një llogaritje ilustruese: dhjetë orë rakordim të shmangura realisht çdo muaj, me një tarifë të brendshme €70 për orë, japin €8,400 në vit para kostove shtesë të funksionimit dhe mirëmbajtjes. Nëse koha e kursyer shndërrohet në shpenzim të reduktuar apo kapacitet të disponueshëm varet nga biznesi. Ndërprerjet e supozuara si të shmangura nuk janë kursime shtesë të garantuara.

Një import të dhënash përfundon vetëm pas rakordimit të biznesit

Numrat e barabartë të regjistrimeve nuk provojnë migrim të saktë. Kontrolloni ID-të e klientëve, totalet, lidhjet, kodimet e karaktereve, zonat kohore dhe përjashtimet historike. Mblidhni raste përfaqësuese para rindërtimit: një porosi normale, anulim të pjesshëm, notë krediti dhe kontakt të ndryshuar në mënyrë prapavepruese. Krahasoni rezultatet e pritshme në të dy sistemet dhe lëreni biznesin të zgjidhë mospërputhjet.

Përcaktoni si trajtohen shkrimet e reja gjatë kalimit përfundimtar. Pasi të dhënat e prodhimit të kenë ndryshuar në aplikacionin e ri, thjesht rinisja e serverit të vjetër mund të mos mjaftojë. Rruga e kthimit kërkon rakordim, një dritare kohore të dakordësuar ose një korrigjim të paracaktuar për të ecur përpara.

Javët e para duhet të pakësojnë pasigurinë

Një fazë hulumtimi me kufij të qartë duhet të prodhojë një hartë të rrjedhave të rëndësishme të të dhënave, versioneve të mbështetura të platformës dhe rasteve përfaqësuese të biznesit. Intervistoni së bashku përdoruesit, ekipin operacional dhe zhvilluesit. Veprimtari të rralla si mbyllja e vitit, anulimet, eksportet dhe qasja e zëvendësuesve mund të mos shfaqen gjatë një periudhe të shkurtër vëzhgimi, por mund të jenë kritike.

Drejtojeni një hetim të vogël teknik te e panjohura më e madhe. Verifikoni një eksport të pasigurt para ndërtimit të ndërfaqes së re; siguroni herët qasjen te një integrim i palës së tretë nëse ai përcakton afatin. Një afat dhe një rezultat i shkruar pengojnë vazhdimin e analizës pa vendimmarrje.

Jepini çdo etape një përfitim, kritere pranimi dhe kusht ndalimi

Zgjidhni një proces biznesi nga skaji në skaj për etapën e parë, si shfaqja e porosive ekzistuese për një grup të kufizuar përdoruesish. Pranimi përcakton të dhënat e pritshme, kohën e përgjigjes nën ngarkesën e dakordësuar, rastet e lejeve dhe shqyrtuesin nga biznesi. Gabimet dhe dallimet e të dhënave duhet të jenë të vëzhgueshme para një publikimi më të gjerë.

Nëse importet e përsëritura të provës vazhdojnë të prodhojnë dallime të pashpjeguara, shtyjeni kalimin në prodhim dhe hetoni. Paratë e shpenzuara tashmë nuk janë provë se të dhënat janë gati. Pas etapës, vendosni nëse do të shtoni funksionin tjetër, të përshtatni strategjinë ose të ruani rezultatin e ndërmjetëm të qëndrueshëm.

Trajtojeni heqjen nga përdorimi si një paketë pune më vete

Pas kalimit, eksportet e natës, llogaritë ose mjetet e raportimit mund të vazhdojnë të përdorin bazën e vjetër të të dhënave. Identifikoni dhe migroni këto procese leximi dhe shkrimi. Të dhënat historike duhet të mbeten të gjetshme në një format të përdorshëm të dakordësuar; një eksport skedarësh i palexueshëm nuk është arkiv i dobishëm.

Mbyllni qasjet e vjetra, licencat, proceset e kopjeve rezervë, paralajmërimet dhe dokumentacionin operacional. Koordinoni përfundimin e kontratave dhe fundin e qasjes së nevojshme që heqja nga përdorimi të mos shkaktojë një ndërprerje tjetër. Vetëm pastaj krahasoni kursimet e pritshme me funksionimin real dhe dokumentoni dallimet e mbetura dhe shkaqet e tyre.