W tym odcinku poruszam kwestię oprogramowania legacy – "odziedziczonego w spadku", przestarzałego, czy potocznie mówiąc, "trupów w szafie" – i tego jak sobie z nim radzić.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 24. „Panie, kto to Panu tak... czyli o utrzymywaniu oprogramowania legacy słów kilka”. W tym odcinku poruszam kwestię oprogramowania legacy. Nie ma takiego chyba dobrego polskiego odpowiednika - mówi się o oprogramowaniu odziedziczonym w spadku, przestarzałym, spotkałem się też z pojęciem trupa w szafie, natomiast najczęściej po prostu mówimy, że jest to oprogramowanie legacy, z polskim tłumaczeniem jest gorzej, natomiast to jedno słowo bardzo dobrze oddaje naturę takiego oprogramowania.

Temat oprogramowania przestarzałego, oprogramowania legacy staje się z każdym rokiem coraz ważniejszy, bo i z każdym rokiem jest coraz mniej firm, które w ogóle nigdy nie miały do czynienia z IT, czy też miały do czynienia w jakimś bardzo ograniczonym zakresie czy to z oprogramowaniem gotowym, czy też zamówionym. Natomiast jednocześnie, siłą rzeczy, coraz więcej firm ma oprogramowanie, które powstawało niekoniecznie 3-6-12 miesięcy temu, a kilka-kilkanaście lat temu. I oczywiście takie oprogramowanie się starzeje i to, w jaki sposób poradzić sobie z tym problemem jest jednym z ciekawszych wyzwań, przed jakimi stoi branża IT, ale i, co do zasady, cały biznes.

Zacznijmy tradycyjnie od definicji. I w zasadzie to jest tak naprawdę już pewien problem, bo takiej jednej spójnej definicji oprogramowania legacy nie ma - jest to chyba jedna z tych sytuacji, gdzie każdy wie, o co chodzi, ale gdy przychodzi do zdefiniowania takiego precyzyjnego, formalnego, to pojawia się problem. Ja w takich sytuacjach - co przecież często też ma miejsce w przypadku prowadzenia jakichś zajęć, wykładów - jak nie umiem czegoś dobrze zdefiniować, to staram się po prostu przedstawić pewne aspekty, wspólne cechy, które można takiemu oprogramowaniu przypisać.

Po pierwsze, co już wspomniałem we wstępie, jest to oprogramowanie, które nie jest dopasowane do bieżących standardów i wymagań, wymagań oczywiście użytkowników, ale nie tylko użytkowników, bo nawet większe znaczenie mają takie czynniki jak np. bezpieczeństwo aplikacji, jej skalowalność i jakość kodu od strony technicznej, zgodność z bieżącymi wersjami oprogramowania zależnego, czyli np. systemu operacyjnego - może być tak, że po prostu istniejący projekt nie działa np. pod nowym Windowsem albo działa gorzej, albo z nową wersją baz danych.

Cecha druga to to, że oprogramowanie, mimo tych wszystkich zarzutów i także wielu innych potencjalnych, które przedstawiłem przed chwilą, mimo wszystko, co do zasady, działa.

Cecha trzecia to to, że oprogramowanie legacy, nawet jeżeli nie jest używane cały czas, nie jest używane w całej rozciągłości, być może tylko część funkcji jest używana, to mimo wszystko jest używane przez jakąś część pracowników danej organizacji.

Można powiedzieć, że ta cecha druga łącznie z cechą trzecią to atrybuty dobrego bieżącego oprogramowania. Jeżeli jest system, program, który jest używany i oczywiście działa i jednocześnie nie jest przestarzały, to w zasadzie jest po prostu dobrze. Jeżeli mamy do czynienia z cechami pierwszą i drugą, czyli oprogramowanie jest nie do końca aktualne, ale działa, natomiast nie jest używane w organizacji, bo po prostu np. zaczęto korzystać z innego systemu, to takie oprogramowanie można po prostu w jakiś sposób usunąć, dane zarchiwizować i tyle. Z kolei połączenie cech pierwszej i trzeciej, czyli oprogramowanie jest przestarzałe, jest używane, ale nie działa, to w zasadzie, można powiedzieć, taka kombinacja, która nie za bardzo ma sens - jeżeli nie działa, to raczej nie będzie używany. Chociaż tutaj jednocześnie warto zwrócić uwagę, że być może brzmi to jak sprzeczność, ale taka sytuacja, czyli oprogramowanie nie działa, może być w pewien sposób użyte, może mieć wartość. Dlaczego? Proszę pamiętać, że w takim oprogramowaniu, zwłaszcza jeżeli jest to oprogramowanie szyte na miarę, dedykowane, w kodzie takiego systemu mogą być zawarte różne przydatne informacje, które mogą być potem użyte do stworzenia albo nowej aplikacji, albo do przeniesienia procesów do jakiejś innej formy. Ja pracowałem kiedyś nad takim projektem, zresztą to jedna z dłużej żyjących aplikacji, które stworzyłem, bo prawie 10 lat, w której było bardzo wiele wzorów, równań, kalkulacji. I tak naprawdę, chociaż klient podjął decyzję, żeby tej aplikacji już nie odświeżać, to tak naprawdę jest cały czas w kodzie zawartych dużo ciekawych obliczeń, które być może kiedyś klient będzie mógł sobie w jakiejś postaci wykorzystać ponownie. Dlatego nawet niedziałające oprogramowanie może mieć pewną, oczywiście dużo mniejszą, ale jednak wartość.

