Jak efektywnie modernizować przestarzałe oprogramowanie w zakładach produkcyjnych?

Każdy, kto pracuje w produkcji, prędzej czy później zetknie się z systemami legacy – starym, ale nadal działającym oprogramowaniem, które trzyma całą firmę w ryzach. I choć na pierwszy rzut oka może wydawać się, że „działa, więc po co ruszać?”, to z czasem zaczyna się dostrzegać jego ograniczenia. Brak dokumentacji, uzależnienie od kilku ludzi w firmie, którzy „jeszcze wiedzą, jak to działa”, czy koszty utrzymania rosnące z roku na rok – to tylko niektóre z problemów.

Brzmi znajomo? Nie jesteś sam. Nawet rząd USA w 2019 roku wydał ponad 70 miliardów dolarów na informatyzację swojej administracji, a wewnętrzne audyty wykazały, że ogromna część tej kasy poszła właśnie na utrzymanie przestarzałych systemów. I w naszej branży jest podobnie – mnóstwo firm działa na oprogramowaniu, które pamięta czasy, gdy internet w firmach był luksusem. Problem w tym, że w pewnym momencie te stare systemy zaczynają bardziej hamować rozwój niż pomagać w codziennej pracy.

W tym wpisie opowiem trochę o tym, czym właściwie jest oprogramowanie legacy, jak rozpoznać, że mamy z nim problem, i jakie są opcje, jeśli nie chcemy utknąć z nim na kolejne dekady.

Cechy systemu zastanego (legacy)

• Przestarzała technologia – system opiera się na starych językach programowania, frameworkach lub sprzęcie, które nie są już rozwijane ani wspierane.
• Problemy z wydajnością – system działa wolniej, ma długie czasy odpowiedzi lub nie radzi sobie z rosnącą ilością danych i użytkowników.
• Problemy z bezpieczeństwem – brak aktualizacji i łat (często w bibliotekach używanych przez system) sprawia, że aplikacja jest podatna na ataki i nie spełnia współczesnych standardów bezpieczeństwa (np OWASP).
• Wysokie koszty utrzymania – każda poprawka, zmiana czy integracja wymaga dużych nakładów pracy i pieniędzy, bo system jest trudny w modyfikacji.
• Ograniczona skalowalność – system nie nadąża za rozwojem firmy, a jego rozbudowa jest skomplikowana lub wręcz niemożliwa.
• Brak elastyczności – nawet drobne modyfikacje wymagają dużej ingerencji, przez co system nie nadąża za nowymi wymaganiami.
• Oprogramowanie słabo się integruje z aplikacjami zewnętrznymi – współczesne API, chmura czy nowe systemy MES często nie współpracują płynnie ze starym rozwiązaniem.
• Manualny proces wymiany wersji – brak automatyzacji sprawia, że każda aktualizacja czy wdrożenie nowej funkcji wymaga ręcznego kopiowania artefaktów, odpalania jakiś skryptów “z ręki” co sprawia że jesteśmy podatni na błędy.
• Brak dokumentacji lub słaba dokumentacja – wiedza o systemie często jest rozproszona lub zależy od kilku kluczowych osób w firmie, co utrudnia jego rozwój i utrzymanie.

Oprogramowanie legacy w oczach pracowników firmy produkcyjnej

Kadra zarządzająca często dostrzega problem – to oni na co dzień korzystają z tego oprogramowania, więc dobrze wiedzą, jak bardzo utrudnia im życie. Widzą, że system się zawiesza, działa wolno albo wymaga absurdalnych obejść, żeby wykonać proste zadanie.

Dla właściciela problem jest mniej oczywisty – na jego poziomie system legacy to tylko cyferki w raportach. Spadki efektywności czy rosnące koszty utrzymania trudno jednoznacznie powiązać z przestarzałym oprogramowaniem, przez co problem nie zawsze trafia na listę priorytetów.

