Dyrektor operacyjny ubezpieczyciela ma na biurku trzecią w tym roku zmianę regulacyjną, którą trzeba wprowadzić do systemu polisowego. System ma kilkanaście lat, działa na frameworku, którego nikt już nie uczy, a dwóch programistów, którzy rozumieją jego rdzeń, za rok przechodzi na emeryturę. Każda zmiana trwa kwartał, testy są ręczne, a wdrożenie odbywa się raz na dwa miesiące w nocy z soboty na niedzielę. CTO wie, że system trzeba zmodernizować. Zarząd też to wie, ale zadaje dwa pytania, na które nie ma dobrej odpowiedzi: ile to będzie kosztować i czy przez ten czas firma będzie w stanie normalnie działać.
To uczciwe pytania, a najgorszą odpowiedzią na nie jest jedna liczba i jeden termin. Projekty modernizacyjne, które obiecują wymianę całego systemu w ciągu roku za z góry ustaloną kwotę, często kończą się tak samo: po półtora roku firma utrzymuje dwa systemy, nowy nie umie jeszcze wszystkiego, co stary, a budżet jest wydany. Modernizacja, która działa, wygląda inaczej: jest serią mniejszych etapów, z których każdy ma osobny koszt, osobny efekt dla biznesu i punkt, w którym można się zatrzymać.
Na blogu opisaliśmy już, kiedy przebudować, refaktoryzować, a kiedy wymienić system dziedziczony, oraz jak odzyskiwać kod legacy. Ten tekst jest dla CTO, który ma już decyzję o modernizacji i potrzebuje dwóch rzeczy: planu etapów, który nie zatrzyma biznesu, i sposobu na policzenie budżetu przed rozmową z dostawcami.
Dlaczego modernizacja legacy jest dziś decyzją budżetową, a nie tylko techniczną?
Bo koszt pozostania przy starym systemie rośnie, nawet jeśli nie widać go w żadnej osobnej pozycji. Rośnie w czasie potrzebnym na każdą zmianę, w ryzyku związanym z odejściem ostatnich osób, które system rozumieją, w kosztach licencji i wsparcia dla starych platform, w lukach bezpieczeństwa, których nie da się już załatać, i w funkcjach, których biznes nie dostaje, bo zespół całe swoje moce wydaje na utrzymanie.
Skalę tego zjawiska dobrze pokazuje sektor publiczny w USA, który regularnie mierzy własne koszty. Amerykański Government Accountability Office w raporcie GAO-19-471 z 2019 roku wskazał, że z ponad 90 mld dolarów planowanych rocznie na IT przez rząd federalny około 80 procent idzie na eksploatację i utrzymanie istniejących systemów. GAO przeanalizował 65 systemów legacy i wskazał 10 najbardziej krytycznych, w wieku od 8 do 51 lat. Firmy prywatne nie publikują takich zestawień, ale mechanizm jest ten sam: im starszy system, tym większa część budżetu IT idzie na to, żeby działał, a mniejsza na to, żeby dawał przewagę.
Dlatego rozmowę z zarządem warto zacząć nie od kosztu modernizacji, tylko od kosztu status quo. Ile trwa i kosztuje typowa zmiana dziś? Ile kosztuje wsparcie dla starej platformy i ile będzie kosztować za dwa lata? Co się stanie, jeśli odejdą dwie kluczowe osoby? Jakich inicjatyw biznesowych nie da się zrealizować na obecnym systemie? Te liczby rzadko są precyzyjne, ale nawet przybliżone zmieniają pytanie z „czy stać nas na modernizację” na „czy stać nas na jej brak”.
Drugi powód, dla którego to decyzja budżetowa, jest bardziej praktyczny: modernizacja etapowa pozwala rozłożyć wydatek w czasie i finansować kolejne etapy z oszczędności i korzyści poprzednich. To zupełnie inna rozmowa z dyrektorem finansowym niż prośba o jednorazowy, wieloletni budżet na projekt, którego efekt będzie widać dopiero na końcu.
Jakie są opcje modernizacji: rehost, replatform, refactor i pozostałe?
Najczęściej używaną klasyfikacją opcji jest model 7R spopularyzowany przez AWS. Przewodnik AWS Prescriptive Guidance opisuje siedem strategii migracji: retire (wycofanie), retain (pozostawienie), rehost, relocate, repurchase (zakup gotowego produktu), replatform i refactor. Choć przewodnik dotyczy migracji do chmury, ta sama siatka pojęć dobrze opisuje decyzje modernizacyjne w ogóle.
Rehost, czyli lift and shift. Aplikacja trafia na nową infrastrukturę bez zmian w kodzie. To najszybsza i najtańsza opcja, która rozwiązuje problemy infrastrukturalne (koniec wsparcia sprzętu, koszty centrum danych), ale nie zmienia niczego w tym, jak trudno rozwija się system.
Replatform. Ograniczone zmiany, które pozwalają skorzystać z nowej platformy: przejście na zarządzaną bazę danych, przeniesienie do kontenerów, aktualizacja środowiska uruchomieniowego. Architektura zostaje, ale koszty utrzymania i ryzyko infrastrukturalne spadają.
Refactor, czyli re-architektura. Zmiana architektury aplikacji, na przykład wydzielenie usług z monolitu albo przebudowa modułów tak, żeby można je było rozwijać niezależnie. AWS wprost nazywa to najbardziej złożoną i kosztowną ze strategii i dla dużych migracji zaleca najpierw przenieść aplikację prostszą metodą, a modernizować ją dopiero po migracji.
Repurchase, retire, retain. Część funkcji starego systemu warto zastąpić gotowym produktem, część wyłączyć, bo nikt z nich nie korzysta, a część zostawić bez zmian, bo działa i nie blokuje biznesu. Te trzy opcje są często pomijane, a to one najbardziej obniżają koszt całości: każdy moduł, którego nie trzeba przebudowywać, to pieniądze dostępne dla tych, które naprawdę tego wymagają.
Szczegółową macierz decyzji między przebudową, refaktoryzacją i wymianą znajdziesz w osobnym tekście. Tutaj najważniejsze jest jedno: te opcje nie wykluczają się w skali całego systemu. Dobry plan modernizacji przypisuje je do poszczególnych modułów.
Jak wybrać strategię dla każdego modułu, a nie dla całego systemu?
Najdroższy błąd w modernizacji to jedna decyzja dla całego systemu: „przepisujemy wszystko” albo „przenosimy wszystko do chmury”. Systemy legacy nie są jednorodne. Mają moduły, które są stabilne i rzadko się zmieniają, moduły, które zmieniają się co miesiąc i blokują biznes, oraz moduły, z których prawie nikt już nie korzysta.
Praktyczna metoda zaczyna się od mapy systemu z dwiema osiami: wartość biznesowa i częstotliwość zmian z jednej strony, stan techniczny i ryzyko z drugiej. Moduł, który zmienia się często, ma dużą wartość i jest w złym stanie, to kandydat do refaktoryzacji albo wydzielenia w pierwszej kolejności. Moduł stabilny, rzadko zmieniany i w znośnym stanie zwykle wystarczy przenieść (rehost albo replatform) i zostawić. Moduł o niskiej wartości to kandydat do wycofania, a funkcja, którą dobrze realizują gotowe produkty, na przykład obieg dokumentów czy rozliczenia płacowe, to kandydat do zakupu.
Do tej mapy potrzebne są dane, a nie opinie. Historia zmian w repozytorium pokazuje, które moduły zmieniają się najczęściej. Zgłoszenia i incydenty pokazują, gdzie są problemy. Audyt kodu pokazuje stan techniczny, zależności i dług technologiczny w poszczególnych częściach. Rozmowy z użytkownikami biznesowymi pokazują, gdzie system realnie spowalnia firmę. Pomocna bywa też nasza lista kontrolna długu technicznego, która porządkuje pierwsze pytania.
Osobną uwagę warto poświęcić modułom, z których nikt nie korzysta. W starych systemach takich funkcji bywa zaskakująco dużo: raporty generowane dla działu, którego już nie ma, ścieżki obsługi produktów wycofanych lata temu, integracje z partnerami, z którymi firma dawno nie współpracuje. Dane o użyciu, zebrane z logów albo z prostego licznika wywołań włączonego na kilka tygodni, pozwalają je wskazać bez dyskusji opartych na przeczuciach. Każda taka funkcja wyłączona przed modernizacją to mniej kodu do zrozumienia, przetestowania i przeniesienia.
Wynikiem jest lista modułów z przypisaną strategią i kolejnością. Ta lista jest podstawą zarówno planu etapów, jak i budżetu, bo koszt modernizacji to w praktyce suma kosztów poszczególnych modułów plus koszt infrastruktury, która pozwala im współistnieć.
Na czym polega wzorzec strangler fig i dlaczego pozwala modernizować bez zatrzymywania biznesu?
Nazwa pochodzi od figowców dusicieli, które wyrastają na drzewie gospodarzu i stopniowo je zastępują. Martin Fowler opisał to podejście w tekście Strangler Fig Application jako alternatywę dla wymiany systemu w jednym kroku: zaczyna się od niewielkich dodatków, często nowych funkcji, budowanych obok starego kodu, a następnie kolejne fragmenty zachowania przenosi się ze starego systemu do nowego. Fowler zaznacza, że kod przejściowy, który pozwala obu systemom współistnieć, kosztuje, ale ten koszt jest wart obniżenia ryzyka i wcześniejszego dostarczania wartości.
W praktyce wygląda to tak. Przed starym systemem staje warstwa pośrednia: brama API, proxy albo warstwa integracyjna, przez którą przechodzi ruch. Na początku przekazuje ona wszystko do starego systemu. Gdy pierwszy moduł zostaje przebudowany i przetestowany, warstwa zaczyna kierować do niego część ruchu, na przykład dla jednej grupy klientów albo jednego typu operacji. Gdy nowy moduł sprawdzi się na produkcji, przejmuje całość, a odpowiadający mu fragment starego systemu zostaje wyłączony.
Dlaczego to pozwala nie zatrzymywać biznesu? Bo w każdym momencie działa system, który obsługuje wszystkie procesy, a każda zmiana jest mała i odwracalna. Jeśli nowy moduł zachowuje się źle, ruch wraca do starego w ciągu minut, a nie po tygodniach naprawy. Biznes widzi postęp co kilka miesięcy, a nie po dwóch latach.
Strangler fig ma też ograniczenia, o których warto wiedzieć przed startem. Wymaga warstwy pośredniej i kodu przejściowego, które trzeba zbudować i utrzymywać. Jest trudniejszy, gdy stary system nie ma wyraźnych punktów wejścia, a logika biznesowa siedzi w procedurach składowanych bazy danych. I wymaga dyscypliny: jeśli nikt nie pilnuje wyłączania starych części, po kilku latach firma ma dwa systemy zamiast jednego. Podobne pytania pojawiają się przy dekompozycji monolitu, którą opisujemy w przewodniku po migracji z monolitu do mikroserwisów.
Jak wygląda plan etapów modernizacji, od oceny do wyłączenia starego systemu?
Poniższy plan to ramy, które warto dopasować do własnego systemu. Każdy etap ma swój cel, rezultat i moment decyzji, czy iść dalej.
Etap 0: ocena i mapa systemu. Audyt kodu, architektury, infrastruktury i danych, inwentarz integracji, rozmowy z użytkownikami i właścicielami procesów. Rezultat: mapa modułów z przypisaną strategią, lista ryzyk, wstępny plan etapów i szacunek budżetu z przedziałami. To zwykle kilka tygodni i jedyny etap, który warto kupić w stałej cenie, zanim zobowiążesz się do czegokolwiek więcej.
Etap 1: fundamenty. Testy charakteryzujące wokół krytycznych ścieżek, czyli testy, które utrwalają obecne zachowanie systemu, zanim ktokolwiek je zmieni. Automatyczny pipeline wdrożeń, monitoring, warstwa pośrednia do kierowania ruchem. Często także rehost albo replatform całości, jeśli infrastruktura jest pilnym problemem. Ten etap nie daje nowych funkcji, ale bez niego każdy kolejny jest ryzykowny.
Etap 2: pilotaż. Modernizacja pierwszego modułu: takiego, który ma dużą wartość biznesową, ale ograniczone zależności. Pilotaż sprawdza w praktyce całe podejście: architekturę docelową, sposób migracji danych, przekierowanie ruchu, współpracę zespołów. Jego prawdziwy koszt i czas trwania są najlepszą podstawą do wyceny kolejnych etapów.
Etap 3: kolejne moduły. Modernizacja następnych modułów według ustalonej kolejności, każdy z własnym budżetem i kryteriami odbioru. Po każdym module warto zweryfikować plan: priorytety biznesowe się zmieniają, a część modułów może okazać się niepotrzebna.
Etap 4: wyłączenie starego systemu. Ostatnie moduły, migracja pozostałych danych, archiwizacja danych historycznych zgodnie z wymogami prawnymi, wyłączenie starej infrastruktury i licencji. Ten etap jest często pomijany w planach, a to on przynosi oszczędności, które uzasadniały całą modernizację.
Czas trwania etapów zależy od wielkości systemu i liczby modułów, dlatego nie podajemy tu sztywnych terminów. Ważniejsze od długości jest to, żeby każdy etap kończył się działającym rezultatem na produkcji i decyzją zarządu o kolejnym kroku, podjętą na podstawie faktów, a nie harmonogramu zapisanego dwa lata wcześniej.
Taki plan ma jedną ważną cechę: po każdym etapie firma jest w lepszym miejscu niż przed nim, nawet jeśli kolejny nigdy nie nastąpi. To zasadnicza różnica wobec projektu typu „wielki wybuch”, w którym wartość pojawia się dopiero na końcu, o ile w ogóle.
Ile kosztuje modernizacja systemu legacy i od czego zależy cena?
Nie ma rzetelnej odpowiedzi na pytanie o cenę bez oceny konkretnego systemu, i dostawca, który podaje kwotę po jednej rozmowie, zgaduje. Można natomiast dokładnie wskazać, co tę kwotę przesuwa. Poniższa tabela zbiera najważniejsze czynniki i sposób ich sprawdzenia.
| Czynnik ceny | Co podnosi koszt | Co obniża koszt | Jak sprawdzić przed wyceną |
|---|---|---|---|
| Wiedza o regułach biznesowych | Reguły tylko w kodzie, autorzy odeszli | Opisane procesy, dostępni eksperci dziedzinowi | Wywiady z właścicielami procesów, przegląd dokumentacji |
| Dane | Duże wolumeny, słaba jakość, wiele formatów | Czyste, opisane dane, jedno źródło | Profilowanie danych na próbce |
| Integracje | Wiele systemów, interfejsy nieopisane, wymiana plikami | Udokumentowane API, mało punktów styku | Inwentarz integracji z właścicielami |
| Testy | Brak testów automatycznych, testy tylko ręczne | Istniejące testy regresji krytycznych ścieżek | Raport pokrycia, lista scenariuszy testowych |
| Logika w bazie danych | Procedury składowane z regułami biznesowymi | Logika w warstwie aplikacji | Przegląd schematu i procedur |
| Strategia dla modułów | Refactor wszystkiego | Mieszanka retire, retain, rehost i refactor | Mapa modułów z przypisaną strategią |
| Wymogi dostępności | Zero przestojów, praca ciągła | Akceptowalne okna serwisowe | Uzgodnienie z biznesem dopuszczalnych przerw |
| Wymogi regulacyjne | Audyty, archiwizacja, walidacja systemów | Brak szczególnych wymogów | Lista wymogów prawnych i branżowych |
| Okres równoległego działania | Długie utrzymywanie dwóch systemów | Szybkie wyłączanie zmodernizowanych części | Plan wyłączeń w harmonogramie |
Dwa wiersze ważą zwykle najwięcej. Pierwszy to wiedza o regułach biznesowych: jeśli jedynym opisem tego, jak system liczy składkę albo rabat, jest kod sprzed dziesięciu lat, ktoś musi tę wiedzę odtworzyć, zanim ktokolwiek zbuduje nowy moduł, i to kosztuje więcej niż samo programowanie. Drugi to dane: migracja danych jest w wielu modernizacjach najbardziej czasochłonnym i najbardziej niedoszacowanym elementem.
Jak oszacować budżet modernizacji etapami?
Budżet modernizacji warto liczyć tak samo, jak się ją realizuje: etapami, z rosnącą dokładnością. Poniższy przykład pokazuje metodę i rzędy wielkości na podstawie stawek z naszych stron, a nie cennik całego projektu.
Etap 0: ocena. W ARDURA Consulting audyt kondycji kodu kosztuje od 18 000 PLN i trwa 1–2 tygodnie, a Technical Due Diligence, z oceną skalowalności, infrastruktury i zgodności licencji open source, od 35 000 PLN i trwa 2–3 tygodnie. Dla systemu legacy, który ma zostać zmodernizowany, ta druga opcja jest często trafniejsza, bo modernizacja dotyczy nie tylko kodu.
Etapy 1 i 2: fundamenty i pilotaż. Tu najlepiej liczyć koszt zespołu w czasie. Według naszej strony Software development typowy trzyosobowy zespół (dwóch programistów i QA) kosztuje około 62 000–123 000 PLN miesięcznie, zależnie od poziomu doświadczenia. Jeśli fundamenty i pilotaż zajmą takiemu zespołowi cztery miesiące, daje to około 248 000–492 000 PLN. Do tego dochodzą koszty infrastruktury i czas Twoich ludzi: ekspertów dziedzinowych, testerów biznesowych, administratorów.
Etap 3: kolejne moduły. Tu szacunek opiera się na wyniku pilotażu. Jeśli pierwszy moduł średniej wielkości zajął zespołowi trzy miesiące, a kolejne moduły są podobnej złożoności, masz realną jednostkę do przemnożenia, zamiast zgadywania. Dlatego budżet tego etapu warto zatwierdzać dopiero po pilotażu, z przedziałami, a nie jedną kwotą.
Etap 4: wyłączenie. Pozycja, o której łatwo zapomnieć: migracja pozostałych danych, archiwizacja, wygaszenie licencji i infrastruktury. Jednocześnie to tu pojawiają się oszczędności, które warto policzyć po stronie przychodów budżetu: koniec opłat za wsparcie starej platformy, mniejsze koszty infrastruktury, mniej czasu zespołu na utrzymanie.
Do każdego etapu warto dodać jawną rezerwę na ryzyko, nazwaną w budżecie wprost, a nie ukrytą w stawkach. Jej wysokość powinna maleć wraz z postępem: najwyższa przy pierwszym module, gdy niewiadomych jest najwięcej, niższa przy kolejnych, gdy zespół zna już system, dane i sposób przełączania ruchu. Jeśli dostawca nie umie wskazać, na co konkretnie jest przeznaczona rezerwa w jego ofercie, poproś o listę ryzyk, które ona pokrywa. Rezerwa bez listy ryzyk to po prostu wyższa cena.
Taki budżet ma dwie zalety w rozmowie z zarządem. Po pierwsze, zarząd zatwierdza na początku tylko to, co da się rzetelnie wycenić: ocenę i pilotaż. Po drugie, po pilotażu decyzja o kolejnych etapach opiera się na faktach z własnego systemu, a nie na obietnicach dostawcy.
Jak migrować dane bez przestoju?
Migracja danych to miejsce, w którym modernizacje najczęściej przekraczają budżet i terminy. Stary system zbierał dane przez lata, często w formatach i strukturach, które odzwierciedlają dawne wymagania, z duplikatami, wyjątkami i polami używanymi niezgodnie z nazwą.
Pierwszy krok to profilowanie danych: zanim ktokolwiek zaprojektuje migrację, trzeba wiedzieć, ile jest rekordów, jakiej jakości, z jakimi wyjątkami. Profilowanie na próbce kosztuje niewiele, a pozwala uniknąć sytuacji, w której w połowie projektu okazuje się, że jedna trzecia klientów ma niepoprawne adresy, a historia transakcji sprzed reformy systemu jest w innym formacie.
Drugi krok to wybór sposobu synchronizacji w okresie przejściowym. Przy podejściu strangler fig stary i nowy moduł działają jednocześnie, więc dane muszą być spójne w obu miejscach. Stosuje się do tego przechwytywanie zmian w bazie (change data capture), które przenosi zmiany ze starego systemu do nowego niemal na bieżąco, albo zapis do obu systemów naraz przez warstwę pośrednią. Każde z tych rozwiązań ma swoje koszty i ryzyka, ale oba pozwalają przełączać ruch bez długiego okna serwisowego.
Trzeci krok to uzgadnianie danych. Po migracji i w trakcie pracy równoległej trzeba regularnie porównywać dane w obu systemach: liczby rekordów, sumy kontrolne, wyniki tych samych obliczeń. Rozbieżności są nieuniknione, ważne, żeby wykrywać je automatycznie i wcześnie, a nie od klienta, który dostał dwa różne rachunki.
Warto też ustalić z góry, kto po stronie biznesu rozstrzyga rozbieżności. Nie każda różnica oznacza błąd nowego systemu: czasem to stary system przez lata liczył coś niepoprawnie, a wszyscy przyzwyczaili się do wyniku. Taka decyzja należy do właściciela procesu, nie do zespołu migracyjnego, i bez wskazanej osoby uzgadnianie danych potrafi stanąć na tygodnie.
Czwarty krok to decyzja, co z danymi historycznymi. Nie wszystko musi trafić do nowego systemu. Dane, które są potrzebne tylko do celów archiwalnych lub regulacyjnych, często taniej jest przenieść do archiwum z możliwością odczytu niż migrować do nowego modelu danych.
Jak zachować ciągłość działania w trakcie modernizacji?
Modernizacja bez zatrzymywania biznesu to nie tylko architektura, ale też zestaw praktyk, które chronią firmę przed skutkami błędów w trakcie zmian. Ciągłość działania musi być zaplanowana dla każdego etapu, a nie tylko dla końcowego przełączenia.
Najważniejsza praktyka to odwracalność. Każde przełączenie ruchu do nowego modułu powinno mieć prosty i przetestowany sposób powrotu: przełącznik w warstwie pośredniej, flagę funkcji, która wyłącza nową ścieżkę, albo możliwość przekierowania ruchu z powrotem do starego systemu. Jeśli powrót wymaga wdrożenia nowej wersji, nie jest wystarczająco szybki.
Druga praktyka to stopniowe przełączanie. Zamiast przekierować cały ruch naraz, zaczyna się od małej grupy: użytkowników wewnętrznych, jednego oddziału, kilku procent klientów. Przy każdym kroku obserwuje się błędy, wydajność i zgodność wyników ze starym systemem. Dopiero gdy wskaźniki są stabilne, zwiększa się udział nowego modułu.
Trzecia praktyka to praca równoległa dla procesów krytycznych. Dla obliczeń, w których błąd ma poważne skutki, na przykład naliczania składek, odsetek czy wynagrodzeń, warto przez jakiś czas liczyć wynik w obu systemach i porównywać rezultaty, zanim nowy system przejmie odpowiedzialność. To kosztuje, ale jest tańsze niż korekta tysięcy błędnych dokumentów.
Czwarta praktyka to zamrożenie zmian w starym systemie w obszarach, które są właśnie modernizowane. Jeśli zespół utrzymaniowy wprowadza zmiany w module, który inny zespół właśnie przebudowuje, obie wersje się rozjeżdżają, a migracja nigdy się nie kończy. Zmiany regulacyjne, których nie da się odłożyć, trzeba wtedy wprowadzać w obu miejscach i uwzględnić w budżecie.
Jakie pytania zadać dostawcy modernizacji i co zapisać w umowie?
Wybór dostawcy modernizacji to wybór metody, a nie tylko zespołu. Poniższe pytania pomagają ocenić, czy dostawca ma doświadczenie w modernizacji bez przestojów, czy tylko w budowie nowych systemów.
Jak wyceniacie modernizację przed oceną systemu? Dobra odpowiedź: płatna ocena w stałej cenie, potem wycena pilotażu, a dalsze etapy po pilotażu. Dostawca, który podaje stałą cenę za całą modernizację po kilku spotkaniach, albo zawyża ją o ryzyko, albo zamierza odzyskać różnicę w zmianach zakresu.
Jak zachowacie reguły biznesowe, które są tylko w kodzie? Szukaj odpowiedzi o testach charakteryzujących, analizie kodu i pracy z ekspertami dziedzinowymi, a nie o „zbieraniu wymagań od nowa”.
Jak będzie wyglądać przełączanie ruchu i powrót w razie problemów? Dostawca powinien opisać warstwę pośrednią, stopniowe przełączanie i procedurę powrotu, zanim zacznie mówić o nowej architekturze.
Jak migrujecie dane i jak sprawdzacie ich zgodność? Odpowiedź powinna obejmować profilowanie, synchronizację w okresie przejściowym i automatyczne uzgadnianie.
W umowie warto zapisać, że każdy etap ma własny zakres, kryteria odbioru i budżet, że prawa do kodu przechodzą na Ciebie na bieżąco, a nie na koniec projektu, że kod, dokumentacja i infrastruktura są na Twoich kontach od pierwszego dnia, oraz że po każdym etapie możesz zakończyć współpracę z udokumentowanym przekazaniem. Modernizacja trwa długo, a w tym czasie może się zmienić wiele, łącznie z dostawcą, więc warunki wyjścia są tu ważniejsze niż w zwykłym projekcie. Jak w praktyce wygląda zmiana dostawcy w połowie prac, opisujemy w tekście o zmianie dostawcy IT w trakcie projektu i planie przejęcia w 30 dni.
Jakie błędy najbardziej podnoszą koszt modernizacji?
Kilka błędów powtarza się w projektach modernizacyjnych na tyle często, że warto je znać przed startem.
Odwzorowanie starego systemu jeden do jednego. Zespół przenosi wszystkie funkcje, łącznie z tymi, z których nikt nie korzysta, i wszystkie dziwactwa, które powstały jako obejścia dawnych ograniczeń. Efekt: nowy system jest tak samo skomplikowany jak stary, tylko droższy. Przed przebudową każdego modułu warto sprawdzić, które funkcje są faktycznie używane.
Brak testów przed zmianami. Modernizacja bez testów utrwalających obecne zachowanie oznacza, że nikt nie wie, czy nowy moduł robi to samo co stary. Rozbieżności wychodzą na produkcji, u klientów.
Niedoszacowanie danych. Migracja zaplanowana jako jeden krok na końcu projektu, bez profilowania i bez okresu przejściowego, to najczęstsza przyczyna przekroczenia terminów.
Rozbudowa zakresu w trakcie. Modernizacja staje się okazją do zrealizowania wszystkich odłożonych pomysłów biznesowych. Każdy z nich może być sensowny, ale razem zamieniają projekt o jasnym celu w projekt bez końca. Lepiej oddzielić modernizację od rozwoju funkcjonalnego i dodawać nowe funkcje dopiero w zmodernizowanych modułach.
Modernizacja bez właściciela po stronie biznesu. Gdy projekt prowadzi wyłącznie IT, decyzje o tym, które funkcje są potrzebne, a które można wyłączyć, zapadają za wolno albo wcale. Każdy etap potrzebuje osoby z biznesu, która ma prawo powiedzieć „tej funkcji nie przenosimy” i „ten wynik jest poprawny”.
Brak wyłączania starych części. Gdy nikt nie odpowiada za wyłączanie zmodernizowanych fragmentów starego systemu, firma płaci za oba systemy dłużej, niż to konieczne, a oszczędności, które uzasadniały projekt, nie pojawiają się.
Jak ARDURA Consulting wspiera modernizację systemów legacy?
Modernizację systemów legacy realizujemy w ramach usługi Software Rescue, obejmującej m.in. migrację z monolitu do mikroserwisów, aktualizację frameworków i przeniesienie do chmury. Zaczynamy zawsze od oceny, bo bez niej każda wycena i każdy harmonogram są zgadywaniem: audyt kondycji kodu kosztuje od 18 000 PLN i trwa 1–2 tygodnie, a Technical Due Diligence od 35 000 PLN i trwa 2–3 tygodnie. Wynikiem jest raport z oceną ryzyk i plan działań, który należy do Ciebie niezależnie od tego, kto będzie go realizował.
W projektach ratunkowych i modernizacyjnych pracują u nas tylko seniorzy, którzy znają systemy legacy i umieją czytać cudzy kod. Jeśli po ocenie zdecydujesz się realizować modernizację z nami, możemy to zrobić w ramach Software development jako zespół dedykowany albo wzmocnić Twój zespół specjalistami w modelu body leasingu, z dwutygodniową gwarancją satysfakcji i bezpłatną wymianą specjalisty. Jeśli wolisz realizować plan samodzielnie albo z innym dostawcą, raport i plan etapów są Twoje.
Co zapamiętać, zanim zatwierdzisz budżet modernizacji?
Modernizacja systemu legacy nie musi być wieloletnim projektem z jedną kwotą i jednym terminem, który zatrzymuje biznes. Może być serią etapów, z których każdy kosztuje tyle, ile da się rzetelnie wycenić, i każdy zostawia firmę w lepszym miejscu.
Zapamiętaj pięć rzeczy. Po pierwsze, zacznij od kosztu status quo, bo to on uzasadnia modernizację przed zarządem. Po drugie, wybieraj strategię dla każdego modułu osobno: część przebuduj, część przenieś, część kup, a część wyłącz. Po trzecie, modernizuj stopniowo, ze wzorcem strangler fig, warstwą pośrednią i możliwością powrotu przy każdym przełączeniu. Po czwarte, licz budżet etapami: płatna ocena, pilotaż, a dopiero potem wycena kolejnych modułów na podstawie faktów z pilotażu. Po piąte, traktuj migrację danych i wyłączanie starych części jako pełnoprawne etapy z budżetem, a nie dodatki na końcu.
Jeśli planujesz modernizację i chcesz zacząć od rzetelnej oceny systemu, zobacz pakiety audytu kodu i Technical Due Diligence albo umów rozmowę. Powiemy, który rodzaj oceny pasuje do Twojego systemu i jak mógłby wyglądać pierwszy etap modernizacji.