Może na początek ustalmy co mam na myśli, gdy mówię o przestarzałych aplikacjach (internetowych / webowych, ale i nie tylko). Często takie rozwiązania nazywane są też systemami legacy, a wśród developerów znane są pod nazwą kodową: ten shit, którego nie chcę dotykać nawet dziesięciometrowym kijem. No więc aplikacje / systemy legacy, to takie stwory, które nierzadko pamiętają czasy, gdy ludzie nie "googlali" rożnych rzeczy, a mówiło się, że "altavistują", a pilne wiadomości przesyłało się jeszcze na pager. Innym sposobem kwalifikacji danego rozwiązania do tej niechlubnej kategorii może być informacja, że gdy zaczęło działać produkcyjnie, to od razu na fazę drugą miała zaplanowany upgrade do PHP5, czy Java 1.5 (czy inne w zależności od wybranego języka, które miały premierę niedługo po roku 2000). No i ta aplikacja czasami dalej jest przed tą fazą drugą.

Jak wygląda praca z systemem legacy?

Często dla Ciebie i Twojej firmy praca z takim systemem oznacza (co nie zawsze jest oczywiste, bo wszystko jakoś działa i działało przez X lat):

1. Łatwość korzystania z tego systemu plasuje się na drugim miejscu, zaraz po rozliczeniu podatków w "Polskim ładzie". Twoi pracownicy / klienci narzekają, że jest powolny, trudno coś w nim znaleźć i zawiesza się przy losowych operacjach.
2. Jeśli chodzi o wsparcie mobilne, to system wciąż jest w latach 90-tych - nie jest responsywny / nie jest przyjazny dla urządzeń mobilnych, a współcześnie użytkownicy nie spodziewają się już niczego innego.
3. Oprócz tego, że nie jest zgodny z najnowszymi standardami w zakresie UX (doświadczeń użytkownika) i usability (użyteczności) możesz podejrzewać (lub mieć twarde dowody), że system nie jest bezpieczny. Albo zrobiłeś audyt bezpieczeństwa (lepiej) albo jeden z Twoich bardziej uzdolnionych użytkowników znalazł krytyczne błędy bezpieczeństwa w Twoim oprogramowaniu (gorzej). UODO lubi to (a Ty szykuj grube tysiące na ew. kary)!
4. Dostawca rozwiązania nie chce (nie może) uczynić go lepszym. Albo nie jest to wykonalne z ich perspektywy, albo nie ma to sensu z Twojej: dostawca ma bardzo długie cykle rozwojowe lub stały się one drogie do tego stopnia, że nie ma sensu inwestować.
5. Rozwiązanie nie udostępnia na dodatek żadnych API (możliwości integracji z nim innych rozwiązań), które mógłbyś wykorzystać do zbudowania lepszych narzędzi wokół niego.
6. Dodatkowo nie masz dostępu do bazy danych (np. z powodu ograniczeń licencyjnych) lub baza danych jest trudna do odczytania, czy wykonania inżynierii wstecznej (np. jak u wiodącego na świecie dostawcy oprogramowania zza Odry z ich maksymalnie czteroliterowymi nazwami kolumn, które są skrótem dla trzystronicowych słów w języku niemieckim). Innym przypadkiem odnośnie bazy danych może być to, że silnik baz danych jest oprogramowaniem, które nie jest już wspierane przez producenta.
7. Nie można systemu po prostu zastąpić nowym, ponieważ użytkownicy muszą np. uwierzytelniać się w tym starym systemie. Bez tego nie mają dostępu do swoich danych.

Jakie są konsekwencje pracy z systemem legacy?

Kilka przykładów poniżej jakie straty mogą wynikać dla Twojej organizacji w związku z działaniem na przestarzałym systemie.

