The Legacy: blessing or curse?

console

Néhány napja egy orvostanhallgató barátommal beszélgettem, amikor szóba került, hogy mennyire elavult informatikai eszközökkel (mind hardver, mind szoftver szempontjából) kell dolgozniuk a magyarországi kórházakban, például egy röntgen elkészítése után az orvosa a rendszerben nem látja a tényleges képet, csak egy pár soros fogalmazványt róla. A kérdése az volt: Miért nem lehet ezeket egyszerűen modernizálni? A legnyilvánvalóbb okon (pénzhiány) kívül rengeteg más indok is eszembe jutott első körben, így úgy döntöttem egy kicsit jobban beleásom magam a legacy (örökölt) rendszerek és alkalmazások világába, ennek eredményét fogom bemutatni ebben a cikkben. 

Mit is jelent az, hogy legacy system pontosan? A kifejezést olyan rendszerekre használják, amely valamely informatikai vagy üzleti szempont(ok)ból elavult tekinthető. Ian Sommerville szerint ezek a szempontok a rendszer komponensei lehetnek, amelyek a következők:

  • Hardver – elavult eszközök
  • Támogató szoftver – megszűnt szolgáltatók
  • Alkalmazás szoftver – elavult programnyelven íródott
  • Alkalmazásban keletkezett adatok – hiányos, inkonzisztens
  • Üzleti folyamatok – szoftver struktúrája, funkcionalitása korlátozza
  • Üzleti szabályok, szabályozások – szoftverben implicit módon megtalálható

legacy systems

Egy-egy ilyen rendszer nem keletkezik egyik pillanatról a másikra, hosszú évek fejlesztéseinek az eredménye. Tipikus jelenség egy új, jól működő alkalmazás esetén, hogy az üzlet által felmerülő igények megoldására újabb és újabb funkciókat fejlesztenek. Időközben ezek az igények, illetve szabályozások is változnak, amelyhez alkalmazkodni kell és olyan – előre nem tervezett – megoldásokat kell szállítani, amelyek gyökeresen eltérnek az eredeti igényektől és funkcionalitásoktól. Ezáltal szép lassan életre kel egy óriási csápokkal rendelkező polip, amely nélkülözhetetlen az üzlet számára, ennek ellenére rendkívül alacsony hatékonysággal működik.

Ezek alapján viszonylag könnyen meg tudjuk fogalmazni azokat a hátrányokat, ami egy ilyen rendszer használatával jár. A keletkező optimalizálatlan programkódok gyakran lassú futást okoznak, ezzel akadályozva a dolgozó munkáját. Az új funkciók következtében sokszor egy táblát különböző módokon kell felhasználni, egy adat többször is megjelenhet benne, ami inkonzisztenciát és hibás működést produkálhat. A szállítói függés következtében sokszor költséges a rendszer karbantartása, miközben nem biztos, hogy megfelelő szintű a támogatás. Egy régi rendszer egyáltalán nem biztos, hogy egy újabb hardverrel és/vagy operációs rendszerrel kompatibilis, ez biztonsági problémákat okozhat, illetve meghibásodás esetén körülményes és drága is lehet az új alkatrészek beszerzése. Összességében azt mondhatjuk, hogy ezek az indokok mind-mind afelé mutatnak, hogy minél tovább van működésben egy ilyen rendszer, annál költségesebb lesz a fenntartása, miközben egyre nehezebben képes megfelelni a környezet változó igényeinek.

Ugyanakkor elhamarkodott lenne kijelenteni, hogy márpedig most azonnal ki kell dobni az összes ilyen rendszert és ördögtől való, hogy létrejöttek valaha. Bizonyára mindenki látott már boltokban a kasszáknál elhelyezett pénztárgépeknél futó DOS-os időket idéző CRT monitoron futó monokróm alkalmazást, amely nyilvántartja és számolja a vásárlásunkat. Ezt is ki kellene vajon dobni? Nos, valószínűleg vannak újabb és jobb megoldások is, ugyanakkor ezek gyakran csak marginálisan tudnának jobb funkcionalitást nyújtani. Eközben pedig ez az alkalmazás nyilvánvaló kritikus az üzlet szempontjából, így amíg használható a jelenlegi nem éri meg a kockázatot, amely az átállásból fakad. Egy másik példa, amely mindenkinek ismerős lehet, amikor a háziorvosnál az asszisztens pillanatok alatt tölti a több tíz mezőből álló adatlap(ok)at, hiszen már pontosan tudja, hogy mi és hol található a rendszerben. Ugyan biztosan hasznos lenne néhány új funkció, de itt szintén nem érne számára annyit a plusz funkcionalitás, mint a jelenlegiek gyors használatából fakadó előnyök. Ezek alapján azt mondhatjuk, hogy bizonyos esetekben kifejezetten költséghatékony is lehet egy ilyen rendszer használata, így gondosan kell mérlegelni a döntés előtt.

Végezetül, tegyük fel, hogy gondos mérlegelés után, úgy döntünk, hogy vállalkozásunk új operációs rendszer használatára tér át, sajnos azonban egy alkalmazásunk nem kompatibilis ezzel. Nézzük meg milyen lehetőségeink vannak ebben az esetben, illetve miket tanácsolnak a szakemberek. Jellemzően három fő (természetesen lehetőségek tárháza végtelen, ezek viszonylag egyszerűbb példák) opciónk akadhat:

  • Virtualizáció – rövid- és középtávú megoldás
    • Ilyenkor gyakorlatilag teljesen képesek leszünk megtartani a korábbi alkalmazást (ugyan valamennyivel kevésbé hatékonyan), csupán megfelelő erőforrásokat kell kiosztanunk a virtuális gép számára.
  • Middleware használata – középtávú megoldás
    • A régi alkalmazásunkat interfészek segítségével összeköthetjük egy új alkalmazással. Idővel akár ez utóbbi teljesen át is veheti a szerepét, megfelelő fejlesztések mellett.
  • Rendszer cseréje – hosszútávú megoldás
    • Amennyiben van rá módunk, próbáljuk meg modulonként áttérni egyik rendszerről a másikra, ezzel könnyítve a dolgozók dolgát, hiszen nem kell mindent egyszerre újratanulni.
    • Kisebb rendszerek esetén működtessük egy ideig párhuzamosan mind a két rendszert, és fokozatosan sarkalljuk az alkalmazottakat az új alkalmazás használatára

Akármelyik megoldás mellett is döntünk a legfontosabb a szervezet támogatása: akár induljon a folyamat a vezetők felől, akár az alkalmazottak irányából. Előbbi esetben kiemelt fontosságú a szervezeti ellenállás csökkentése (a dolgozók gyakran elutasítóak egy új rendszerrel szemben, mivel az eltérően működik az általuk megszokottól), ezt legjobban a tervezési és megvalósítási fázisba történő bevonással, illetve megfelelő felhasználói oktatással (hogy a megértsék a döntések mögötti logikát, és lássák a valódi előnyeit az új megoldásnak). Utóbbi esetben pedig elengedhetetlen a menedzsment és a felső szintű vezetők támogatása, mivel ha nem kap elég erőforrást a projekt, akkor esetlegesen még több kárt okozunk a szervezet számára, mintha semmit nem is csináltunk volna.

Patrik

Reklámok

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s