Przestarzałe systemy stają się zagrożeniem dla polskich firm

Badanie przeprowadzone wśród polskich organizacji pokazuje, że systemy legacy stają się w nich istotnym problemem, który niedługo dojrzeje. W perspektywie kilku lat przestarzałe systemy w przypadk niektórych przedsiębiorstw będą decydować o ich być albo nie być.

Nie ma chyba dobrego tłumaczenia angielskiego terminu „system legacy” na język polski. Najczęściej tłumaczy się ten zwrot jako system odziedziczony lub system zastany, co niejako z automatu rodzi skojarzenie, że jest to system mający za sobą długi okres użytkowania. Czy prawdą jest jednak, że każdy „stary” (jeżeli chodzi o wiek) system jest z definicji systemem legacy? I czy system, który został wdrożony „zaledwie” cztery lata czy pięć lat temu nie może być „legacy”?

Czym są systemy legacy

Okazuje się, że sytuacja nie jest taka prosta. W inżynierii oprogramowania za system legacy uznaje się system, który obarczony jest wysokim długiem technologicznym, co powoduje, że jego używanie stanowi istotne ryzyko dla działania operacyjnego firmy lub jest ograniczeniem dla jej rozwoju bądź ekspansji, ale jednocześnie wspiera on szereg istotnych procesów czy obszarów biznesowych tej organizacji (nie da się go więc „tak po prostu” wyłączyć lub w prosty sposób zastąpić innym systemem).

Zobacz również:

Dla dalszej dyskusji dotyczącej systemów legacy istotne jest także jednoznaczne zdefiniowanie terminu „dług technologiczny”. Rozumiem to pojęcie szeroko – tj. jako każde podejście zastosowane (świadomie lub nie) przy budowie systemu informatycznego, które utrudniać będzie jego przyszły rozwój czy dalsze zmiany. Czyli dług technologiczny powstaje, kiedy stosowane są złe praktyki kodowania czy dokumentowania kodu (w szczególności oznacza to jakikolwiek brak dokumentacji lub jej szczątkową postać), ale także wówczas, kiedy następuje zaniechanie przechodzenia na najnowsze wersje narzędzi czy bibliotek programistycznych oraz trwanie przy starych wersjach systemów operacyjnych, baz danych, serwerów aplikacyjnych itp. Szczególnym rodzajem długu technologicznego jest dług związany z używaniem bardzo starych urządzeń (np. serwerów, macierzy itp.). Według klasyka inżynierii oprogramowania Edwarda Yourdona źródłem długu technologicznego może być także brak projektu systemu, w rozumieniu braku całościowej koncepcji jego rozwoju, powodujący ustawiczne przerabianie oprogramowania w takt pojawiania się nowych wymagań.

Jakie są konsekwencje przyjęcia powyższej definicji legacy? Okazuje się, że stosunkowo nowy system informatyczny (mający trzy czy cztery lata, co w przypadku wdrożeń systemów Enterprise oznacza często dopiero wyjście z wieku niemowlęcego), który wspiera kluczowe procesy biznesowe, może zostać już zaliczony do klasy systemów zastanych. Jest on bowiem obarczony bardzo dużym długiem technologicznym – nie ma praktycznie żadnej dokumentacji, sposób kodowania jest daleki od kanonu zasad dobrego programowania, stosuje stary stos technologiczny i ma w sobie zaszyte na skutek chaotycznego rozwoju mnóstwo zbytecznej – z punktu widzenia kluczowego jego zakresu zastosowania – funkcjonalności. Jednocześnie wspiera w istotnym stopniu procesy sprzedażowe firmy (przechodzi przez niego 85–90% całkowitej sprzedaży).

Jak sobie radzić z przestarzałymi rozwiązaniami

W ramce przedstawiono listę 14 kryteriów, które pozwalają stwierdzić, jak bardzo poszczególne systemy w firmie są „zastane”. Można przyjąć, że co najmniej osiem do dziewięciu odpowiedzi „tak” przy konkretnym systemie pozwala stwierdzić, że powinien stać się on źródłem szczególnej troski z perspektywy szefa IT.

