<img height="1" width="1" src="https://www.facebook.com/tr?id=292546644544618&amp;ev=PageView&amp;noscript=1">

Wyłączanie aplikacji, czyli czas na wiosenne porządki w organizacji

Każda organizacja prędzej czy później staje przed problemem wyłączenia (decommissioningu) używanej przez siebie aplikacji. Dzieje się tak z różnych powodów.

Wyłączamy!

Dlaczego w ogóle warto rozważyć wyłączenie aplikacji? Aplikacja może nie przystawać już do rzeczywistości i zmieniających się wymagań biznesowych. Może to być np. związane z funkcjonalnością aplikacji lub z ergonomią korzystania z niej i interfejsem użytkownika. Dostosowanie aplikacji jest na tyle drogie i nie da wystarczająco dobrych efektów, aby jej zmiany były opłacalne. Należy więc wdrożyć nową aplikację, a starą wyłączyć.

Aplikacja może też po prostu stać się niepotrzebna. Być może obsługiwała produkt, którego już nie sprzedajemy i chcemy całkowicie wycofać z obsługi. Być może obsługiwała proces, który okazał się zbędny Być może w ciągu ostatnich 6 miesięcy nikt nie logował się do aplikacji. 

Możemy również spotkać się z duplikacją funkcji. Mamy inny (nowy, lepszy) system, który robi dokładnie te same rzeczy. Do takiej sytuacji może dojść na wiele sposobów. Jednym z nich jest połączenie się dwóch (lub więcej) organizacji działających w tej samej branży.

Utrzymanie aplikacji może być także zbyt drogie. Dzieje się tak w przypadku, kiedy koszty związane z obsługą aplikacji przewyższają korzyści wynikające z jej stosowania. Przyczyny tutaj mogą być tożsame z opisanymi powyżej. Mogą to być też kwestie długu technologicznego – aplikacje nieaktualizowane latami stają się dla IT z kilku powodów trudne w obsłudze. Trzeba utrzymywać kompetencje technologiczne, które mogą być związane z tą jedną aplikacją. Producenci oprogramowania i sprzętu mają politykę zmuszającą klientów do aktualizacji – koszty wsparcia starych wersji kilkukrotnie przewyższają koszt wsparcia dla nowych wersji.

Z wyłączanym systemem możemy zrobić kilka rzeczy. Możemy go po prostu wyłączyć i zapomnieć o nim. Jest to rzadki przypadek, gdyż najczęściej system jest zintegrowany z innymi i trzeba coś zrobić, aby istniejące procesy nie przestały działać. Często nie możemy tak postąpić też ze względów praktycznych – może wystąpić okoliczność (np. związana z reklamacją lub z zapytaniem od regulatora), gdy będziemy potrzebowali sięgnąć do danych.

Najczęstsza sytuacja to taka, gdy jednak będziemy chcieli zostawić pewne (być może wszystkie) funkcje systemu i jego dane. Funkcje możemy przenieść do nowego (lub nowych) oraz istniejących systemów. Za każdym razem będzie to wyglądało nieco inaczej. W przypadku danych możemy pójść śladem przenoszonych funkcji. Często jednak nie będziemy chcieli przenosić pełnej historii zmian w danych. Dane historyczne trafią do dedykowanego archiwum lub do hurtowni danych.

Ale to trudne…

Gdy organizacja dojrzewa do decyzji o powołaniu takiego projektu okazuje się, że nie jest to takie proste, jak mogłoby się wydawać. Najczęściej wyłączane są stare systemy i brakuje w organizacji osób, które mają pełny obraz ich wykorzystania – znają wszystkie powiązane procesy, integracje i przypadki użycia. To powoduje dyskomfort u podejmujących decyzję – co może przestać działać, gdy wyłączymy system? Jak krytyczne jest to dla organizacji? Czy będziemy w stanie szybko naprawić ten problem?