Pracownicy produkcyjni tracą cierpliwość – kiedy na linii trzeba czekać na załadowanie ekranu, skanowanie kodu trwa wieczność, a system potrafi się zawiesić w kluczowym momencie, frustracja rośnie. Co gorsza, ludzie często przyzwyczajają się do tego, że „tak już jest” i zamiast walczyć o zmiany, uczą się tolerować słabo działające rozwiązania. Problem w tym, że prędzej czy później przekłada się to na spadek zaangażowania i większą rotację pracowników.

Co można z tym zrobić?

Pierwsza opcja to… zignorowanie problemu. Brzmi ryzykownie, ale w niektórych przypadkach może to być całkiem rozsądne podejście. Jeśli firma działa stabilnie, nie planuje większych zmian i ma pełne zaufanie do obecnego rozwiązania, to może nie ma sensu na siłę go ruszać. Oczywiście, trzeba się liczyć z tym, że prędzej czy później technologia stanie się jeszcze większym ograniczeniem, ale jeśli wszystko działa i nie ma potrzeby rozwoju, to czasem lepiej skupić się na innych priorytetach.

Drugie podejście to stopniowa migracja poszczególnych modułów systemu do nowych technologii. To dość popularna strategia, bo pozwala unikać wielkich rewolucji i rozkłada koszty w czasie. Problem w tym, że wymaga ogromnej dbałości o spójność danych – stare i nowe moduły muszą się dogadywać, a każda zmiana to potencjalne ryzyko komplikacji. Jeśli jednak firma nie może sobie pozwolić na gwałtowne zmiany, to jest to jedno z rozsądniejszych rozwiązań.

Czasami jednak nie ma innego wyjścia niż przepisanie całego systemu od zera lub zakup gotowego rozwiązania. Kiedy system legacy jest już kulą u nogi, a każda próba jego naprawy przypomina łatanie tonącej łodzi, to może pora go po prostu wyrzucić i zacząć od nowa. To oczywiście kosztowna i czasochłonna operacja, ale w dłuższej perspektywie może się opłacić – zwłaszcza jeśli stare rozwiązanie nie nadąża za rozwojem firmy.

Najbardziej radykalnym podejściem jest przebudowanie całego procesu biznesowego razem z obsługującym go oprogramowaniem. To opcja dla firm, które nie tylko chcą wymienić system, ale przy okazji gruntownie przeanalizować i zoptymalizować sposób działania. Efekt może być rewolucyjny – usprawnienie operacji, większa elastyczność i oszczędności na przyszłość – ale jednocześnie jest to opcja najbardziej wymagająca, zarówno finansowo, jak i organizacyjnie.

Każde z tych podejść ma swoje plusy i minusy. Kluczowe jest znalezienie równowagi między kosztem, ryzykiem a długoterminowymi korzyściami.

Kiedy powinniśmy rozważyć częściową lub całkowitą wymianę na nowe oprogramowanie?

• Stara aplikacja nie obsługuje nowych wymagań biznesowych – jeśli firma się rozwija, a system nie nadąża za jej potrzebami, to znak, że coś trzeba zmienić. Gdy każde nowe wdrożenie wymaga kosztownych obejść albo jest wręcz niemożliwe, to jasny sygnał, że obecne rozwiązanie przestało być wystarczające.
• System stał się wolny przez przestarzałe technologie i źle zoptymalizowany kod – gdy aplikacja powstawała, działała sprawnie, ale z biegiem lat ilość danych urosła, a technologie nie były na to gotowe. Efekt? System muli, przetwarzanie informacji trwa wieki, a każda większa operacja obciąża serwery bardziej, niż powinna.
• Dług techniczny jest zbyt duży, żeby dalej rozwijać oprogramowanie – efekt „big ball of mud” – to sytuacja, w której kod jest tak skomplikowany, niespójny i pełen prowizorycznych łatek, że nikt już nie wie, jak go poprawnie rozwijać. Każda zmiana prowadzi do nowych problemów, a poprawki w jednym miejscu psują coś innego. W takiej sytuacji dalsza modernizacja systemu może być bardziej kosztowna niż napisanie go od nowa.
• System posiada poważne dziury w zabezpieczeniach i jest podatny na ataki – stare aplikacje często nie spełniają współczesnych standardów bezpieczeństwa, co naraża firmę na wycieki danych, ataki hakerskie czy inne zagrożenia. Jeśli system nie ma już wsparcia technicznego lub nie da się go łatwo zabezpieczyć, to lepiej nie czekać na katastrofę, tylko działać z wyprzedzeniem.