Najczęstsze symptomy i problemy związane z posiadaniem systemu legacy

Jak sprawdzić (poza intuicją), czy mój system jest systemem legacy czyli najczęstsze symptomy i problemy związane z posiadaniem systemu legacy:

1. System został stworzony kilka(naście) lat temu.

2. Jego rozwój (zakres funkcjonalny) dryfował w różnych kierunkach.

3. Obrósł „milionem” podsystemików, zintegrowanych z nim na „milion” sposobów.

4. Nie odpowiada aktualnym, ciągle zmieniającym się potrzebom biznesu.

5. Jego architektura nie odpowiada dzisiejszym standardom (nie jest zgodna z uznanymi wzorcami projektowymi).

6. Producent nie zapewnia już jego dalszego wsparcia (lub nie wspiera sprzętu, na którym ten system jest postawiony – w szczególności oznacza to szukanie na wyprzedażach i – to nie przesada, tylko przypadek znany autorowi – giełdach staroci części zapasowych do urządzeń).

7. Wykazuje liczne podatności bezpieczeństwa.

8. Wersje bibliotek czy języków programowania, za których pomocą został stworzony nie są już wspierane ani rozwijane (lub system nie został przeportowany na ich nowe wersje).

9. Budowano go z wykorzystaniem wielu różnych styli/sposobów kodowania.

10. Część linii kodu przestała być już używana, ale nikt nie wie, które są to linie.

11. Jego dokumentacja jest cząstkowa bądź nieaktualna, a wiedza o jego działaniu jest w głowach.

12. Bardzo trudno poddaje się automatyzacji procesu wytwórczego (np. automatyzacji testów).

13. Są trudności z pozyskaniem kadry znającej zastosowaną do budowy systemu technologię czy język programowania bądź framework programistyczny.

14. Czas wprowadzania zmian (TTM) w systemie jest niezwykle długi (przestał być akceptowalny dla biznesu).

Jeżeli firma dorobiła się już systemów legacy, możliwe są różne strategie postępowania (dostępny wachlarz możliwości przedstawia ramka 2). Przy czym biznesu ze szczebla operacyjnego raczej nie interesuje problem systemów legacy (i to zainteresowanie będzie jeszcze malało) – czasami wręcz jest z nich zadowolony (bo znane, lubiane, wygrzane, „pan Kazio”, lokalny programista, jest na miejscu i wszystko zmieni). A poziom strategiczny biznesu woli inwestować w nowe, ciekawe, medialne rzeczy (legacy to wstyd).

Strategie postępowania z systemami legacy

1. Ignorowanie (niezauważanie) faktu, że występują systemy legacy.

2. Świadome pozostawienie systemu legacy i lekka jego konserwacja (np. wzmocnienie kadrowe…).

3. Reinżynieria starego systemu (od refaktoryzacji kodu do „dotknięcia” architektury).

4. Rozczłonkowanie starego systemu na moduły i przeniesienie części nich do nowego systemu (stary częściowo pozostaje).

5. Zinterfejsowanie starego systemu (wystawienie API).

6. Uruchomienie dużego przedsięwzięcia wymiany starego systemu i zastąpienie go nowym system budowanym od podstaw (system dedykowany).

7. Uruchomienie dużego przedsięwzięcia wymiany starego systemu i zastąpienie go nowym system z półki (COTS) – on premise, cloud.

8. Uruchomienie dużego przedsięwzięcia budowy nowego systemu i pozostawienie starego systemu obok (równolegle do nowego), przy czym stary system odgrywa (coraz) mniejszą rolę.

9. Zastosowanie rozwiązania RPA (Robotic Process Automation) i pozostawienie starych systemów.

10. Outsourcing systemów legacy (przeniesienie ryzyka związanego ze zmianami i utrzymaniem systemu legacy na firmę outsourcingową).

