Migracja z legacy w 90 dni ma sens tylko wtedy, gdy kupujesz kontrolowany eksperyment produkcyjny, a nie początek wielkiej odnowy całego krajobrazu IT. Jeśli pierwszy etap nie jest porównywalny ze starą ścieżką, odwracalny i ograniczony do jednego procesu albo jednej klasy integracji, projekt lepiej zatrzymać przed implementacją. Najczęściej to właśnie brak twardej granicy pierwszego etapu zamienia modernizację w kosztowny program bez wiarygodnego punktu decyzji.
Najwięcej błędów nie pojawia się przy wdrożeniu, tylko przy wyborze tego, co ruszyć najpierw. Zespoły biorą obszar najbardziej widoczny dla biznesu, choć realne ryzyko zwykle siedzi głębiej: w danych, wyjątkach operacyjnych, ręcznych obejściach i integracjach, których nikt nie potrafi już porządnie opisać. Kontrolę odzyskuje się nad wycinkiem systemu. Rdzenia z wieloletnimi zależnościami nie modernizuje się uczciwie w jednym krótkim etapie.
Kiedy etap 90 dni ma sens, a kiedy lepiej zatrzymać się na rozpoznaniu
Dobry kandydat na szybki etap spełnia trzy warunki. Obejmuje jeden proces albo jedną klasę integracji, da się go porównać ze starą ścieżką przez logi i testy, a po stronie biznesu istnieje właściciel zdolny podejmować decyzje bez wielotygodniowej ścieżki akceptacji.
Nie potrzeba pełnej obserwowalności całej platformy. Potrzebne jest minimum operacyjne: identyfikator transakcji, błędy, czas odpowiedzi, wolumen i możliwość sprawdzenia, czy nowa ścieżka działa co najmniej nie gorzej niż stara. Bez tego ograniczanie ryzyka pozostaje opinią, nie oceną.
Rollback też bywa źle rozumiany. To nie deklaracja w ofercie, tylko procedura: kto przełącza ruch, po jakim sygnale, w jakim czasie i co dzieje się z danymi zapisanymi przez nowy komponent. Jeżeli nie da się tego opisać przed implementacją, zakres jest za szeroki albo architektura przejściowa nadal nie została zaprojektowana.
Są układy, w których 90 dni po prostu nie ma sensu. Zwłaszcza tam, gdzie nakładają się ręczne obejścia poza systemem, brak wiarygodnych danych do porównania wyników, wiele krytycznych integracji bez testowalnych kontraktów i konieczność równoczesnej migracji logiki transakcyjnej oraz danych historycznych. W takim przypadku krótkie discovery nie jest opóźnieniem. To tańsza decyzja niż wejście w implementację na ślepo.
Jeśli częściej pojawia się brak odpowiedzi na pytania o dane, zależności i warunki przełączenia niż konkretne decyzje projektowe, implementacja jest przedwczesna. Kilka tygodni rozpoznania zwykle wystarcza, by zmapować wyjątki operacyjne, granice odpowiedzialności i warunki pierwszego etapu. Dopiero wtedy ma sens decyzja, czy iść w wydzielenie procesu, warstwę pośrednią czy szersze przepisanie.
Przy takim wyborze pomaga też rozróżnienie, czy problem wymaga etapowej zmiany, czy jednak głębszego resetu architektury. Dobrze porządkuje to materiał refaktoryzacja czy przepisanie kodu.
Jak wybrać pierwszy zakres, żeby nie utknąć w przepisywaniu wszystkiego
Pierwszy etap nie powinien być najbardziej efektowny. Powinien dać mierzalny efekt operacyjny przy ograniczonym promieniu awarii. Najlepszym kandydatem bywa obszar, który dziś generuje ręczne korekty, incydenty albo blokuje wdrożenia, ale da się go odgrodzić interfejsem, kolejką, osobnym API lub kontrolą zapisu.
Często dobrym wyborem okazuje się niestabilna integracja z systemem zewnętrznym albo fragment walidacji biznesowej, który produkuje wyjątki i eskalacje. Zaskakująco rzadko najlepszym pierwszym ruchem jest interfejs użytkownika. Front jest widoczny, ale w systemach legacy źródło kosztu zwykle siedzi tam, gdzie użytkownik go nie widzi.
W dystrybucji hurtowej, przy organizacji obsługującej kilka magazynów i integrację z ERP, próba ruszenia całego modułu zamówień na starcie ugrzęzła nie na kodzie, tylko na wyjątkach operacyjnych i ręcznych korektach po stronie back office. Tarcie wdrożeniowe okazało się ważniejsze niż sam koszt programistów: bez odseparowania walidacji limitów i komunikacji z ERP każdy test kończył się sporem o dane i odpowiedzialność za wynik. Taki zakres wygląda ambitnie w planie, ale operacyjnie jest zły na pierwszy etap.
Wybór między API facade, adapterem a wydzieleniem procesu zależy od miejsca, w którym dziś kumuluje się ryzyko. Gdy stary system liczy poprawnie, ale jego interfejs blokuje zmianę kontraktów i tempa wdrożeń, sens ma facade. Gdy awarie wynikają głównie z formatów danych, timeoutów, kolejkowania i niestabilnych połączeń, lepszy będzie adapter integracyjny. Jeśli problem siedzi w regułach biznesowych, które można odseparować od reszty i uruchomić na ograniczonym zbiorze danych, wtedy warto wydzielić proces do osobnej usługi. Moda na wzorzec nie obniża ryzyka. Obniża je dopiero zgodność wzorca z faktycznym źródłem awarii i kosztem cofnięcia zmiany.
Wzorzec strangler, opisywany między innymi przez Microsoft Azure Architecture Center, działa wtedy, gdy można przejmować ruch stopniowo i porównywać wyniki starej oraz nowej ścieżki. Nie działa dobrze tam, gdzie system opiera się na ciężkich wsadach, ukrytych krokach poza aplikacją i ręcznych korektach bez śladu w logach.
Najczęściej problemem nie jest samo legacy, tylko zbyt ambitny pierwszy etap modernizacji. Z tą tezą część dostawców się nie zgodzi, bo rynek nadal premiuje duże programy transformacyjne sprzedawane przed uczciwym ograniczeniem zakresu. Operacyjnie wygrywa jednak zespół, który potrafi odrzucić połowę pomysłów na start.
Jeżeli potrzebna jest warstwa pośrednia między starym rdzeniem a nowym komponentem, sensowny punkt odniesienia daje materiał o połączeniu systemu legacy z nowym produktem. Chodzi nie o sam wzorzec, tylko o ograniczenie sprzężeń przed większą zmianą.
Plan 30-60-90 dni: jakie decyzje muszą zapaść, żeby projekt miał sens
Dobry plan 90 dni nie składa się z trzech równych faz pod tytułem analiza, development i wdrożenie. Składa się z bramek decyzyjnych. Po każdej z nich projekt można zawęzić, zatrzymać albo dopuścić do kolejnego kroku bez utraty kontroli.
Do 30 dnia: granica zakresu i warunki przełączenia
Na początku trzeba ustalić rzeczy mało efektowne, ale krytyczne: granicę modułu, źródła danych, ręczne obejścia, minimalny zestaw testów regresji i sposób pomiaru wyniku. Jeśli monitoring nie istnieje, trzeba go uruchomić od razu.
Wyjściem z tego etapu powinny być konkretne artefakty: opis przepływu krytycznego, lista zależności synchronicznych i asynchronicznych, plan rollbacku z odpowiedzialnościami oraz decyzja, czy nowy komponent zapisuje dane samodzielnie, czy tylko odczytuje i publikuje zdarzenia. Brak tych elementów oznacza, że szeroka implementacja jest przedwczesna.
Jest jeszcze jeden warunek stop. Jeśli po pierwszym miesiącu nadal nie wiadomo, które wyjątki operacyjne są dopuszczalne, a które zatrzymują transakcję, projekt nie ma granicy ryzyka i nie powinien wejść w pełną implementację.
