allclouds.pl

Systemy legacy nie znikną same: jak fabryki agentów AI zmieniają biznesowe uzasadnienie modernizacji IT

Systemy legacy nie znikną same: jak fabryki agentów AI zmieniają biznesowe uzasadnienie modernizacji IT

Generatywna i agentowa AI nie sprawi, że system legacy zniknie. Jednak po raz pierwszy realnie zmienia równanie: skraca czas modernizacji nawet o połowę, zmniejsza koszty długu technicznego i przenosi to zadanie z kategorii „niezbędnego zła IT” do „strategicznej dźwigni biznesowej”. Jest jeden warunek: trzeba przestać myśleć o modernizacji jako o przepisywaniu kodu i zacząć myśleć w kategoriach fabryki agentów.

Nie są to już wyłącznie obietnice dostawców. Empiryczne badania McKinsey nad produktywnością programistów pokazują, że narzędzia generatywnej AI skracają czas pisania nowego kodu i dokumentowania istniejącego do mniej niż połowy wartości wyjściowej, a refaktoryzacji systemów legacy do około dwóch trzecich (McKinsey, „Unleashing developer productivity with generative AI”). Osobna inicjatywa McKinsey - LegacyX, wykorzystująca wyspecjalizowane „szwadrony” agentów AI do modernizacji systemów bankowych - informuje o przyspieszeniu o 20-30% już w pierwszych projektach, z dalszym wzrostem po przejściu od pojedynczych narzędzi do architektury wieloagentowej.

Article illustration

System legacy jako kotwica, a nie „naturalny stan rzeczy”

Zacznijmy od trzeźwej oceny: system legacy nie jest „normalnym etapem życia systemu”. Jest kotwicą.

W sektorach takich jak finanse, ubezpieczenia, administracja i energetyka kręgosłup działalności stanowią systemy mające kilkanaście, a nawet kilkadziesiąt lat. Wiele z nich napisano w językach, których nie uczy się już na uczelniach. Dokumentacja jest fragmentaryczna albo nie istnieje, a logika biznesowa przeszła dziesiątki „szybkich poprawek”. Każda zmiana boli.

Z perspektywy biznesowej oznacza to:

Nie jest to już wyłącznie problem „działu IT”. To problem przewagi konkurencyjnej organizacji.

Dlaczego tradycyjne podejścia do modernizacji zawiodły

Przez lata próbowano różnych dróg, które dziś wyraźnie widać jako ślepe zaułki.

Przepisanie typu big bang. Ogromne projekty trwające 5-7 lat, setki ludzi i obietnica: „Przepiszemy wszystko na nowoczesną platformę i będzie po sprawie”. W praktyce wymagania biznesowe zmieniają się po drodze, architektura docelowa staje się przestarzała przed ukończeniem projektu, a ryzyko migracji rośnie wraz z poszerzaniem się luki między starym i nowym systemem.

Lift & shift do chmury. Przeniesienie monolitu jeden do jednego do infrastruktury chmurowej. Rezultat: część kosztów infrastruktury spada lub się upraszcza, ale dług techniczny i złożoność architektoniczna pozostają nietknięte, a system nadal ogranicza możliwości pracy z danymi i procesami.

Code and load. Przepisanie kodu z jednego języka na inny bez zmiany logiki lub architektury. Na przykład COBOL → Java, ale wszystkie historyczne obejścia, „trzy ify dla wyjątku z 2007 roku” i dziwne ścieżki nadal istnieją; nikt nie pyta, czy cały proces wciąż jest potrzebny, a biznes nadal nie rozumie, co naprawdę znajduje się w środku - tyle że teraz trudniej się do tego przyznać, bo przecież „to nowoczesny stos”.

Wspólny mianownik: koncentracja na technologii (liniach kodu, infrastrukturze), a nie na intencji systemu i wartości biznesowej.

Co naprawdę wnosi generatywna i agentowa AI?

Kusi, aby powiedzieć: „OK, teraz mamy AI, więc szybciej napisze kod”. Tyle że największa wartość nie polega wyłącznie na szybkim pisaniu.

Właściwie wykorzystana AI potrafi:

