Zanim zajmiemy się problemem systemów zastanych (legacy), spróbujmy najpierw zdefiniować problem. Na użytek tego artykułu jako system zastany zdefiniujemy taki, z którym w razie awarii lub konieczności rozbudowy dział informatyki nie jest w stanie szybko sobie poradzić. Powody mogą być bardzo różne: wewnętrzne skomplikowanie i złożoność, brak odpowiedniej dokumentacji, brak kompetencji w zespole informatyków, wygasły bądź nigdy nieistniejący kontrakt na wsparcie... Do tego dochodzi wykorzystanie technologii, które wyszły z użycia, albo zależność od nich (np. osadzenie aplikacji na platformie producenta, który zniknął z rynku), stosowanie języków programowania lub platform, jakie są trudno dostępne, i stare wersje komponentów – podatne na awarie oraz posiadające luki bezpieczeństwa.

Jeżeli do tego wszystkiego dodamy osadzenie naszego systemu w architekturze w miejscu, gdzie inne systemy są z nim zintegrowane i od niego zależne, a także istotność dla działania podstawowych procesów przedsiębiorstwa, np. sprzedaży, rozliczeń, dostaw, księgowości, obraz będzie pełny. Legacy to ból głowy, nieprzespane noce, nieustająca niepewność oraz ciągła troska.

Istniejąca literatura na temat systemów zastanych koncentruje się na archaicznych technologicznie rozwiązaniach, np. mainframe’ach. Ale użycie takiej czy innej technologii nie musi determinować ryzyka związanego z legacy. Przeciwnie, systemy zastane są zaniedbane dlatego, że nie wymagały wielkiej uwagi i można było ich nie modyfikować i nie aktualizować. Dobrze spełniały swoje zadania, działały stabilnie i w związku z tym na którymś etapie uznano, że lepiej ich nie dotykać, a za wsparcie można przestać płacić.

Systemy legacy. Wszyscy mamy trupa w szafie

Pierwszym krokiem CIO do rozwiązania problemu systemów zastanych jest uświadomienie sobie: nie jesteś sam(a). Informatyka w polskich przedsiębiorstwach funkcjonuje na poważnie mniej więcej od ćwierćwiecza i jeśli ktokolwiek działa w biznesie dłużej niż dwa czy trzy lata, zapewne ma systemy legacy. Niezaktualizowane w porę wersje Windows, nieodnowione licencje na silnik bazy danych, systemy stworzone własnymi siłami w języku C, arkusze obliczeniowe na Excelu 2007 – i mnóstwo stanowisk i procesów, które od nich zależą. To, że wszyscy niechętnie o nich mówią, a kiedy już mówią, to półgębkiem i w zamkniętym gronie, wynika z faktu, że z takimi systemami wiąże się wielkie ryzyko. I to ryzyko jest centralnym tematem, który wymaga zainteresowania CIO.

Z badań przeprowadzonych latem 2017 r. przez prof. Andrzeja Sobczaka z warszawskiej SGH na próbce 29 polskich przedsiębiorstw wynika, że ponad 40% badanych organizacji posiada systemy, których wiek wynosi od sześciu do 10 lat, i drugie tyle takie, które mają powyżej 10 lat. Dekada w technologii to wieczność.

Nawet jeżeli przez ten czas system się nie zmieniał, to zmieniało się otoczenie. Używa niesprzedawanej wersji bazy danych, ma problemy z nowoczesnymi systemami operacyjnymi, niezbędne komponenty mają poważne luki bezpieczeństwa. Chociaż na badanie prof. Sobczaka trzeba patrzeć raczej w jakościowym niż ilościowym ujęciu, to fakty są faktami: mało który CIO może dzisiaj spać spokojnie. Powierzone mu środowisko, z prawdopodobieństwem graniczącym z pewnością, starzeje się szybciej, niż jest odnawiane. Problem legacy to jego problem, który jeszcze będzie się nasilał. Witajcie w świecie ryzyka związanego z długiem technologicznym!