W następstwie każdy projekt wyłączenia systemu poprzedzany jest długą i wnikliwą analizą. W trakcie takiej analizy z reguły okazuje się, że system był rozwijany przyrostowo przez różne zespoły, przez różnych dostawców. Konsekwencją tego jest brak spójnej dokumentacji systemu, która jest niezgodna z tym, co rzeczywiście działa na produkcji. Co więcej, architektura systemu i model danych były rozwijane przyrostowo, z wykorzystaniem całego zestawu antywzorców.

Model danych jest „zabezpieczony” na wypadek dalszego rozwoju zestawem atrybutów typu param1, param2, param3,... w różnych miejscach. Ten wzorzec przenosi się często na warstwę logiki aplikacji i na warstwę aplikacyjną. Powstały łańcuszek powiązań powoduje, że mamy strukturę, której wszyscy boją się dotknąć „bo wybuchnie”. Takie postępowanie sprawia, że część zależności pomiędzy danymi, które moglibyśmy czytelnie opisać w strukturze bazy danych, jest oprogramowanych w logice aplikacyjnej, co czyni je mniej czytelnymi i trudniejszymi do znalezienia!

Atrybuty obiektów danych są wykorzystywane w wielu miejscach kodu na różne sposoby. Logika biznesowa aplikacji nadaje danym różne znaczenie w zależności od kontekstu wywołania. Np. jeśli mamy do czynienia z produktem A, to pole ‘date’ oznacza datę podpisania umowy, jeśli to produkt B – datę rozpoczęcia obowiązywania umowy, a jeśli ‘status’ jest ‘inactive’ – datę rozwiązania umowy. Tzw. „zagłębie ifów”, które jest jeszcze kopiowane w różne miejsca kodu, a potem modyfikowane jedynie w niektórych z tych miejsc, to jeden z większych koszmarów, jaki może napotkać programista czy też analityk systemowy.

Ta faza analizy jest niejako procesem reverse-engineeringu aplikacji. Projekty wyłączenia systemów nie udają się głównie dlatego, że  na tym etapie nie udaje się odtworzyć pełnej logiki działania systemu. Możemy się spotkać nawet z decyzjami o „wydrukowaniu” systemu – ze względu na ryzyko przeoczenia pewnej logiki biznesowej, należy zarchiwizować komplet danych źródłowych, kodu źródłowego i danych zinterpretowanych (np. raportów).

Co zrobić, droga redakcjo?

Jak zatem rozwiązać problem trudnego wyłączania systemów? Wydaje mi się, że metoda jest prosta, choć może wydawać się nieco obrazoburcza. Każdy system ma swój cykl życia. Jego wyłączenie powinno nastąpić w ciągu kilku, najdalej kilkunastu lat. Przy projektowaniu systemu warto wirtualnie przenieść się w przyszłość, w moment wyłączania systemu i pomyśleć, co zrobić, żeby to wyłączanie było stosunkowo proste, a następnie przełożyć to na wymagania do systemu. Ten proces należy powtarzać przy projektowaniu i implementowaniu każdej zmiany w systemie.

Trudne? Myślę, że nie. Wymagające nieco innego myślenia. Wymagające nieco mniejszego związku emocjonalnego ze „swoją” aplikacją – trzeba pogodzić się z myślą, że nie robimy systemu na zawsze. Czy tak będzie drożej? Być może – gdy będziemy robili dobrze zaprojektowane rozwiązania, zamiast łączenia „na sznurki”, możemy zużyć na to więcej czasu. Jednak tutaj różnica nie powinna być duża. Duża różnica będzie za to w koszcie projektu decomissioningu.

W tak urządzonej architekturze projekty informatyczne, nawet te mniej seksowne, jak migracja i wyłączanie systemów, mogą być przyjemniejsze i dużo mniej stresujące.

 

software development, decommissioning, czas życia aplikacji, wyłączanie aplikacji
Paweł Kot

Paweł joined ITMAGINATION in November 2016 after leaving PZU Group where he held the role of IT Architecture Director. In ITMAGINATION he focuses not only on insurance but on the whole financial industry acting as Enterprise Architect and Product Manager responsible for the product portfolio for FSI clients.

Chcesz wiedzieć więcej? Skontaktuj się z nami.