Starý systém: čo zachovať a čo meniť ako prvé

Pomenujte dôvod zmeny

Systém môže byť starší a stále spoľahlivo vykonávať dôležitú úlohu. Samotný vek nestačí na rozhodnutie o výmene. Dôvodom môže byť náročné zavádzanie zmien, chýbajúce integrácie, nepodporované technológie alebo pracovný postup, ktorý sa od návrhu aplikácie zmenil.

Tieto problémy potrebujú odlišné riešenia. Nové používateľské rozhranie nemusí odstrániť chyby v dátach. Prepis aplikácie nemusí vyriešiť nejasné pravidlá schvaľovania. Pri úvodnom posúdení oddeľte procesný, dátový a technický problém a určte, ako zistíte, že sa situácia zlepšila.

Zmapujte aj nenápadné závislosti

Aplikácia býva prepojená s exportmi, naplánovanými úlohami a návykmi tímu, ktoré dokumentácia nezachytáva. Rozhovor s ľuďmi z prevádzky môže odhaliť report, bez ktorého sa neuzavrie mesiac, alebo súbor, ktorý spracúva ďalšie oddelenie. Pri výmene ho treba zachovať alebo dohodnúť náhradu.

Základom je inventár funkcií, rozhraní, údajov a prístupov. Overte tiež licencie a dostupnosť zdrojového kódu. Výsledkom úvodného kroku môže byť zoznam chýbajúcich podkladov. Aj ten pomáha pripraviť realistický rozsah a odhad.

Vyberte oddeliteľnú časť

Postupná náhrada má zmysel, ak možno vybranú funkciu oddeliť a smerovať na nové riešenie, zatiaľ čo zvyšok ostáva v pôvodnom systéme. Taký prístup potrebuje jasnú hranicu a spôsob zdieľania údajov. Nie každý systém ho umožní bez zásadných zásahov.

Ako prvý krok môže poslúžiť portál, integračná vrstva alebo samostatný modul. Výber závisí od toho, ktorá časť prinesie užitočný výsledok a zároveň pomôže overiť technický postup. Rozsah nemá byť taký široký, aby sa z prvého kroku stala skrytá kompletná výmena.

Migrácia potrebuje skúšku a návratový postup

Prenos údajov treba vyskúšať na vhodnej kópii a porovnať výsledok. Sledujte väzby medzi záznamami, chýbajúce hodnoty aj rozdiely medzi starým a novým významom polí. Úspešný import bez týchto kontrol ešte nepotvrdzuje, že tím môže pokračovať v práci.

Pri kritickej zmene určte okno nasadenia, rozhodujúcu osobu a podmienky návratu. Myslite na údaje, ktoré môžu vzniknúť počas zmeny. Návratový plán musí popísať ich osud; samotné obnovenie staršej zálohy môže znamenať stratu nových záznamov.

Ukážkové rozhodnutie: nový partnerský portál

Firma môže potrebovať portál pre partnerov, pričom interný systém ďalej spracúva objednávky. Jedna možnosť je rozšíriť pôvodnú aplikáciu. Ďalšia je nový portál s prepojením. Porovnanie má zahrnúť dostupnosť rozhraní, správu účtov, aktuálnosť údajov aj zodpovednosť za opravu prenosu.

Ak integračná hranica funguje, portál môže byť samostatnou etapou. Ak však údaje nemožno spoľahlivo oddeliť, nový frontend iba prekryje pôvodný problém. Je to ilustračná situácia; vhodnú cestu určí až posúdenie konkrétnej aplikácie a procesov.

Dohodnite život po prvej zmene

Nový modul môže určitý čas fungovať vedľa pôvodného systému. Toto obdobie potrebuje vlastnú prevádzkovú zodpovednosť: kto sleduje prepojenie, opravuje chyby a rozhoduje o ďalšej náhrade. Dočasná architektúra sa bez plánu ľahko stane trvalou.

Pri plánovaní porovnajte aj cenu súbežnej prevádzky a schopnosť tímu riešenie udržiavať. Postupná zmena má byť vedomé rozhodnutie s konkrétnymi etapami. Po každej možno prehodnotiť ďalší rozsah podľa výsledku a nových informácií o systéme.

Od témy ku konkrétnemu riešeniu.

Súvisiaca realizácia: FaxCopy a.s.