Systemy legacy w Polsce A.D. 2017

O ile najnowszymi wdrożeniami czy śmiałymi programami transformacyjnymi polskie organizacje bardzo chętnie się chwalą, o tyle zagadnienie systemów legacy zawsze pozostaje w cieniu. Na przełomie 2016/2017 r. w ramach Zakładu Zarządzania Informatyką będącego częścią Instytutu Informatyki i Gospodarki Cyfrowej SGH uruchomiłem długofalowe przedsięwzięcie SPARTA (czyli Strategie Przedsiębiorstw w świecie Automatyzacji i RoboTyzAcji biznesu). Jeden z wątków tego przedsięwzięcia dotyczy problemu systemów legacy.

Na pierwszy rzut oka jest to temat odległy od automatyzacji i robotyzacji biznesu. W praktyce okazuje się jednak, że takie systemy stanowią w wielu przypadkach wąskie gardo w procesie cyfrowej transformacji firm i zastosowania na szeroką skalę pełnej automatyzacji procesów. Aby zbadać, jak wygląda faktycznie ta sytuacja w Polsce w okresie maj–czerwiec 2017 r. zorganizowano dwa seminaria na SGH, podczas których przedstawiciele kilkunastu przedsiębiorstw z różnych branż (m.in. telekomunikacja, banki, ubezpieczyciele, motoryzacja, sektor zdrowia) omówili swoje zmagania z systemami legacy. Dodatkowo razem z magazynem „Computerworld” zrealizowane zostały poglądowe badania ankietowe w polskich organizacjach (wzięły w nim udział jednostki z: administracji publicznej, sektora utilities, telekomunikacji, banków, firm ubezpieczeniowych, przemysłu, sektora zdrowia). Ze względu niewielką próbę trudno mówić o reprezentatywnych wynikach. Mogą one jednie pomóc nakreślić ramy problemów, jakie występują w przypadku systemów legacy.

Czy udaje się faktycznie wyłączać systemy legacy? W ponad 40% organizacji udało się maksymalnie wycofać ¼ zaplanowanych systemów, a w 20% – 0% zaplanowanych do wycofania systemów. Okazuje się więc, że polskie jednostki zaczynają sobie hodować prawdziwe „strucle”.

Respondenci posiadają w większości do 25 kluczowych systemów (pytaliśmy nie o wszystkie systemy, tylko o te, które są najważniejsze z perspektywy biznesu). Taką liczbę podało blisko 70% organizacji. Ale jednocześnie blisko 20% respondentów wskazało, że ma ponad 100 kluczowych systemów. Jeżeli chodzi o wiek kluczowych systemów, to trochę ponad 60% jest stosunkowo nowych (jak na światowe standardy korporacyjne), bo ma poniżej 10 lat. Jednocześnie blisko 15% systemów ma aż 16 i więcej lat (tutaj należy upatrywać istotnych problemów). Języczkiem u wagi są systemy mające 11–15 lat. Jest ich blisko 25%. Oznacza to, że w ciągu kilku lat liczba systemów starych i bardzo starych w polskich firmach może się w istotny sposób zwiększyć.

Ponieważ sam wiek nie decyduje o tym, czy dany system zaliczany jest do legacy, respondenci zostali poproszeni o wskazanie, jaka część posiadanych przez nich systemów to systemy zastane. Okazało się, że w 30% organizacji praktycznie nie występują systemy legacy, ale jednocześnie aż blisko w co czwartej organizacji stanowią one ponad 75% ogółu systemów. Co więcej, w ponad 40% organizacji już obecnie są więcej niż dwa systemy legacy, które w istotny sposób wpływają na funkcjonowanie biznesu (ograniczają możliwości jego rozwoju).

Interesujące było także określenie, w jakich językach stworzone zostały systemy legacy. Okazało się, że najczęściej są to: C/C++, Java oraz PHP. Czyli nie są to szczególnie stare (z perspektywy historii informatyki) języki programistyczne.


TOP 200