1. Słabsza sprzedaż niż wynikałoby to z możliwości - np. Twój przestarzały system CRM zawiesza się, zawodzi w krytycznych momentach, proces sprzedaży trwa 30 minut zamiast 5, bo drukowanie dokumentu umowy trwa wieczność (a klienci się irytują, że tak prosta rzecz znowu nie działa).
2. Masz wyższe koszty obsługi klienta, bo klienci dzwonią ze wszystkim, bo przestarzały system samoobsługowy jest dla nich niedostępny, ablo trudno coś w nim zrobić samemu, albo żeby dojść do tego jak to zrobić trzeba mieć ukończoną habilitację w trzech dziedzinach nauki.
3. Twoi pracownicy (zwłaszcza nowi) mają problem z pracą z tym oprogramowaniem, masz dłuższe cykle szkoleniowe i musisz zainwestować więcej, aby ludzie pracowali z nim produktywnie.
4. Masz niespójne dane i nie możesz ich wykorzystać do wiarygodnego raportowania (np. przez brak walidacji pól wejściowych, co powoduje, że w danych masz wszystkie możliwe sposoby zapisu daty, NIPu, a kluczowe informacje zapisywane są w ogólnych notatkach, bo nie ma dla nich określonego miejsca w systemie).
5. Dużo dłużej zajmuje wdrażanie nowych funkcjonalności (jeśli to w ogóle jest jeszcze możliwe), kosztuje to więcej z każdym kolejnym wdrożeniem i przez większość czasu jesteś w tyle za konkurencją, jeśli chodzi o sprawne narzędzia, które powinny pomagać w pracy Twoim pracownikom, a nie być im kulą u nogi.
6. I można by tak jeszcze długo wymieniać ...

Ok, to już wiesz, że nie jest kolorowo - jak ratować się z opresji systemu legacy?

Możliwości w dużym skrócie jest kilka i każdorazowo należy przyjrzeć się, który ze sposobów będzie najlepszy w danym przypadku:

1. stworzenie rozwiązania od nowa lub kupienie gotowego rozwiązania tej klasy + migracja danych
2. wprowadzanie poprawek / zmian w systemie tak, aby stopniowo go modernizować i wprowadzić w trzecią dekadę XXI wieku
3. wykorzystanie starego narzędzia jako API dla innych systemów

Jeśli z różnych względów podejścia 1. i 2. nie są dostępne w określonych warunkach można pokusić się o podejście nr 3. Jeśli Twój system jest aplikacją internetową (najlepszy przypadek, ale aplikacje desktopowe z większymi trudnościami też nie są na straconej pozycji) możesz przeprowadzić studium wykonalności czy może być użyty jako API. Wiele razy okaże się, że naśladowanie interakcji użytkownika z systemem za pomocą dostępnych na rynku narzędzi przyniesie dobre wyniki. Możesz niejako ukryć stary system i wyeksponować jego funkcje jako API dostępne dla bardziej przyjaznych i współczesnych aplikacji internetowych, aplikacji typu Single Page, aplikacji mobilnych i do innych celów.

Jak podejść do takiego projektu unowocześnienia przestarzałego systemu?

Jest to zwykły projekt stworzenia i wdrożenia oprogramowania, więc powinien obejmować wszystkie etapy znane w tego typu projektach, niezależnie od tego, czy realizujesz go w metodyce Scrum, Waterfall, Kanban, czy "na chłopski rozum". Standardowo projekt będzie zawierał etapy takie jak analiza, implementacja, testowanie, wdrożenie, szkolenia, utrzymanie i ew. dalszy rozwój. Co będzie wyróżniało taki projekt od przedsięwzięć, gdzie budujemy narzędzie od zera to fakt, że powinniśmy już wiedzieć, po wielu latach użytkowania, jakie procesy zaimplementowane w starym narzędziu są potrzebne, a jakie nie. Kilka kwestii uwzględniających specyfikę takiego projektu poniżej.

Analiza