Systemy legacy. Oblicza długu technologicznego

Trup, którego większość firm trzyma w szafie, ma różne oblicza. Spróbujmy dokonać krótkiej inwentaryzacji.

• Sprzęt – serwery, sprzęt sieciowy, systemy zasilające, zakupione wiele lat temu, pozbawione wsparcia, przestarzałe technologicznie, czasami pochodzące od nieistniejących producentów, ale nadal działające i wykorzystywane przez aplikacje i systemy.
• Platformy – oprogramowanie bazowe (systemy operacyjne, bazy danych, platformy middleware), które nie było od lat aktualizowane, i, co więcej, zaktualizowane być nie może, bo działające na nich aplikacje musiałyby zostać poprawione, albo nawet napisane od nowa.
• Oprogramowanie – systemy tworzone w językach programowania i z bibliotekami, które nie są już wspierane albo po prostu nie są już aktualizowane. Narzędzia, takie jak: Delphi, PowerBuilder, Visual Basic 6.0, a nawet COBOL i Clipper, istnieją dzisiaj w tysiącach, jeśli nie setkach tysięcy przedsiębiorstw.
• Dokumentacja – systemy zbudowane „pod klucz”, przez – albo z udziałem – pracowników, którzy już nie pracują już od lat, w przeciwieństwie do stworzonych przez nich systemów. W efekcie, działają jako „czarne skrzynki” z wszystkimi konsekwencjami – nie ma żadnej możliwości rozbudowy, a jedynie „archeologia” oraz „nadbudowa” takiego systemu.
• Ukryte interfejsy i cicha integracja – w architekturze aplikacji, które powstawały przez wiele lat, z reguły istnieją (tworzone często ad hoc) interfejsy do innych systemów. Mają wszystkie felery technologii i aplikacji legacy, ale spotęgowane – bo o ile dokumentacja systemu często jest lub była częścią kontraktu, o tyle o dokumentacji do samodzielnie zbudowanego interfejsu pomiędzy tym systemem a innymi aplikacjami trudno nawet pomarzyć.
• Niedostępność danych – w konsekwencji niejasnej struktury i niedzisiejszych technologii dane przetwarzane przez aplikację zastaną nie są dostępne do analiz. Niemożność wykorzystania ich w analizach zarządczych podcina przedsiębiorstwu skrzydła, zwłaszcza w czasach, o których słusznie mówi się, że „dane to nowa ropa”.

Konsekwencje wszystkich tych zjawisk są trzy. Pierwsza to koszty – systemy legacy konsumują dużą część budżetu i jest to część „sztywna”, którą można by porównać do dotacji do emerytur na szczeblu państwa. Drugi problem to bezpieczeństwo – i tutaj nie ma żartów ani kompromisów. Niemożność usuwania krytycznych podatności oznacza, że firma musi mierzyć się z ryzykiem utraty kontroli nad częścią systemu oraz danych, którymi ten system zarządza. Wyciek danych to najbardziej optymistyczny scenariusz. Najbardziej pesymistyczny to zatrzymanie kluczowego procesu w wyniku przejęcia kontroli nad systemem przez hakera lub złośliwe oprogramowanie (np. szyfrujące).

Trzeci, najważniejszy problem, dotyczy wprowadzania zmian. Istnienie systemu, którego firma nie może rozwijać, oznacza znaczne ograniczenie możliwości konkurencyjnych przedsiębiorstwa. Jeśli nasz system rozliczeń napisany jest w C++ i korzysta z bazy Informix, to każdorazowa zmiana formatu faktur, np. wynikająca z przepisów, będzie kosztowna i długotrwała. A żyjemy przecież w XXI wieku i czas wdrożenia zmiany (tzw. time-to-market) to dzisiaj kluczowy parametr biznesowy przedsiębiorstwa, którzy może przesądzić o jego zdolności konkurencyjnej.

Systemy legacy. Strategie wyjścia z długów