I tu pojawia się drugi element, którego klasyczne podejścia do modernizacji w ogóle nie obejmowały. Transkrypcje rozmów z „dinozaurami” - ludźmi, którzy naprawdę pamiętają, dlaczego dwadzieścia lat temu dodano ten dziwny wyjątek do reguły kredytowej i co się stało, gdy kiedyś go wyłączono - nie są jedynie surowcem dla agenta discovery. Wraz z setkami innych historycznych decyzji, intuicji branżowych i wzorców rozumowania zbudowanych przez eksperta w ciągu lat pracy z konkretnym systemem tworzą materiał na bliźniaka poznawczego tego eksperta: model, który nie tylko zna jego decyzje, lecz rozumie sposób ich podejmowania. Bliźniak systemu opisuje, co robi system legacy. Bliźniak poznawczy opisuje, dlaczego robi to właśnie tak, a nie inaczej - i dlaczego „dinozaur” przez dwadzieścia lat nie pozwalał tego zmienić. W modernizacji systemów legacy potrzebne są oba. Bez bliźniaka systemu modernizujesz po omacku. Bez bliźniaka poznawczego modernizujesz precyzyjnie, lecz tracisz wiedzę o tym, dlaczego istniejące rozwiązanie wyglądało właśnie tak - i prawdopodobnie odtworzysz w nowym kodzie te same problemy, które obejścia „dinozaura” tłumiły przez dekadę.

Przesuwa to środek ciężkości: ludzie przestają być „rękami do przepisywania”, a stają się projektantami docelowego systemu, podczas gdy AI i agenci wykonują techniczną „czarną robotę”.

W sektorach regulowanych istnieje jednak dodatkowy wymiar: podstawowego kodu systemów bankowych, ubezpieczeniowych lub administracyjnych nie można po prostu przenieść do zagranicznej chmury, aby przeanalizował go agent, dlatego suwerenność danych oraz wymagania DORA i EU AI Act stają się integralnym elementem architektury fabryki, a nie dodatkiem.

Pułapka, której trzeba uniknąć: AI jako turbodoładowane „code and load”

Najprostszy i najgorszy sposób wykorzystania AI do modernizacji wygląda następująco:

W krótkim okresie wygląda to jak sukces: mamy nowy kod, działają nowe testy, wszystko wykorzystuje modne technologie. Pod spodem pozostaje jednak struktura procesów z lat 90., historyczne obejścia i „rozwiązania tymczasowe” przeniesione do nowego świata - zero nowej wartości biznesowej, tylko silnik w ładniejszej obudowie.

To dokładnie to samo co „lift & shift” do chmury, tylko na poziomie kodu. Z perspektywy biznesowej jest to kosztowna operacja, która nie rozwiązuje tego, co naprawdę boli.

Fabryka agentów AI: nowy model modernizacji

W metodologii CDF, którą przedstawiłem w pierwszym artykule z tej serii, nazywam ten wzorzec fabryką agentów - jest to konkretna konfiguracja zespołu, narzędzi i procesów, a nie jedynie retoryczna metafora. Poniżej wyjaśniam, co oznacza to w praktyce.

Prawdziwy przełom zaczyna się wtedy, gdy przestajesz myśleć w kategoriach „projektów modernizacyjnych”, a zaczynasz w kategoriach fabryki agentów.

Od projektu do fabryki

Zamiast za każdym razem tworzyć zespół ad hoc, wybierać narzędzia i wymyślać podejście, budujesz trwałą zdolność:

Dzięki temu każdy kolejny system jest analizowany szybciej, korzysta z doświadczeń poprzednich projektów i generuje nowe „klocki”, które można wykorzystać ponownie.

Jacy agenci pracują w takiej fabryce?

Przykładowy zestaw:

Nad wszystkim czuwa agent-orkiestrator, który zarządza kolejnością zadań, dba, aby wyniki jednego agenta stanowiły dane wejściowe dla następnego, i eskaluje problemy do ludzi, gdy coś wykracza poza ustalone granice.

I teraz rzecz, która zmienia całe ramy myślenia o modernizacji systemów legacy. Wynik pracy agenta discovery - bliźniak systemu - nie jest dokumentacją tworzoną po fakcie. Jest przedmiotem dalszej pracy fabryki. Wszystkie kolejne kroki (decyzje biznesowe o tym, co zachować, projektowanie stanu docelowego, generowanie nowego kodu, testowanie) odbywają się na bliźniaku, a nie na działającym systemie. To fundamentalna różnica względem klasycznych podejść do modernizacji: zrozumienie systemu zostaje oddzielone od jego modyfikacji. Można podejmować radykalne decyzje - upraszczać, restrukturyzować, eliminować całe ścieżki - bez ryzyka uszkodzenia produkcji, której właściciele biznesowi nie pozwolą dotknąć. Modernizacja przestaje być „operacją na otwartym sercu”. Staje się projektowaniem na precyzyjnym modelu, z weryfikacją na działającym systemie dopiero po podjęciu decyzji.

Rola ludzi: od „kodowania” do architektów zmiany

Fabryka agentów nie zastępuje ludzi; redefiniuje ich pracę.

Business / Product Owner. Nie musi czytać COBOL-a. Otrzymuje od agentów „czytelny dla człowieka” opis istniejących procesów, mapę funkcji i wyjątków oraz propozycje uproszczeń. Na tej podstawie decyduje, które funkcje są nadal potrzebne, co można połączyć lub odrzucić i jak powinny wyglądać doświadczenie użytkownika oraz KPI nowego systemu.