I teraz ważna rzecz. Już chyba któryś raz tak się zdarza - kwestię oprogramowania legacy trzeba znowu rozpatrzeć troszkę inaczej, przez pryzmat różnych rodzajów oprogramowania. Taki trójpodział nam się coraz częściej pojawia w tym podcaście, czyli kwestia oprogramowania pudełkowego, czyli gotowego, ale takiego do samodzielnego użycia, instalacji, oprogramowania SAS-owego, czyli dostęp abonamentowy w chmurze i oczywiście oprogramowanie dedykowane - to które jest najbliższe mojemu sercu z racji działalności w Makimo. W SAS-ach w zasadzie problem legacy nie występuje, bo zwróćmy uwagę, że, jeżeli w ogóle elementarnie taka usługa jest utrzymywana - a jeżeli usługa, co do zasady, po prostu działa i klienci płacą, to musi być utrzymywana - to twórca tej usługi czy jakaś firma, która dostarcza taki SAS powinna dbać o zapewnienie aktualizacji bezpieczeństwa poszczególnych składników takiego ekosystemu, bezpieczeństwa samej aplikacji, która ten SAS tworzy, zapewnienie zgodności z nowymi przeglądarkami chociażby czy np. też oczywiście mobilnymi systemami operacyjnymi, z przeglądarkami na urządzeniach mobilnych. To wszystko może się zepsuć, ale jednak każdej działającej - nawet nie mówię, że bardzo dobrze, ale elementarnie - firmie zależy na naprawieniu takich błędów, więc nawet jak coś się stanie, to jednak można liczyć na to, że taki dostawca zareaguje. Chociaż nie da się też ukryć, że niektóre startupy, też z powodu pewnych ograniczeń - no, tutaj nie każdy SAS to startup, też pamiętajmy, są SAS-y dojrzałe, gdzie już po prostu nie mówimy o startupie - ale zwłaszcza w przypadku startupowych SAS-ów, SAS-ów, które są tworzone przez jeszcze młode firmy mogą być takie problemy jak np. kwestia bezpieczeństwa, bo to nie zawsze widać - aplikacja może działać, może działać wydajnie, może działać na różnych urządzeniach, ale może np. nie być dobrze zabezpieczona i to jest niestety trudna rzecz. Natomiast, mimo wszystko, z tym się niewiele da zrobić. Jeżeli nie spotykasz jakiejś opinii w internecie, gdzie ktoś zwraca uwagę, że są jakieś znane problemy, albo po prostu nie ma, nie było ataków na taką aplikację, to w zasadzie można po cichu przyjąć, że chyba jest to usługa bezpieczna, trzeba jakiś zdrowy poziom ryzyka zaakceptować. Oczywiście to też zależy, o czym mówimy, o jakim rodzaju usługi - im bardziej wrażliwe dane, dotyczące, nie wiem, finansów, jakiejś poczty elektronicznej, tym na pewno trzeba zachować większą ostrożność.

