Stara aplikacja ma złą opinię, bo jest powolna, trudna w zmianie i pamięta kilka poprzednich etapów firmy. To jeszcze nie dowód, że trzeba od razu napisać ją od nowa. Może przechowywać ważne reguły, których nie ma w dokumentacji, a użytkownicy nauczyli się obchodzić jej ograniczenia. Modernizacja powinna zacząć się od rozpoznania, co rzeczywiście działa i co powoduje koszt. Wielki reset bez tej wiedzy potrafi odtworzyć stare problemy w nowszej technologii.
Zbierzcie konkretne objawy: wolne zadanie, częste błędy, trudność wdrożenia albo brak możliwości zmiany dostawcy. Każdy z tych problemów może wymagać innego działania. Nie należy zakładać, że wymiana interfejsu naprawi model danych, a nowa baza usunie niejasne zasady pracy. Jeśli aplikacja ma nadal obsługiwać firmę podczas zmian, potrzebny jest plan zachowania ciągłości połączony z docelową architekturą.
Odtwórz stan, zanim zaczniesz go poprawiać
Pierwszy etap powinien ustalić, gdzie znajduje się kod, która wersja działa i jak przygotowuje się wydanie. Sprawdźcie konta, dane oraz połączenia z innymi usługami. Tematy przekazania i utrzymania aplikacji wracają tu w praktycznej formie. Bez dostępu do potrzebnych elementów trudno zaplanować zmianę, a jeszcze trudniej wycofać ją po nieudanej próbie. Dokumentacja może wymagać aktualizacji, ale najpierw trzeba potwierdzić, co naprawdę opisuje.
Zobaczcie również, jak użytkownik wykonuje najważniejsze zadania. Czasem dodatkowy arkusz przechowuje regułę, której system nigdy nie obsługiwał. Czasem pracownik pomija krok, który przestał być potrzebny po zmianie procesu. Podobnie jak przy zamawianiu nowej aplikacji, konkretny przykład daje lepszy materiał niż ogólna lista wad. Modernizacja nie powinna automatycznie utrwalać wszystkich przyzwyczajeń, ale musi rozumieć, jaką potrzebę dziś zaspokajają.
Wybierz granicę pierwszej zmiany
Można zacząć od jednego modułu, poprawy wydajności ważnej ścieżki albo uporządkowania integracji. Zakres powinien mieć rozpoznawalny rezultat i sposób sprawdzenia. Jeśli aplikacja przepisuje dane między programami, przejrzyjcie źródła prawdy oraz identyfikatory. Część problemów może wynikać z niejasnej odpowiedzialności za informację, a nie z wieku użytej biblioteki. Zmiana technologii bez tej decyzji zostawiłaby rozbieżność na swoim miejscu.
Warto też porównać warianty działania i ich konsekwencje dla kosztu projektu. Naprawa wybranego fragmentu może być rozsądna, jeśli reszta systemu spełnia potrzeby firmy. Przebudowa większej części może być uzasadniona, jeśli ograniczenia są głębsze i zostały potwierdzone. Decyzja powinna wynikać z rozpoznania i celu, a nie z ogólnego przekonania, że każda starsza aplikacja przeszkadza nowoczesnej organizacji.
Zabezpiecz zachowania, których firma nadal potrzebuje
Przed zmianą przygotujcie przykłady ważnych zadań i wyniki, których oczekujecie. Dotyczy to także wyjątków, uprawnień oraz dokumentów wymienianych z innymi systemami. Taki zestaw pomaga zauważyć, że poprawka jednego modułu naruszyła inny. Nie trzeba od razu opisywać całej historii aplikacji. Trzeba jednak zabezpieczyć to, na czym opiera się aktualna praca. Brak testów nie staje się mniej istotny dlatego, że dotyczy starego kodu.
Jeżeli zmieniają się dane, zaplanujcie migrację, kontrolę kompletności oraz sposób postępowania przy rozbieżności. Przydatna jest próba na uzgodnionym środowisku, zanim zaczniecie przetwarzać dane produkcyjne. Ustalcie również, czy i jak można wycofać zmianę. Cofnięcie plików programu nie zawsze cofa operacje wykonane na danych. Ten związek powinien być rozpoznany wcześniej, zamiast ujawniać się dopiero w rozmowie podczas pierwszego poważnego problemu.
Po wydaniu obserwuj to, co ma znaczenie dla pracy
Błędy, czas wykonania zadania i wynik integracji pomagają ocenić zmianę po uruchomieniu. OpenTelemetry opisuje rolę sygnałów takich jak metryki, logi i ślady w poznawaniu zachowania systemu. Dobór narzędzi powinien wynikać z tego, jakie pytania zespół musi rozstrzygać. Samo gromadzenie dużej ilości zapisów nie zapewni szybkiej diagnozy, jeśli nikt nie wie, gdzie szukać informacji o konkretnej sprawie.
Przydatnym wynikiem pierwszego etapu może być także usunięcie jednego ręcznego obejścia. Użytkownik powinien wiedzieć, który stary sposób przestaje być potrzebny i jak sprawdzić rezultat nowego działania. Bez tego firma utrzymuje równolegle aplikację i dodatkowe notatki, nie mając pewności, której wersji zaufać. Dobrze zaplanowana zmiana usuwa więc także określony fragment dotychczasowego wysiłku zespołu.
Każdy etap powinien mieć własny odbiór i decyzję o dalszej pracy. Archifutura może pomóc rozpoznać istniejące oprogramowanie firmowe i zaplanować modernizację bez niepotrzebnego zatrzymania całego procesu. Na rozmowę o przejęciu aplikacji przygotuj opis najważniejszego problemu oraz dostępne materiały techniczne. Celem pierwszego kroku jest odzyskanie kontroli nad zmianą, nie ogłoszenie, że od dziś wszystko musi powstać jeszcze raz.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
