Modernizacja systemów
Dysponują Państwo dużym, działającym systemem, który wymaga uaktualnienia lub dalszej rozbudowy? Szukacie Państwo rzetelnego wykonawcy w dziedzinie migracji systemów Legacy?
Zależnie od wymagań biznesowych oraz możliwości technicznych do tematu można podejść na wiele różnych sposobów. W poniższym opracowaniu postaramy się przybliżyć kilka rozwiązań, bazując na naszym doświadczeniu.
Głównymi czynnikami mającymi wpływ na sposób migracji / modernizacji / unowocześnienia są:
- Ciągłość działania
- Sposób przetwarzania danych
- Wymagania dotyczące security
- Zmiany infrastrukturalne, sieciowe
- Wymagania prawne, bezpieczeństwa, podmiotów trzecich
- Zmiany struktury przedsiębiorstwa
- Wymagany termin modernizacji
- Zmiany warunków współpracy z podmiotami trzecimi
- Istniejące powiązania pomiędzy innymi systemami
Kiedy pisać od nowa?
Jeśli istniejący projekt cały czas sprawnie działa, wymagamy od niego ciągłości działania, a jednocześnie istnieje czas i środki na równoległe rozwijanie bliźniaczego systemu, który docelowo zastąpi istniejące rozwiązanie — można tworzyć nowy system.
Rozwiązanie takie pozwala na skoncentrowaniu się na eliminacji problemów, wąskich gardeł, błędów architektonicznych pierwowzoru już na etapie planowania. Nie mamy żadnych ograniczeń co do sposobu wymiany danych WEWNĄTRZ takiego systemu — otwiera to możliwości na zupełnie nowe rozwiązania.
Projekt pisany "od nowa", pozbawiony jest również długu technologicznego (eng. technical debt) - wszystkie języki, frameworki czy biblioteki dobiera się w aktualnych, wspieranych wersjach, z myślą o późniejszym, wieloletnim utrzymaniu.
Faza przejściowa
W przypadku niektórych systemów nie można dłużej utrzymywać starszej wersji, ale też nie ma możliwości szybkiego wdrożenia nowego odpowiednika. W takiej sytuacji dobrą praktyką może okazać się stopniowe modernizowanie poszczególnych elementów systemu, wymiana niektórych mniejszych modułów w całości czy nawet rafaktoryzacja pierwotnych rozwiązań.
Zaletą takiego podejścia jest niemal natychmiastowy zysk z modernizacji — poszczególne elementy systemu zaczynają działać wydajniej, można podjąć się dodawania nowych funkcjonalności i całość robi się stopniowo prostsza w dalszym utrzymaniu.
Wadą takiego podejścia jest ograniczona ścieżka migracyjna w zakresie architektury — przykładowo trudno w ten sposób przerobić monolityczną aplikację SSR, na SPA, ale jest to technicznie możliwe.
Migracja projektu do innego wykonawcy
Czasami powodem przekazania projektu innej firmie nie są zagadnienia stricte techniczne, ale przykładowo — brak możliwości dalszego rozwoju pod skrzydłami bieżącego wykonawcy.
W takiej sytuacji możemy rozpatrywać kilka scenariuszy takich jak:
Rzetelny wykonawca, który np. nie ma już czasu na projekt
Takie podejście najczęściej jest dalszym życiem udanego projektu, który musi nabrać nowego tempa rozwoju. Dzięki dobrej atmosferze najczęściej udaje się wspólnie wypracować pola do współpracy takie jak:
- Możliwość transferu wiedzy
- Etap przejściowy wspólnej pracy
- Stopniowe wygaszanie udziału poprzedniego wykonawcy
Nierzetelny wykonawca, który np. porzucił projekt
W takich sytuacjach klient najczęściej zostaje pozostawiony samemu sobie, a to zaś może generować problemy przy przejmowaniu opieki nad projektem:
- Brak dokumentacji
- Utrudnianie wdrożenia się nowej firmy
- Brak pełnego kodu źródłowego, danych dostępowych
W takiej sytuacji bardzo ważna jest bliska współpraca z klientem — otwartość na nowe pomysły i chęć uzupełnienia ewentualnych braków w projekcie.
Niestety zdarza się również, że klient nie posiada wiedzy projektowej i wówczas lepszym wyjściem jest tworzenie takiego systemu od nowa — o ile jest to możliwe.
Bieżący support i rozwój
Niekiedy zdarza się, że projekt sprawnie funkcjonuje, jest dopracowany i nie potrzebuje modernizacji — pojawia się za to potrzeba bieżącego utrzymania i stopniowego, zrównoważonego rozwoju.
W takim scenariuszu warto w początkowym etapie dokładnie poznać aplikację, zweryfikować aktualność i szczegółowość dokumentacji. Jeśli zajdzie taka potrzeba — stworzyć lub rozbudować testy aplikacyjne — co będzie pomocne w dalszym rozwoju w przyszłości.
Wdrażając nowe funkcjonalności, trzeba mieć na względzie konieczność zachowania stabilności całości systemu, jego integralność, a także zachowania dotychczasowych wymagań. Często wymusza to pewne ograniczenia w sposobie tworzenia nowych features, ale przestrzeganie tych ograniczeń odwdzięcza się bezproblemową pracą całego systemu.
Najczęściej do prac związanych z bezpośrednim utrzymaniem należą:
- Aktualizacje bezpieczeństwa
- Migracje kodu źródłowego do nowych wymagań
- Eliminacja błędów zgłaszanych przez użytkowników
- Reagowanie na incydenty
- Moderacja treści tworzonych przez użytkowników
- Inne prace zapewniające ciągłość działania
Dlaczego warto uaktualniać systemy IT
Na koniec warto zapamiętać jakie korzyści daje stale utrzymywany i modernizowany system:
- Zapewnienie odpowiedniego poziomu bezpieczeństwa
- Dostosowanie oprogramowania do zmieniających się wymagań
- Niwelowanie długu technologicznego (eng. technical debt)
- Zdobywanie / utrzymanie przewagi technologicznej nad konkurencją
Propozycja desi9n.pl w zakresie modernizacji systemów IT
Utrzymujemy, refaktoryzujemy, migrujemy oraz modernizujemy istniejące systemy / oprogramowanie. Do naszych działań należy między innymi:
- Wyszukiwanie i naprawianie "wąskich gardeł systemu"
- Dostosowanie interfejsu do urządzeń mobilnych
- Poprawa wydajności działania
- Tworzenie instancji aplikacji opartych o Docker
- Integracja z innymi systemami
- Refaktoryzacja kodu do nowych wersji języków / bibliotek
- Tworzenie API i komunikacji sieciowej
- I wiele innych – w zależności od wymagań projektu