W przypadku produktów pudełkowych bądź instalowanych we własnej infrastrukturze, gdzieś na własnych serwerach sytuacja wygląda zgoła odmiennie; tutaj niestety kwestia aktualizacji jest już po twojej stronie, po twojej, jako klienta - oczywiście, z reguły w organizacjach zajmują się tym przedstawiciele działów IT - i w niektórych przypadkach takie aktualizacje są robione automatycznie, oczywiście po wyrażeniu zgody, tak jak, nie wiem, w przypadku Windowsa, Office’a, takich typowych prostych programów. Natomiast nie da się ukryć, że w przypadku takich bardziej zaawansowanych systemów procedura aktualizacji nie musi być niestety taka łatwa czy, mówiąc wprost, nie jest często taka łatwa, bo aktualizacja samego oprogramowania może wiązać się z aktualizacją zależności, te zależności też mogą mieć zależności - krótko mówiąc, to już nie jest tylko klikanie „dalej”, „dalej”, „dalej”, „okej” i „zakończ”. Tutaj warto jako przykład podać oprogramowanie Jira. Jira - w branży IT jedno z najpopularniejszych narzędzi do zarządzania projektami, do zarządzania zadaniami, też help deskiem, są różne tryby. I tu jest ciekawa rzecz, bo Jira może być używana zarówno w formie SAS-owej jak i w formie self-hosted, czyli, mówiąc po naszemu, instalowana we własnym środowisku. Instalacja Jiry u siebie daje niewątpliwie większą kontrolę, ale też większą wymusza odpowiedzialność, zadbanie o bezpieczeństwo, aktualny stan komponentów, takich jak aktualna wersja platformy Java - bo Jira jest tworzona w Javie - bazy danych MySQL czy POSTGRES. Więc tutaj trzeba o to po prostu zadbać samemu, co w przypadku Jiry chmurowej dostajemy niejako w pakiecie. Z drugiej strony, mając większą kontrolę, możemy np. w przypadku Jiry tej własnej u siebie, np. jeżeli potrzebujemy wyciągnąć jakieś bardzo specyficzne raporty z Jiry, których nie dają standardowe funkcje albo nie dają też wtyczki, czy też te wtyczki są niezwykle płatne, a my chcemy np. wygenerować jeden prosty raport, tutaj, jeżeli mamy dostęp do bazy, możemy się zalogować u siebie, napisać kwerendę, napisać zapytanie do bazy i sobie takie dane wyciągnąć. W Jirze chmurowej z tym niewątpliwie jest z kolei problem.

Dobrze, bo ja tutaj dużo mówię o aktualizacjach, ale to jest ta kluczowa kwestia, zwłaszcza w przypadku oprogramowania gotowego. A co jeżeli nie będziemy aktualizować oprogramowania? Poza brakiem dostępu do nowych funkcji, bo przecież wraz z aktualizacjami też nowe funkcje się pojawiają, narażamy się przede wszystkim na problemy z bezpieczeństwem i kompatybilnością, zgodnością z nową wersją systemu operacyjnego. Oczywiście, że to nie jest tak z reguły, że pierwszego dnia, jak, powiedzmy, jakieś oprogramowanie będzie nieaktualne, to już od razu mamy pewność, że nastąpił atak hakerski, ale z upływem czasu będzie coraz większe ryzyko, że do takiego ataku może dojść, np. gdy nie będziemy w stanie zaktualizować systemu operacyjnego, bo jak zaktualizujemy system operacyjny, to wtedy przestanie działać nasza aplikacja. Więc tutaj istnieje taka sieć zależności i brak aktualizacji często jednego składnika powoduje, że i z innymi musimy się powstrzymać w tych kwestiach.

Podsumowując, oprogramowanie legacy w zakresie gotowego oprogramowania nie daje nam za dużo pola do działania, bo nie mamy też takiej pełnej kontroli, nie możemy zaingerować w to oprogramowanie. Natomiast jeżeli masz oprogramowanie gotowe, to takie kilka rad mogę ci tutaj sprezentować.

Przede wszystkim, poszukaj na stronie producenta, lub nawet na jakichś zewnętrznych stronach w internecie - tutaj przydaje się hasło „End of life”, koniec życia produktu - do kiedy jest oferowane wsparcie danego oprogramowania, ale w bardzo konkretnej wersji. Czyli musisz sprawdzić wersję swojego oprogramowania i poszukać informacji do kiedy jest oferowane wsparcie, support, zwłaszcza wsparcie bezpieczeństwa, czyli security support. Nie da się ukryć, że używanie oprogramowania po tym terminie wiąże się z większym ryzykiem, coraz większym wraz z upływem coraz większej ilości czasu. I kiedy już poznasz ten termin, możesz podjąć pewne działania mające na celu rozwiązanie problemu. Można spróbować wykupić dodatkowe wsparcie, czasem przedłużyć, aby mieć dostęp do aktualizacji. Można spróbować po prostu zainstalować, zakupić oczywiście też, nową wersję programu. A jeżeli czasu jest sporo, a np. ta wersja starego oprogramowania już też, często nie da się ukryć, nie spełnia np. twoich nowych potrzeb, można oczywiście zainwestować w nowe oprogramowanie, szyte na miarę, czy też gotowe, w zależności od tego, co jest na rynku. Natomiast na pewno to jest działanie, które powinno być podjęte z zauważalnym wyprzedzeniem czasowym, nawet jeżeli chcemy rozważyć przesiadkę z jednego oprogramowania gotowego na inne.