Jeśli którykolwiek z tych problemów brzmi znajomo, to znak, że warto poważnie zastanowić się nad wymianą systemu. Czasem odwlekanie decyzji wychodzi drożej niż podjęcie trudnej, ale koniecznej zmiany.

Podejście “town-planning”

Jednym z ciekawszych sposobów myślenia o modernizacji systemów legacy jest koncepcja „town-planning”, którą spopularyzowali Ian Cartwright, Rob Horn i James Lewis z Thoughtworks – firmy, która od lat doradza organizacjom w cyfrowej transformacji. To podejście porównuje modernizację aplikacji i całych powiązanych systemów do przebudowy miasta, gdzie nie da się po prostu zrównać wszystkiego z ziemią i zacząć od zera.

Urbanista nie ma takiego komfortu – zamiast tego analizuje istniejącą infrastrukturę, identyfikuje kluczowe obszary wymagające modernizacji i wprowadza zmiany stopniowo, tak aby miasto mogło dalej funkcjonować. Podobnie jest z systemami legacy – zanim podejmie się jakiekolwiek działania, najpierw trzeba dokładnie zrozumieć, jak wygląda obecna architektura, jakie procesy obsługuje i jak wpływa na działanie całej firmy.

Koncepcja „town-planning” zakłada też, że modernizacja to proces ciągły, a nie jednorazowy projekt. Firmy często szukają magicznej „dużej zmiany”, która raz na zawsze rozwiąże problem, ale w rzeczywistości transformacja IT to długofalowa strategia, która pozwala budować przewagę konkurencyjną krok po kroku. Nie chodzi tylko o wymianę technologii, ale też o poprawę procesów biznesowych, bo często to właśnie one wymagają usprawnienia, zanim nowa infrastruktura zacznie przynosić realne korzyści.

Myśląc o systemach legacy jak o mieście, łatwiej pogodzić się z faktem, że idealne rozwiązanie nie powstanie z dnia na dzień. Kluczowe jest strategiczne podejście do zmian, tak aby nowa „architektura IT” nie tylko działała lepiej, ale też była gotowa na przyszłe wyzwania.

Wyzwania migracji do nowego oprogramowania w firmie produkcyjnej

Dla CIO i działów IT w firmach produkcyjnych migracja systemu legacy nie oznacza, że sami będą ją przeprowadzać – to zadanie najczęściej jest zlecane firmie zewnętrznej. Jednak nawet jeśli cały proces wykonuje dostawca, świadomość wyzwań związanych z migracją jest kluczowa, żeby dobrze zarządzać projektem, kontrolować koszty i unikać niespodzianek.

Pierwszym wyzwaniem jest przygotowanie jasnego planu działania. Nie wystarczy powiedzieć „chcemy nowy system” – trzeba dokładnie określić, jakie funkcjonalności są kluczowe, jakie zależności występują w starym systemie i jak nowa architektura ma wspierać biznes. Niezbędne jest też zdefiniowanie mierzalnych celów, np. skrócenie czasu obsługi reklamacji o 30% czy utrzymanie tej samej wydajności produkcji bez zatrudniania nowych osób.