Prędzej czy później CIO musi zadać sobie pytanie: co zrobić z posiadanymi systemami legacy. Pierwsze wyjście to strategia pasywna: nie nic robić, niech te systemy działają. Rozwiązanie jest popularne, bo nie wymaga żadnych procesów decyzyjnych ani inwestycji. Natomiast narastające ryzyko sprawia, że system kiedyś może się po prostu zatrzymać. Przypomina to pozostawienie przeciekającej rynny w domu: dzisiaj nie trzeba nic inwestować, ale pojutrze trzeba będzie skuć wszystkie tynki z zagrzybionej ściany.

Strategia półaktywna zakłada eliminację głównych problemów. Można dokonać częściowej wymiany komponentów systemu, np. przestarzałej platformy sprzętowej, usuwając najważniejsze ryzyka, ale pozostawiając resztę. Taką wymianę łatwo jest powiązać z celem biznesowym i „ukryć” część niezbędnych inwestycji w kalkulacji ROI przedsięwzięcia. Na przykład przy okazji tworzenia nowego rozwiązania business intelligence dla działu sprzedaży dokonujemy aktualizacji platformy bazodanowej.

W strategii aktywnej (reengineering / refaktoring) następuje zastąpienie istniejącego systemu nowym rozwiązaniem, działającym na bazie współczesnych platform, technologii i infrastruktury, z zachowaniem jego interfejsów i funkcjonalności. Atrakcyjność tej strategii polega na tym, że jest względnie prosta z punktu widzenia architektury. Jej wadą jest trudność w pozyskaniu środków do jej sfinansowania, zaś utrzymanie styków (interfejsów) często sprawia, że nowy system „ciągnie” problemy starego – np. przestarzałe formaty i komponenty.

Wreszcie, jest strategia głębokiej zmiany: systemu wraz z częścią architektury. To najbardziej radykalna, najbardziej kosztowna, ale i najbardziej obiecująca strategia. Eliminacji istniejącego systemu legacy towarzyszy głębsza przebudowa procesów i architektury przedsiębiorstwa. Nowy system, inaczej niż przy reengineeringu, nie zastępuje starego 1:1; jako nowy element układanki, niektóre puzzle eliminuje, inne zmienia, jeszcze inne zostawia. Ta strategia potencjalnie oferuje największe korzyści, choć jej wdrożenie wymaga pełnego wsparcia biznesu oraz czasu i pieniędzy.

Na każdą ze strategii (z wyjątkiem kompletnie pasywnej) potrzebne są pieniądze. CIO musi wiec zawsze przekonać biznes, że warto te pieniądze wydać oraz delegować pracowników biznesowych – choćby tylko byli potrzebni do konsultacji i testów.

Systemy legacy. Jak pozyskać środki na inwestycje

Są trzy główne metody. Pierwsza to odpis na dług technologiczny, który dopisujemy do budżetu każdego projektu. Na przykład zawsze 10% łącznego budżetu projektu stanowi kwota, którą przeznaczamy na cele niezwiązane bezpośrednio z nim, ale na odnowienie starych licencji, wymianę serwerów, aktualizację wersji albo odświeżenie środowiska testowego. Wbrew pozorom, użytkownicy biznesowi to rozumieją – w codziennym życiu płacą 8 albo 23% podatku VAT od każdego zakupu i wiedzą, że bez tego nie mieliby dróg, wojska, szkół i policji.

Druga metoda to eliminacja kosztów. Ta jest najbardziej skuteczna przy reengineeringu. Tutaj można czarno na białym udowodnić, że np. wymiana systemów komercyjnych na systemy open source pozwoli zaoszczędzić realne pieniądze – dość, aby sfinansować sam projekt. Windows można więc zamienić na Linuksa, komercyjne silniki baz danych na PostgreSQL albo MariaDB, a platformy middleware na darmowego JBossa. Niestety, w ten sposób można łatwo zamienić siekierkę na kijek, czyli platformy płatne, ale stabilne i posiadające wsparcie producenta, na bezpłatne, ale awaryjne i wymagające dodatkowych etatów.