Omówiliśmy SAS-y, omówiliśmy pudełka, a co jeżeli masz oprogramowanie dedykowane... rozumiane bardzo różnie? Bo to nie musi być oprogramowanie zamówione w software house’ie, często zdarza się, że jest to jakaś aplikacja stworzona przez pracownika, który nawet może nie był programistą, ale coś tam gdzieś tam doczytał, nauczył się, zrobił. Jak to mówią, prowizorka jest najtrwalsza i naprawdę widziałem dowody tego u wielu klientów. Oprogramowanie działa, robi swoje, ale jednak po pewnych czasie się okazuje, że jest to spore ryzyko. Może też być sytuacja, że pracownik np. już nie pracuje, a jego, można powiedzieć, dziedzictwo przerosło jego staż w firmie, i co wtedy zrobić? W świecie oprogramowanie dedykowanego jest trudno, myślę, że zauważalnie trudniej, przedstawić jakiś taki precyzyjny scenariusz, bo konkretne kroki zależą od technologii, w jakiej została napisana aplikacja, od infrastruktury, w której taka technologia została wdrożona, kiedy ta aplikacja została wdrożona - to też oczywiście wiąże się z tym, jakie technologie - 20 czy 25 lat temu wielu technologii, które obecnie są bardzo popularne jeszcze nie było, a inne były niezwykle młode. W obecnych czasach coraz większe znaczenie mają też integracje, jakie dane oprogramowanie, które chcemy poddać pewnej analizie... integracje, które występują z innymi systemami. Co do zasady, z uwagi na z reguły zauważalnie większy poziom skomplikowania w porównaniu do tych gotowych aplikacji warto rozważyć zakupienie usługi, niekoniecznie od razu kupienie całego oprogramowania, ale najpierw wykonanie takiego audytu. Tutaj możemy mówić o takim czystym audycie cyfrowym, technicznym, czyli Technical Due Diligence, ale też o doradztwie w zakresie oprogramowania dedykowanego już takim wyspecjalizowanym, takim jak Legacy Software Advisory, które pozwoli na zbadanie różnych aspektów infrastruktury informatycznej, ale też samego projektu, samej aplikacji, analizę kodu tej aplikacji. I oczywiście tutaj pewne działania związane z analizą oprogramowania takiego szytego na miarę będą podobne jak w oprogramowaniu gotowym, gdzie też trzeba się zastanowić, czyli właśnie kwestia terminów, do których dane oprogramowanie jest wspierane. Tutaj, w przypadku oprogramowania dedykowanego możemy mówić nie tyle o terminie wspierania, terminie, do kiedy będzie takie oprogramowanie wspierane - bo jeżeli pracownik, który nam zrobił taką aplikację już nie pracuje, to nie jest wspierane - ale chodzi chociażby o, no właśnie, np. system operacyjny, na którym jest uruchomiona taka aplikacja - on też ma swoją datę końca wsparcia, końca życia. Więc te kroki też warto wykonać, natomiast już samą analizę tego oprogramowania, z którym faktycznie chcemy coś zrobić, tego oprogramowania legacy, tutaj faktycznie trzeba, warto, moim zdaniem, oddać specjalistom, którzy przeanalizują, na ile jest to oprogramowanie rozwijalne - to też jest niezwykle ważne, bo nawet jeżeli ono hipotetycznie jest bezpieczne, to może się okazać, że np. próba rozwinięcia danego projektu będzie po prostu bardzo trudna.

To jest, nie da się ukryć, taka sytuacja, w której - porównując to, jak często zresztą tutaj robię w podcaście - mamy sytuację, że np. samochód ładnie wygląda, jeździ, ale gdy zajrzymy pod maskę, to okaże się, że niestety silnik jest, czy będzie za chwilę do wymiany, że te wnętrzności samochodu są po prostu w fatalnym stanie i tylko można odliczać czas, kiedy coś się stanie - trochę podobnie wygląda to w oprogramowaniu. Oczywiście, oprogramowanie nie ma części zużywalnych wprost, ono może sobie działać, natomiast próba np. rozwinięcia takiego źle napisanego oprogramowania może być po prostu niezwykle trudnym zadaniem. I często właśnie taki nowy dostawca, wykonawca jest obarczany tutaj tym problemem i to na niego wina spada, że nie umie sobie poradzić, a prawda jest taka, że to oryginalny wykonawca, jak to w tytule tego odcinka, no po prostu... nie będę cytował dosłownego powiedzonka, ale po prostu wykonał źle swoją pracę.