Następnie dochodzi problem skali i złożoności. Stare systemy to często gigantyczne monolity, w których wszystko jest mocno powiązane. Oddzielenie poszczególnych modułów czy ich migracja do nowego środowiska może być ekstremalnie trudna, a każda zmiana w jednym miejscu może powodować nieprzewidziane skutki gdzie indziej. Należy być świadomym, że migracja może oznaczać konieczność kompromisów – nie zawsze da się zrobić wszystko idealnie od pierwszego dnia.

Migracja samych danych to kolejne duże wyzwanie. Różne formaty, nieaktualne rekordy, brak spójności – to wszystko wymaga nie tylko technicznej transformacji, ale też decyzji biznesowych, np. czy wszystkie dane rzeczywiście muszą być przeniesione, czy część można zarchiwizować. Kluczowe jest też zaplanowanie procesu tak, żeby nie zaburzył działania firmy – przestoje produkcyjne kosztują krocie, więc migracja danych musi być zaplanowana w taki sposób, aby minimalizować downtime.

Brak wsparcia dla starej technologii to kolejny problem. Nowy system będzie musiał przez pewien czas współpracować ze starym, a to oznacza tymczasowe integracje i konieczność zarządzania dwoma środowiskami jednocześnie. Dodatkowo brakuje specjalistów znających stare technologie, co oznacza, że każda poprawka w systemie legacy jest ryzykowna i kosztowna.

Nie można też zapominać o kosztach. Zatrudnienie specjalistów od rzadkich technologii i utrzymanie starej infrastruktury może być droższe niż sama migracja. Dlatego warto od początku określić budżet na każdą fazę projektu – od developmentu, przez testy, aż po wdrożenie. Brak kontroli nad finansami może sprawić, że projekt się przeciągnie lub utknie w połowie.

Ostatnim, ale równie ważnym aspektem jest zarządzanie ryzykiem awarii w trakcie transformacji. W firmach produkcyjnych przestój jednej maszyny może kosztować dziesiątki tysięcy złotych. Migracja nie może doprowadzić do sytuacji, w której systemy sterujące procesem produkcyjnym przestają działać. Warto posiadać strategie awaryjne, backupy i mechanizmy recovery, żeby w razie problemów można było szybko wrócić do stabilnego stanu.

Strategie ewolucji oprogramowania legacy

Enkapsulacja

Enkapsulacja to próba złożenia w całość powiązanych ze sobą fragmentów oprogramowania w jeden spójny moduł posiadający interfejs komunikacyjny (np fasada w postaci REST API) do reszty systemu. Komunikacja przez wspólną bazę danych też jest jakąś opcją ale jest to raczej antywzorzec z uwagi na to że stara struktura danych narzucać nam nieoptymalne rozwiązania w wydzielonym serwisie. Dzięki temu udaje nam się osiągnąć wyraźne granice pomiędzy poszczególnymi elementami systemu co jest pierwszym krokiem do modularyzacji i skalowalności.

Innym rozwiązaniem jest wydzielenie całej logiki domenowej jako najważniejszej części aplikacji i skomunikowanie jej za pomocą interfejsów z resztą systemu (warstwa dostępu do danych, kontrolery itd.)

Strategia enkapsulacji pozwala wprowadzać zmiany przyrostowo i dobrze wpisuje się w metodologię Agile.

Kluczowe założenia enkapsulacji to:

• dogłębne zrozumienie działania obecnego systemu, jego architektury i logiki biznesowej
• priorytetyzacja prac nad najbardziej krytycznymi modułami, która zarabiają/oszczędzają dla naszej produkcji najwięcej pieniędzy
• inwestycja w automatyzację wdrożeń i testowania – CI/CD
• inwestycja w przygotowanie testów automatycznych – najczęściej E2E (End To End), ponieważ trudno dopisywać testy do kodu legacy
• przygotowanie testów kontraktowych (CDC) jako pokrycie punktów styku pomiędzy starą i nową częścią