Trzecia metoda przekonywania, najlepsza do zastosowania, to ścisłe powiązanie eliminacji systemu legacy z korzyściami biznesowymi. Zarówno tymi bezpośrednimi, takimi jak: zwiększona sprzedaż, zmniejszone rezerwy, krótszy cykl operacyjny, lepszy obieg gotówki, jak i pośrednimi – lepsza dostępność danych, krótszy time-to-market i w konsekwencji lepsza dokładność planowania albo szybsza, sprawniejsza realizacja nowych przedsięwzięć. Dobra wiadomość jest taka, że w ten sposób z projektu „wymiany technologicznego trupa” można zrobić zdecydowanie bardziej ekscytujący projekt „zwiększenia penetracji nowych kanałach sprzedaży” albo „poprawy zwinności biznesu”, a na dodatek połączyć to z jakąś modną, innowacyjną technologią, np. blockchain, uczenie maszynowe, rozpoznawanie obrazu albo mowy.

Systemy legacy. Drużyna pierścienia

CIO nie powinien podejmować się tego sam. Przede wszystkim potrzebny jest mu architekt. Osoba, która dobrze zna aktualne rozwiązania, ale także – czy raczej przede wszystkim – wizję długofalowej ewolucji architektury procesów i systemów przedsiębiorstwa. Każde przedsięwzięcie powinno być kamykiem, który składa się na realizację tej wizji.

„Hobbitami” w tej wyprawie powinni być analitycy i szefowie projektu. Radzenie sobie z masą systemów zastanych wymaga realizacji większych i mniejszych, prostszych albo trudniejszych przedsięwzięć: od eliminacji arkuszy excelowych i przeniesieniu tej logiki na standardową platformę business intelligence aż po wymianę platform sprzętowych i systemowych. To wszystko w przedsięwzięciach trwających od kilku tygodni do kilku lat.

Nie obędzie się także bez pomocy czarodzieja, to analityk finansowy. Wyprawom przeciw zmurszałym orkom i goblinom czającym się w czeluściach architektury systemów przedsiębiorstwa musi towarzyszyć wywiad: jakie siły przygotować, jak przekonać do inwestycji decydentów, jakiego zwrotu oczekiwać. Jeszcze raz: biznes nie wyda pieniędzy na eliminację legacy, jeśli nie będzie widział, że stoi za tym mierzalna korzyść.

Na koniec przyda się elf sprawnie posługujący się łukiem i krasnolud z toporem, czyli programiści interfejsów, baz i komponentów. CIO wprowadzi ich do akcji wszędzie tam, gdzie sytuacja zacznie wymykać się spod kontroli. Na przykład gdy stary system po prostu przestanie działać i trzeba go będzie ekspresowo reanimować, a także tam, gdzie dostawca np. licencji w nowym roku, czując przymusową sytuację przedsiębiorstwa i wiedząc, że wkrótce utraci przychody (bo system został wybrany do reengineeringu lub eliminacji), będzie się starał podyktować zaporową cenę. I tam, gdzie trzeba będzie prawdziwego oka snajpera i wirtuozerii w technologii, aby rozwiązanie sprzed kilkunastu lat pozwoliło na wdrożenie nowego produktu, procesu biznesowego albo przechowywanie nowych danych, mimo że w firmie nikt tak do końca nie rozumie, jak ono działa.

Masa systemów legacy będzie przyrastać. Taka jest psychologia człowieka: zawsze nowe, lśniące zabawki bardziej nas pociągają niż utrzymywanie przy życiu starych. Przedsiębiorstwa, cyfryzując nowe obszary działania, powiększają swoje uzależnienie od informatyki. Dzisiejsze inwestycje to jutrzejszy dług. Problem radzenia sobie z systemami zastanymi i długiem technologicznym stanie się wkrótce kluczową kompetencją szefów informatyki. Trudno się obrażać na rzeczywistość – radzę raczej przyzwyczajać się do legacy.