Cóż więc począć w takim przypadku? Bo załamywanie rąk nie wchodzi w grę, chyba że tak na chwilę, żeby odreagować. W skrajnych przypadkach - i nam też się to zdarzało - może się okazać, że przepisanie aplikacji ma sens, zwłaszcza jeżeli poza takim doprowadzeniem jej do porządku chcesz też dodać jakieś nowe elementy, natomiast jeżeli zależy ci na zachowaniu istniejącego systemu, dostosowaniu go jednakowoż do obecnych reguł bezpieczeństwa, przede wszystkim do stale ewoluujących technologii, tych innych zależności, tak jak wspominałem, można rozważyć proces refaktoryzacji i następnie aktualizacji kodu. Refaktoryzacja to proces usprawnienia jakości kodu, czy też ogólnie całego rozwiązania informatycznego, bez zmian funkcjonalnych. I, przyznam szczerze, to jest usługa, której klienci po prostu nie lubią, bo „Jak to, mamy zapłacić jakieś pieniądze za to, że się nic nie zmieni? Przecież płaci się za efekty, za funkcje, za zmiany wizualne lub funkcjonalne, a nie za coś, czego w żaden sposób nie widać”. Z drugiej strony - i znowu wracam tu do porównań do samochodów, one fajnie działają - to jest trochę tak jak z kosztem eksploatacji samochodu. W rozwijanym oprogramowaniu, takim, o które nie dba się regularnie, bo czasami nie ma np. czasu czy budżetu, jakość będzie po prostu spadać z czasem. I samochód też, może nie pod kątem jakości się tak zachowuje, ale przecież nie możemy nawet nowo kupionym samochodem jeździć w nieskończoność bez żadnych działań - musimy wykonać przeglądy klimatyzacji, filtrów, przegląd w ogóle całego samochodu, wymienić olej, klocki hamulcowe czasem i z tym jakoś wszyscy się godzą. Pewnie ma to związek z takim fizycznym aspektem samochodu, że się zużywają dosłownie, ale oprogramowania w trochę inny sposób, ale też to dotyczy.

Kiedy już dysponujemy aplikacją poddaną takiej refaktoryzacji, można następnie spokojnie zacząć aktualizować taki projekt do nowych wersji bibliotek, nowych wersji tzw. frameworków, aktualizując wszystko i dbając już wtedy nie tylko o samą jakość i rozwijalność, ale też o bezpieczeństwo, o skalowalność, o te inne aspekty, które już bardziej zdecydowanie widać.

Po tych dwóch operacjach utrzymywanie oprogramowania w przyszłości i jego rozwijanie, dodawanie nowych funkcji będzie naprawdę znacznie tańsze, bo, można powiedzieć, że aplikacja będzie troszkę jak nowa. Dzięki temu, chociaż sam proces refaktoryzacji, sam proces aktualizacji na pewno generuje pewne koszty, które pozornie na początku się nie zwracają, z czasem, zwłaszcza jeżeli dane oprogramowanie jest dla nas istotne i ma przyszłość, z czasem taki efekt po prostu... taka inwestycja po prostu się zwróci.

Na tym kończymy dzisiejszy odcinek. Myślę, że w niedługim czasie pojawi się kontynuacja, bo tak naprawdę tematu do końca nie wyczerpałem. Nie będę tutaj umieszczał spojlerów, natomiast w sumie pierwotny impuls dla tego odcinka nie został przeze mnie do końca omówiony. Nie powiem, o co chodzi, ale o temat, powiedzmy, pokrewny, związany z audytowaniem - to są usługi, którymi też miałem okazję się zajmować, więc mówię tutaj mocno z własnego doświadczenia. I coraz częściej zauważamy, że u nas, w Makimo pojawiają się pytania, prośby o to, aby zająć się oprogramowaniem nie tworzonym od zera przez nas, tylko oprogramowaniem, które już istnieje. I to jest trend, który faktycznie w przyszłości, naszym zdaniem, będzie po prostu wzrastał.

Jeżeli macie jakieś komentarze, sugestie - w ostatnim czasie otrzymuję ich trochę więcej - to naprawdę zachęcam. Nie mówię tego w każdym odcinku, żeby już się tak nie powtarzać, ale bardzo i sympatycznie i miło jest przeczytać czy porozmawiać na temat wcześniejszych odcinków czy pomysłów na kolejne odcinki. Tak że zachęcam do kontaktu, naprawdę w pewien sposób możecie wpłynąć też na to, co będzie tutaj omawiane, dyskutowane. Na dziś to już wszystko.

Dziękuję za uwagę, kłaniam się nisko i do usłyszenia.