Wzorzec “dusiciel”

Wzorzec dusiciela (strangler pattern) to metafora sposobu wydzielania fragmentów oprogramowania legacy do nowej wersji przypominająca dusiciela oplatającego drzewo figowe.

To co robimy tutaj to krok po kroku przenosimy poszczególne fragmenty kodu legacy do zewnętrznych serwisów (np mikroserwisów) które działają obok systemu zastanego. Sukcesywne działanie prowadzi w końcu do tego że nowo napisane moduły przewyższają swym rozmiarem system legacy co z czasem prowadzi do jego ostatecznego wyłączenia.

Podejście to zapewnia nam możliwość ciągłego wykorzystywania funkcjonalności do obsługi procesów produkcyjnych w trakcie wyodrębniania kolejnych modułów.

Zastosowanie mechanizmów feature toggles jest tutaj bardzo pomocne bo umożliwia powrót do starej, działającej ścieżki w ciągu kilku sekund jeżeli zauważymy że coś jest nie tak – daje nam to odporność na potencjalne awarie.

Na co powinniśmy zwrócić uwagę:

• identyfikacja nisko wiszących owoców – warto jest osiągnąć szybki sukces zaczynając od czegoś prostego ale być może sprawiającego największy problem?
• wdrożenie skutecznego pipeline CI/CD aby być pewnym, że wszystko działa “po staremu”
• identyfikacja kolejnych fragmentów kodu, skupiając się na tych najtrudniejszych w utrzymaniu
• iteracyjne zastępowanie starych modułów nowymi
• ciągła komunikacja z zarządem i interesariuszami na temat postępu migracji

Replatforming

Replatforming to wykorzystanie tzw strategii “lift and shift” czyli przeniesienia oprogramowania w raz z podpiętym do niego systemem bazy danych do innego środowiska uruchomieniowego – np. z on-premise do cloud (AWS, Azure, Google Cloud itp.). Przy czym nie wprowadzamy tutaj istotnych zmian w samej aplikacji.

Jest to ciekawa opcja w sytuacji kiedy system legacy zużywa bardzo dużo zasobów hardware’owych i przeniesienie go do chmury będzie po prostu tańsze (disclaimer: chmura często jest jeszcze droższym rozwiązaniem!)

Takie podejście najczęściej trwa krócej niż przepisywanie całego lub fragmentów kodu i pociąga za sobą niższe koszty całej migracji.

Jest to też najprostszy sposób na poprawę wydajności i skalowalności systemu legacy, poprzez dołożenie zasobów sprzętowych które w pewien sposób “zamaskują” nieoptymalne rozwiązania pod spodem.

Założenia replatformingu:

• zdefiniowanie ostatecznego celu: poprawa wydajności, skalowalności czy niższe koszty?
• dokładne poznanie architektury systemu legacy, aby przewidzieć co może pójść nie tak
• wybór odpowiedniej platformy
• przygotowanie szczegółowego harmonogramu migracji
• zadbanie o dogłębne przetestowanie systemu po migracji zarówno za pomocą testów automatycznych jak i manualnie

Re-architecting

Jest to jedna z bardziej radykalnych strategii, polegająca na zaprojektowanie całkowicie nowej architektury systemu poczynając od etapu koncepcyjnego.

Strategię tą stosujemy kiedy obecna architektura systemu przestała całkowicie obsługiwać nasze potrzeby biznesowe. W tej sytuacji refaktoring albo wykorzystanie wzorca Strangler może okazać się niewystarczające.

Przykładem może być tutaj przejście z wielkiego monolitycznego systemu ERP do bardziej modularnej architektury, pozwalającej lepiej skalować najważniejsze usługi w ramach systemu.

Należy przygotować się na to, że jest to długi proces mierzony raczej w miesiącach i latach.

Taki proces wymaga:

• dobrego zrozumienie obecnej architektury i wypunktowania jej słabych stron
• zdefiniowania jasnych celów, które chcemy osiągnąć – większa skalowalność, większa niezawodność szybszy rozwój o nowe funkcje
• zaprojektowania docelowej architektury
• stopniowego przenoszenia funkcjonalności biznesowych do nowej architektury, najbezpieczniej jest zacząć od tych najmniej istotnych biznesowo
• continuous testing – zarówno na poziomie kodu aplikacji jak i E2E
• zaangażowania wielu osób z firmy produkcyjnej głównie w celu dostarczenia wiedzy domenowej i zebrania szybkiego feedbacku na temat postępu wdrożenia

Zbudowanie od nowa

W niektórych sytuacjach koszty utrzymania aplikacji i jej migracja byłaby zbyt droga i wtedy warto zastosować opcję zerową, czyli przepisać wszystko od początku z wykorzystaniem modelu domenowego który odpowiada na obecne i przyszłe potrzeby biznesowe.

System zarządzania bazą danych powinien być odpowiedni do obsługi zbiorów danych odpowiadających potrzebom organizacji.

Opcja zerowa to również szansa na wdrożenie nowoczesnych, aktualnie wspieranych technologii do których łatwo jest znaleźć specjalistów, a także możliwość zaprojektowania lepszego, bardziej ergonomicznego interfejs użytkownika.

Należy jednak zdawać sobie sprawę, że główną wadą tego podejścia jest olbrzymia inwestycja finansowa i czasowa, angażująca wiele osób które nie będą mogły w tym czasie wykonywać swoich normalnych obowiązków.

Jeżeli nie zadbamy o odpowiedni dostęp do ekspertów, którzy będą w stanie powiedzieć nam jak działa ten biznes produkcyjny może się okazać że wymagania do nowego systemu będą odtwarzane na podstawie kodu starego systemu.

Podmiana na gotowe oprogramowanie

Istnieje jeszcze jednak opcja którą można wybrać – zamiast przepisywać stare oprogramowanie czasami jest można skorzystać z istniejących gotowych aplikacji z rynku – np w formie SaaS (Software as a service) takich jak nasz system FACTORY plus. Często takie aplikacje da się dodatkowo customizować pod potrzeby danej branży produkcyjnej i rozwijać w miarę zapotrzebowania przedsiębiorstwa.
Zobacz jak robimy to w VISIX.

Finalnie może się okazać, że jest to bardzo praktyczna i o wiele tańsza droga niż przepisywanie wszystkiego od początku.

Co trzeba zrobić aby wybrać tą opcję?

• przede wszystkim należy zrozumieć działanie obecnego systemu legacy i potrzeb biznesowych, które zaspokaja. Również identyfikacja braków w obecnym rozwiązaniu, które nowe lub rozwiązanie komercyjne powinny dostarczyć będzie kluczowa
• przemyśl jaki masz budżet i ile czasu możesz na to poświęcić na szukanie gotowego rozwiązania
• przegląd rynku w celu znalezienia najlepszego dostępnego rozwiązania komercyjnego
• przygotuj plan integracji z obecnie używanym oprogramowaniem
• zadbaj o właściwy onboarding użytkowników, przyzwyczajonych do starego systemu

Proces wymiany oprogramowania typu legacy nie jest prostym zadaniem. Wymaga dokładnego przemyślenia celów, które chcemy osiągnąć, roli jaką system pełni w naszym biznesie oraz potencjalnych ryzyk związanych z migracją. Należy również brać pod uwagę jakie zasoby ludzkie możemy oddelegować do tego procesu. Jak wyżej pokazałem część strategii opiera się na stopniowym, płynnym przejściu do nowego rozwiązania a inna część zakłada podejście radykalne z wymianą lub przebudową całego systemu. To którą ścieżką pójdziemy zawsze wymaga naszej kalkulacji strategicznej na poziomie naszego biznesu produkcyjnego.