Co zrobić, gdy stary system jest ważny, ale trudno go rozwijać
Jak odzyskać kontrolę nad ważną aplikacją legacy bez automatycznej decyzji o kosztownym przepisywaniu wszystkiego od początku.
Stary system nie jest problemem tylko dlatego, że używa starszej technologii. Problem zaczyna się wtedy, gdy firma nie potrafi bezpiecznie go zmieniać, diagnozować awarii albo przewidzieć kosztu kolejnego wdrożenia.
Najpierw ustal fakty
Audyt powinien objąć architekturę, zależności, bazę danych, proces wdrożeń, monitoring i najczęstsze incydenty. Celem jest mapa ryzyka, a nie katalog uwag stylistycznych.
Stabilizacja może być najlepszym pierwszym krokiem
Testy krytycznych ścieżek, lepsze logi, powtarzalny deployment i zabezpieczenie zadań w tle często szybko zmniejszają ryzyko. Dopiero wtedy łatwiej planować większe zmiany.
Modernizuj etapami
Nowe funkcje można wydzielać moduł po module, aktualizować poszczególne warstwy albo stopniowo przejmować ruch przez nową aplikację. Każdy etap powinien dostarczać samodzielną wartość.
Rewrite wymaga uzasadnienia ekonomicznego
Pełne przepisanie ma sens, gdy ograniczeń nie da się rozsądnie usunąć etapowo, a wartość biznesowa przewyższa koszt oraz ryzyko długiego okresu równoległego rozwoju.
Przykład: nowe zamówienia w starszej aplikacji
Załóżmy, że firma używa aplikacji WebForms i chce połączyć ją ze sklepem internetowym. Nie trzeba zaczynać od wymiany wszystkich ekranów. Pierwszy etap może obejmować wydzielone API, które przyjmuje zamówienie i przekazuje je do istniejącego procesu.
Ważne są reguły zapisu danych, identyfikator zamówienia chroniący przed duplikatami oraz możliwość ponowienia operacji po awarii. Dotychczasowy zespół nadal obsługuje zamówienia w znanym systemie, a nowy moduł można rozwijać osobno.
To scenariusz poglądowy — zakres migracji zależy od zależności i sposobu działania konkretnej aplikacji.
Co powinno zostać po audycie
- Lista najważniejszych ryzyk z opisem skutków dla firmy.
- Mapa zależności aplikacji, bazy, integracji i zadań w tle.
- Propozycja pierwszego etapu z zakresem i kryteriami odbioru.
- Sposób wdrożenia, migracji danych i wycofania zmiany.
- Założenia potrzebne do wyceny kolejnych prac.
Raport powinien pomagać wybrać działanie. Sama lista przestarzałych bibliotek nie odpowiada na pytanie, co zrobić w pierwszej kolejności.
Po czym ocenić poprawę
Wybierz konkretny scenariusz: publikację nowej wersji, wykonanie raportu albo dodanie funkcji. Sprawdź czas, liczbę ręcznych czynności i awarie związane z tą operacją. Po zmianie porównaj ten sam scenariusz przy podobnym obciążeniu i danych.
Poznaj zakres rozwoju i modernizacji aplikacji .NET. Pojęcia takie jak API i modernizacja systemów legacy znajdziesz w słowniczku.
Napisz do mnie
Rozważasz automatyzację podobnego procesu?
Opisz krótko sytuację. Wrócę z rekomendacją rozsądnego pierwszego kroku — bez prezentacji sprzedażowej i bez zobowiązań.