Każdy szef IT w którymś momencie swojej kariery mierzy się z następującym problemem: co zrobić z systemem, który wciąż jest używany przez biznes, ale nie ma już realnej możliwości wprowadzania do niego zmian i poprawiania błędów? Najczęściej dotyczy to systemu stworzonego dawno temu na zamówienie. Co prawda są dostępne jego kody źródłowe, ale nie ma już zespołu, który je rozwijał i utrzymywał. Dział IT najchętniej by taki system wyłączył, ale skoro potrzeba biznesowa na to nie pozwala, to pozostają dwie opcje – odbudować zespół rozwojowy albo przepisać system na nowo.

Jeśli spytać programistów, którą z opcji należy wybrać, raczej nie będą mieli wątpliwości. “Napiszmy system od nowa, ale lepiej niż to zrobili poprzednicy. Użyjmy nowych technologii, które dobrze znamy, poprawmy przy okazji architekturę systemu, a stary system zaorajmy. Dzięki temu będziemy mogli wreszcie przeczyścić listę błędów, zaimplementować nowe funkcje, o które biznes dopomina się od miesięcy, a na deser dorzucimy trochę wodotrysków w interfejsie użytkownika.” Korzyści z takiego scenariusza są jasne – dział IT odzyska sprawność wprowadzania zmian w systemie, pojawią się nowe możliwości integracyjne oraz rozwiążemy problem przestarzałości rozwiązania na wiele lat.

Jednak kierownik IT zwykle nie będzie aż tak entuzjastycznie nastawiony do tego pomysłu. Przede wszystkim będzie potrafił sobie wyobrazić spojrzenie właściciela biznesowego systemu, któremu powie: “co prawda od wielu miesięcy czekacie na realizację swoich pilnych zgłoszeń, ale zaakceptujcie teraz ten kilkusettysięczny budżet, a już za rok… no, góra dwa, będziemy mogli je dla was wykonać”. Poza tym będzie wiedział – szczególnie, jeśli miał już doświadczenie z podobnymi projektami – że koszt ponownej implementacji i czas do uruchomienia produkcyjnego są zazwyczaj znacznie niedoszacowane.

Z drugiej strony scenariusz budowy zespołu, który zajmie się utrzymaniem i rozwojem kodu obecnego systemu, też nie rysuje się optymistycznie. Oczywiście w przypadku sukcesu korzyści są warte wysiłku. Dział IT może w krótkim czasie zająć się naprawą najbardziej uciążliwych błędów i realizacją nowych potrzeb biznesu. Ponadto koszty usprawniania i rozwoju stabilnego systemu zwykle stanowią niewielki procent kosztu jego wytworzenia, więc zorganizowanie budżetu w firmie staje się o wiele łatwiejsze. Jednak droga do tego sukcesu wydaje się znacznie bardziej stroma niż w wariancie ponownej implementacji systemu. Najpierw trzeba znaleźć programistów, którzy będą mieli chęć i kompetencje do zagłębienia się w dziesiątki tysięcy linii kodu, do których nie ma za bardzo dokumentacji. Już samo to jest wyzwaniem, a jeśli do tego dodamy fakt, że zwykle kod jest napisany w starszym języku programowania i przy użyciu nierozwijanych już bibliotek i narzędzi, to sytuacja staje się naprawdę trudna. Potem wcale nie jest łatwiej, bo taki zespół trzeba utrzymać, a na tak konkurencyjnym rynku znacznie lepiej w CV prezentuje się “tworzenie nowej aplikacji mobilnej w React Native” niż “poprawianie błędów w starym systemie w Visual Basic 6”.

Jak zatem poradzić sobie z problemem rozwoju systemu, gdy oba scenariusze generują znaczne trudności? Przede wszystkim trzeba mieć świadomość, że w dłuższej perspektywie aktualizacja technologiczna jest konieczna, gdyż z każdym rokiem koszt wspierania starych rozwiązań będzie rósł, a możliwość ich dostosowania do zmieniających się potrzeb biznesu będzie malała. Istotne jest jednak, żeby do takiego projektu zorganizować zespół, który nie tylko będzie posiadał odpowiednie kompetencje techniczne, ale będzie też dobrze znał realne potrzeby biznesowe, które stoją za systemem.

I tu dochodzimy do sedna sprawy, bowiem najlepszym sposobem pozyskania tej wiedzy merytorycznej jest… spędzenie kilku miesięcy na utrzymaniu i rozwoju starego systemu. Tak przeszkolony zespół będzie znacznie lepiej przygotowany do realnego zaplanowania migracji technologicznej. Będzie też w stanie po partnersku rozmawiać z biznesem o potrzebach i odróżniać usprawnienia uzasadnione biznesowo od wymagań z kategorii “nice to have”, które są kosztowne, ale nie wnoszą wiele wartości.

Takie podejście pozwoli uzyskać korzyści z obu opisanych wyżej scenariuszy – w krótkiej perspektywie będzie można na bieżąco reagować na błędy i potrzeby zmian, a w dłuższej rozwiązać problem długu technologicznego i zwiększyć możliwości rozwoju i integracji. Równocześnie zniknie część problemów – dobrze przygotowany zespół uniknie nadmiernego optymizmu w planowaniu migracji, biznes będzie widział bezpośrednie efekty z budżetu, programiści nie będą rozglądać się za ofertami pracy z ciekawszymi technologiami. Nadal jednak pozostaje kwestia, jak zorganizować odpowiednie osoby do takiego zespołu. Na pewno istotne jest, żeby składał się z osób, które są chętne do nauki nowych rzeczy, zarówno w obszarze technologii jak i wiedzy biznesowej. W przypadku programistów bardziej niż np. 10 lat doświadczenia w tworzeniu systemów CRM w JEE na Oracle’u, liczy się obycie z różnymi językami i narzędziami oraz zdolność pracy na cudzym kodzie. Wybranie odpowiednich osób z mnogości ofert na rynku nie jest zadaniem łatwym, jednak możliwym – ale to już temat na osobny artykuł. Zawsze też można skorzystać ze wsparcia zewnętrznych firm, które wezmą tą kwestię na siebie.