1. Zrób mapę funkcji, które chciałbyś zmigrować
2. Przeanalizuj (strona po stronie, ekran po ekranie) dotychczasowy system i wypisz funkcje / dane, które chciałbyś mieć w nowym systemie (może nie wszystko jest konieczne)
3. Optymalizacja procesów biznesowych Prawdopodobnie możesz wprowadzić usprawnienia w nowym systemie poprzez uproszczenie procesów, więc zrób to zanim zaczniesz tworzyć nowe narzędzie.
4. Zweryfikuj jakie są obecne wymagania wydajnościowe dla systemu, a jakie powinny być dla nowego.
5. Zastanów się, co sprawiło, że Twój obecny system jest przestarzały i zaadresuj to w swoich wymaganiach dla nowego rozwiązania.
6. Opracuj podejście do replikacji / migracji danych (szczególnie ważne, jeśli starsza baza danych nie jest łatwo dostępna) Możesz zapisać wyniki pośrednich wywołań (np. dane klientów, adresy, faktury itp.) w lokalnej bazie danych nowego rozwiązania. Najpierw zbudujesz tak cache danych (podręczną kopię dla nowej aplikacji), który w przyszłości może być użyty jako główna baza danych (jeśli wszystko znajdzie się w cache). W ten sposób użytkownicy, korzystając z nowego rozwiązania zmigrują część lub większość danych za Ciebie. Dodatkową korzyścią jest fakt, że tylko potrzebne dane będą migrowane, "martwe" dane nie będą ruszane i mogą być zarchiwizowane po jakimś czasie.

Wdrożenie

1. W zależności od tego, ilu użytkowników korzystało z Twojej starej aplikacji, musisz odpowiednio dostosować strategię wdrożenia.

   1. Niewielu użytkowników

      Jeśli zrobiłeś wszystko dobrze, nowy system powinien obsługiwać ich lepiej niż ten starszy.

   2. Wielu użytkowników

      1. Przygotuj się na bitwę 😉
      2. Przetestuj wydajnościowo swój front do systemu legacy
      3. Spróbuj wcześniej zmigrować (jeśli to możliwe) część / większość danych
      4. Zrób wdrożenie pilotażowe - tylko dla wybranych grup użytkowników (najlepiej jeśli reprezentują oni wszystkie typy / rodzaje / role użytkowników Twojej dotychczasowej aplikacji)
2. W zależności od kontekstu można rozważyć równoległe działanie obu systemów (nowego i starego) obok siebie przez 3/6 miesięcy (lub więcej, w zależności od krytyczności i Twojego akceptowalnego poziomu ryzyka).
3. Przeznacz czas na szkolenia (dla użytkowników wewnętrznych). Stare oprogramowanie może być wolne, może "wywalać" się w losowych momentach, ale to znany "wróg", po którym użytkownicy wiedzą czego się spodziewać. Nowe oprogramowanie, niezależnie od tego jak bardzo jest przyjazne, będzie dla Twoich pracowników czymś nowym i nie wszyscy muszą od razu się w nim odnaleźć.

Przygotuj się na nowe funkcje

W dalszym rozwoju warto dać szansę użytkownikom (czy to pracownikom, czy klientom). Bądź zwinny - pozwól swoim użytkownikom zdecydować, które funkcje zmigrować - może nie potrzebują wszystkiego. Stary system może odzwierciedlać potrzeby, które istniały, gdy był budowany i używany początkowo, ale może dziś zawiera implementację procesów, które nie są już nikomu potrzebne.

Podsumowanie - Oprogramowanie nie jest jak wino!

Oprogramowanie z wiekiem nie nabiera szlachetności. W miarę rozwoju firmy, jej ewolucji oprogramowanie musi rosnąć i być zmieniane / dostosowywane wraz z nią, aby wspierać jej aktualne potrzeby. Jeśli organizacja tego nie pilnuje, to kończy się jak z ogrodem, do którego nikt nie zagląda regularnie z kosiarką, grabiami czy czym tam (nie wiem nie jestem ogrodnikiem). W każdym razie, gdy ogród zarośnie to późniejsze przywrócenie go do stanu przyjemnego dla oka zajmuje sporo pracy i czasu.

Z mojego doświadczenia wynika, że takie podejście jak opisałem wyżej do opakowania starszego oprogramowania nowym i przyjaznym może zdziałać cuda w zakresie doświadczeń klientów, automatyzacji procesów, wydajności (zarówno z punktu widzenia IT, jak i biznesu). Na koniec to pieniądze, które system pomaga zaoszczędzić / zarobić przemówią najsilniej, że warto podjąć się takiego projektu by ostatecznie zastąpić system legacy czymś bardziej współczesnym.