Architekt / lead engineer. Projektuje architekturę docelową (granice modułów, standardy integracji, wzorce bezpieczeństwa), weryfikuje propozycje agentów, zapewnia spójność i unika antywzorców, a także ustala bariery ochronne: co agent może zmieniać automatycznie, a co zawsze wymaga przeglądu.

Zespół Dev/QA. Przegląda wygenerowany kod i testy, dodaje logikę, której agent nie potrafi wygenerować poprawnie, projektuje przypadki brzegowe, „dziwne przypadki” i testy, z których agent będzie się uczyć.

Razem funkcjonują jako zespół projektantów i kontrolerów jakości linii produkcyjnej, a nie „ręczna linia montażowa”.

Jak wygląda modernizacyjna „linia produkcyjna” z agentami

Można ją przedstawić jako kilka powtarzalnych etapów:

Fabryka jako trwała zdolność, a nie jednorazowy „Projekt modernizacyjny X”

Kluczowa zmiana sposobu myślenia: fabryki agentów nie buduje się „dla tego jednego programu”. Jest zdolnością, która zaczyna od jednego lub dwóch systemów, ale ostatecznie obejmuje cały portfel legacy i staje się narzędziem do ciągłego „udrażniania” IT.

Z każdym kolejnym projektem rośnie jakość agentów (wiedza domenowa, kontekst, wzorce), spada czas i koszt wejścia w nowy system, a organizacja mniej obawia się modernizacji - ponieważ dysponuje procesem, ludźmi i narzędziami, które robiły to już wielokrotnie.

To ogromna różnica względem klasycznego modelu: serii „programów modernizacyjnych”, które wygasają po zakończeniu, pozostawiając trochę nowego kodu i jeszcze więcej zmęczenia.

Co trzeba zrobić przed uruchomieniem własnej fabryki agentów

Jeżeli jesteś CIO/CTO lub odpowiadasz za transformację, rozsądnym pierwszym krokiem jest zadanie kilku prostych pytań:

Jakie projekty modernizacyjne prowadzimy dziś? Czy nadal opierają się na modelu „duży zespół + długi harmonogram + brak planu AI”? Czy zamierzamy powtarzać ten wzorzec w nadchodzących latach?

Które systemy są dobrymi kandydatami do „pilotażu fabryki”? Ważne, ale nie absolutnie krytyczne; reprezentatywne pod względem logiki, technologii i złożoności dla innych części środowiska.

Kogo potrzebujemy w zespole fabryki? Architektów rozumiejących zarówno stos legacy, jak i docelowy; specjalistów AI/agentowych potrafiących budować i orkiestrować potoki; product ownerów po stronie biznesowej, którzy nie boją się zagłębiać w procesy.

Jak będziemy mierzyć sukces? Nie tylko „ile kodu przepisaliśmy”, lecz także: o ile spadły koszty utrzymania, jak bardzo skrócił się czas wprowadzania zmian, jak poprawiła się stabilność i jaki wpływ wywarło to na rachunek zysków i strat oraz doświadczenie użytkownika.

Jakie projekty modernizacyjne zarząd powinien dziś kwestionować?

Patrząc na szerszy obraz, warto mieć prosty filtr:

Najgorszy scenariusz na nadchodzące lata wygląda bowiem tak: wydamy fortunę na przepisywanie systemów legacy „tak jak dawniej, tylko szybciej”, podczas gdy konkurencja zbuduje fabrykę agentów, która będzie systematycznie modernizować jej IT, przyspieszając z każdym rokiem.

Mikrowzorzec z praktyki

Najszybszym testem sensowności modernizacji systemu legacy nie jest pytanie: „Czy AI potrafi przepisać ten kod?”. Jest nim pytanie: czy agent discovery uruchomiony na tym systemie potrafi wygenerować zrozumiały opis realizowanych przez niego procesów biznesowych bez pomocy osób, które je pamiętają? Jeżeli tak, masz materiał, na którym może pracować fabryka agentów. Jeżeli nie, problemem nie jest kod. Problemem jest brak utrwalonej wiedzy domenowej w samym systemie. Zanim zaczniesz myśleć o przepisywaniu czegokolwiek, musisz najpierw uchwycić to, co obecnie istnieje wyłącznie w umysłach kilku osób zbliżających się do emerytury.

Ta seria przedstawia transformację AI w sektorach regulowanych w podziale na siedem warstw:

Cała seria jest zapisem tego, czego nauczyła mnie praca w sektorach regulowanych - decyzji, które trzeba było podejmować szybciej, niż pozwalała ostrożność, błędów, które nauczyły mnie więcej niż sukcesy, intuicji szlifowanej w rozmowach bez scenariusza oraz woli zbudowania czegoś, co jeszcze nie istnieje.