Krzysztof:
To jest 317. odcinek Porozmawiajmy IT. Dziś rozmawiamy o radzeniu sobie z wyzwaniami systemów Legacy.

Krzysztof:
Sponsorem odcinka jest Finture. Notatkę, linki i transkrypcję, czyli wszystko to, co porządny słuchacz powinien mieć pod ręką, znajdziesz na porozmawiajmyit.pl, łamane na 317. Nazywam się Krzysztof Kempiński, tworzę ten podcast, napisałem też książkę Marka Osobista w branży IT. Jeśli lubisz ten podcast, udostępnij ten odcinek dalej albo zostaw ocenę w swojej aplikacji. To jest dla mnie nieoceniona pomoc. A teraz odpalamy. Cześć, mój dzisiejszy gość to absolwent Wydziału Elektroniki i Technik Informatycznych Politechniki Warszawskiej, otwarty na nowości profesjonalista IT z ponad 19-letnim doświadczeniem na różnych stanowiskach, w tym programista, lider techniczny zespołu, kierownik produkcji oprogramowania, architekt rozwiązań oraz doradca IT. Zafascynowany postępem w dziedzinie generatywnej sztucznej inteligencji, próbuje znaleźć sposoby, w jakiej może ona wygenerować wartość w obszarze inżynierii oprogramowania. Moim waszym gościem, po raz drugi zresztą, jest Adam Skąpski. Cześć Adam, bardzo miło mi gościć cię w podcaście.

Adam:
Cześć, cześć Krzysztofie, dziękuję za zaproszenie.

Krzysztof:
Ostatnio mieliśmy przyjemność rozmawiać już prawie dwa lata temu i ten temat, który poruszyliśmy, dotyczył projektowania systemów informatycznych w dobie generatywnej AI. Dzisiaj też trochę dotkniemy tego tematu, ale takim głównym wątkiem będzie temat znacznie starszy niż to Gen AI w wariancie, z którym mamy pewnie na co dzień do czynienia, bo będzie dotyczył systemów legacy, jak sobie właśnie z nimi radzić, czym one w ogóle są i czy powinniśmy się ich obawiać. Chciałbym jednak standardowo rozpocząć od zapytania Ciebie, czy słuchasz podcastów i może coś z tej listy, o której ostatnio mówiłeś, się zmieniło.

Adam:
No tak, wiele się nie zmieniło, trochę więcej zacząłem może słuchać takich zagranicznych i też przesłuchałem kilka odcinków twojego podcastu, ten bardzo ciekawy o właśnie Spets Driven Development, obszarze, którym się żywo interesujemy, więc to było fajne. Z takich branżowych podcastów na pewno Latent Space, super sprawa dla jakakolwiek, kto się interesuje AI-em i rzeczywiście tam nie słuchałem regularnie każdego odcinka, ale wybiórczo i te, co słuchałem, rzeczywiście były wartościowe. Bardzo ciekawy był odcinek właśnie o początkach sztucznej inteligencji i meczu GO z luchem 37 z DCDO. No to fascynujące rzeczywiście podcast, więc polecam każdemu, kto się AI-em interesuje. Ale tak poza tym cały czas się skupiam głównie jednak na audiobookach, tak? Te podcasty gdzieś tam w międzyczasie. Jasne. No i tak, jeżeli ktoś się interesuje geopolityką, to raport o stanie świata. Dariusza Rosiaka też. Niezmiennie. Bardzo fajny podcast. Niezmiennie. Co tydzień tam wchodzi, żeby się orientować. Co tu dalej będzie z tym naszym światem?

Krzysztof:
No właśnie, no właśnie. Super, dzięki za te rekomendacje.

Krzysztof:
Dobrze, wiesz, może połóżmy jakiś fundament, że tak powiem, pod dalszą rozmowę. Różnie się system religacji definiuje. Niektórzy mówią, że to już jest to właściwie system, który powstał chwilkę potem, jak ostatni znak w kodzie źródłowym napisałeś, inni mówią w perspektywie miesięcznej, jeszcze inni gdzieś raczej kilkuletnią powiedzmy sobie stawiają. Różnie to bywa. Chciałbym też zrozumieć, jak ty definiujesz system legacy i jak to pojęcie łączy się z długiem technologicznym.

Adam:
Tak jak to mówisz, systemy legacy to jest bardzo pojemne pojęcie i tutaj myślę, że każdy w branży rozumie je trochę po swojemu. Rzeczywiście możemy w tym pojęciu zmieścić zarówno systemy przestarzały technologicznie, których technologie są już niewspierane, albo systemy zareśnięte przez lada dodawania funkcjonalności na skróty, albo po prostu źle zaprojektowane inicjalnie w pierwszej chwili, te, które się stają właściwie legacy od momentu wejścia na produkcję. No ale też nawet takie, z którymi technologicznie wszystko jest okej, ale zatraciliśmy kompetencje i wiedzę w organizacji, jak je utrzymywać, jak one działają i de facto nie umiemy sobie już z nimi poradzić, tak? Więc no… Systemy legacy, bardzo pojemne pojęcie, podobnie dług technologiczny, w którym trochę jest jak z PKB. Wszyscy rozumieją, że jak jest wysokie, to jest dobrze, jak niskie, to słabo, ale nie do końca wszyscy potrafimy wytłumaczyć, skąd się bierze i dokładnie o czym znaczy. Ten dług technologiczny też troszeczkę nam się rozmywa w rozumieniu. Dla mnie systemy legacy to przede wszystkim takie systemy, które straciły swoją zdolność do dalszego rozwoju i wspierania biznesu w opłacalny sposób. Czyli mówiąc w skrócie, że rachunek kosztów i korzyści z ich utrzymywania przestał się zgadzać. Czyli nie wnoszą nam tej wartości za odpowiednią cenę.

Adam:
Nie wspierają biznesu dostarczająco dobrze. No i dług technologiczny wiąże się z tym, ponieważ on wpływa na oba parametry, zarówno na koszty utrzymywania i rozwijania takich systemów, jak i korzyści z nich, jeżeli mamy przestarzałe technologie, aplikacje desktopowe, nie webowe,

Adam:
więc te pojęcia są ze sobą bardzo ścisłe powiązane.

Krzysztof:
Jasne, to wobec tego dlaczego mówimy o problemach wynikających z systemów legacy, czy to jest jak gdyby taki znak równości trochę pomiędzy jakimś potencjalnym problemem w firmie, a tym, że ta firma korzysta z systemów legacy, czy zawsze systemy legacy muszą być tymi problematycznymi, którymi musimy się zająć, no i jeśli tak, to jak to może generować, jak to może wpływać właśnie na jakieś tam problemy z działaniem firmy?

Adam:
Tutaj dochodzimy do ciekawej kwestii, bo wydaje mi się, że zjawisko systemów legacy jest dobrym odzwierciedleniem naszej codziennej rzeczywistości, która wygląda tak, że tempo zmian świata, w którym funkcjonujemy, jest coraz szybsze, A ponieważ to tempo jest coraz szybsze, świat się coraz szybciej zmienia, to to tworzy dużą presję na biznesy operujące w tym świecie. Które muszą nadążać za tymi zmianami, muszą wprowadzać modyfikacje w swoich operacjach, przez co modyfikacje w swoich systemach i to jest dla nich często być albo nie być, więc ta presja jest zrozumiała. I zasadna. no ale ta presja powoduje, że, mamy mniej czasu w coraz bardziej złożonym świecie, mamy coraz mniej czasu na to, żeby te systemy projektować, żeby podejmować świadome decyzje, żeby te decyzje w odpowiedni sposób przemyśleć, zważyć i pójść w odpowiednim kierunku żeby ten system zaprojektować, dlatego też odeszliśmy swego czasu od, metodyki wytwarzania waterfall, przeszliśmy na agile, żeby się lepiej dopasowywać no ale tutaj w tym agile trochę zatraciliśmy tą zdolność projektowania tych systemów odpowiednio i skupiamy się na tym tylko, żeby dowodzić kolejne funkcjonalności. Mało która organizacja jest gotowa na taki sposób pracy długoterminowo. No i ta presja czasu w coraz bardziej złożonym świecie wymusza od nas troszeczkę pójścia czasem na skróty, podjęcia decyzji, które nie są do końca przemyślane, które nie były do końca zważone. Zaimplementowania funkcjonalności w mikroserwisie, w którym nie do końca ona powinna mieć miejsce, na przykład wymusza dodanie synchronicznego odpytania innego mikroserwisu, przez co zaczynamy sobie powoli tworzyć rozproszony monolit. No i każda taka zmiana wprowadza ryzyko regresji, ten system jest coraz trudniej utrzymywalny i w ten sposób wprowadzamy dług technologiczny. Każda taka decyzja, która jest zrobiona na skróty, to jest jakiś kolejny punkt w tym naszym długu technologicznym, kolejny zacięgnięty kawałek długu. Istotną konsekwencją tego długu technologicznego jest krótko i długoterminowo, zdolność systemu do zmiany i ewolucji w czasie, czyli odpowiadania na te potrzeby biznesu, które biznes ma i ma ich coraz więcej i coraz szybciej. System zarasta, dług technologiczny rośnie, bo podejmujemy decyzje skrótowe, to coraz ciężej się ten system utrzymuje, ponieważ się coraz ciężej system utrzymuje, zmiany wymagają coraz dłużej, to powoduje kolejną presję, żeby jeszcze szybciej, jakby zdefiniować wymagania, więc jest mniej czasu na zdefiniowanie wymagań, mniej czasu na przemyślenie, a ponieważ to się wszystko dzieje coraz dłużej, no to jest zamknięte koło i wpadamy w taki korkociąg właśnie systemu Legacy, gdzie, wychodząc od tej presji czasu, idąc na skrótce, tworzymy sobie dług, ten dług nas spowalnia, tworzy jeszcze większą presję czasu i tak w kółko. Myślę właśnie, że to jest dobre odzwielisiedlenie troszeczkę właśnie tego świata, w którym żyjemy, gdzie ta presja czasu, tempo zmian powoduje takie,

Adam:
a nie inne konsekwencje i systemy legacji są tego moim zdaniem bardzo dobrym objawem.

Krzysztof:
Jako branża mamy jakieś tam sposoby na radzenie sobie właśnie z tymi systemami legacji. Staramy się w jakiś sposób je unowocześniać. Biznes czasem jest przy tym partnerem, jest świadomy tego, jakie mogą być konsekwencje pozostawania w tym stanie wcześniejszym, jaki to może mieć impakt na działanie biznesu. Natomiast nie ma co też ukrywać, że nie wszystkie te podejścia do unowocześniania systemów legacy kończą się pozytywnie. Jest mnóstwo całkiem dużych organizacji, które podjęły się różnego typu projektów, unowocześniania właśnie tych systemów stworzonych wcześniej i to się skończyło fiaskiem, więc trzeba byłoby się zastanowić i to pytanie tutaj kieruję właśnie do ciebie. Jakie mogą być przyczyny tego, że taka inicjatywa w postaci zróbmy jakiś update, wprowadźmy unowocześnienie systemu Legacy kończy się w efekcie fiaskiem?

Adam:
No to trudne pytanie, bo osobiście nigdy nie brałem udziału w takim projekcie, który zakończył się fiaskiem unowocześniania legacy, ani nie znam takiej historii z pierwszej ręki, ale jeżeli miałbym wskazywać. Co moim zdaniem jest najtrudniejszym aspektem albo gdzie można popełnić największy błąd w tego typu projektach, to jest tak banalnie mówiąc niewystarczające docenienie przeciwnika na starcie projektu. Czyli startując projekt opieramy się na jakichś założeniach, robimy sobie jakąś wizję tego, co jest przed nami w głowie i ta wizja nie ma szans, żeby ona była kompletna. To jest system legacy, szczególnie przy tych systemach, które już mają kilka dobrych lat. To tutaj nie ma szans, żebyśmy na starcie projektu byli świadomi tego, jakie pułapki są przed nami, żebyśmy byli świadomi, jak ten system w całości działa. Więc podejmując właśnie takie założenia i wyobrażając sobie jak działa ten system na starcie projektujemy architekturę, powołujemy projekt, wystartujemy go, no i w trakcie okazuje się, że, no tego nie przewidzieliśmy, że to jeszcze ten system rozmawia z tamtym systemem, albo że robi to i tamto bo to nigdzie nie był udokumentowany, nikt o tym nie wiedział dopiero gdzieś w zakamarkach kodu na jakimś kurde dysku leży pi, który jest zaczytywany cronjobem, którego nie było w bazie kodu, o i to trochę wywraca nam koncepcję, no i teraz stajemy przed rozlożem, czy w takim razie robimy pauzę, trochę wydłużamy projekt, żeby to uwzględnić, przeprojektować, czy zaciągamy dług technologiczny i idziemy do przodu, robiąc skrót, tak, tym samym, troszeczkę przecząc samej idei, przepisania systemu legacy, bo de facto od razu już zaczynamy powoli tworzyć bazę pod ten dług, który kiedyś może nas przytłoczyć i sprawić, że ten nowy system będzie tym systemem legacy, tak. Więc jeżeli miałbym powiedzieć Jedna taka najważniejsza pułapka to jest właśnie, odpowiednie przemyślenie zagadnienia na starcie.

Krzysztof:
Myślę sobie, że też to zmieniające się w trakcie takiego unowocześnienia otoczenie biznesowe, technologiczne nie służy jak najbardziej, bo to też jest kolejna zmienna, którą nie jesteśmy w stanie do końca przewidzieć, która właśnie tak jak powiedziałeś, może generować dług technologiczny nawet podczas teoretycznie tego unowocześniania, którego się podjęliśmy. Więc jest mnóstwo zmien, których po prostu ciężko przewidzieć, ciężko wszystko zaplanować. A też trzeba pamiętać, że ktoś jest sponsorem tych zmian. Ten tak zwany mityczny biznes też ma jakieś swoje założenia, budżety, deadline’y, o których my nawet jako osoby techniczne nie zawsze musimy wiedzieć,

Krzysztof:
więc te różne perspektywy się mogą właśnie spotkać i gdzieś minąć po drodze może w ten sposób. Dobrze Adam, to spróbujmy może nakreślić, jakie w ogóle mamy podejście, jakie mamy sposoby, żeby sobie z tym kodem, z tymi systemami legacy radzić w praktyce.

Adam:
Jasne, no nie będę tutaj wymieniał za wikipedią czy za czatem GPP podejść, jak się klasycznie takie systemy, Jak się zabrać do tych systemów legacy, bo tych podejścia jest kilka i one wszystkie mają swoje zastosowanie. Myślę, że podkreślę jeszcze raz nawiązanie do poprzedniej wypowiedzi, że najważniejszym w takim projekcie, najważniejszym czynnikiem, czy tam aspektem radzenia sobie z systemami legacy jest odpowiednie zidentyfikowanie, jaki aspekt systemu legacy jest dla organizacji największym punktem bólu. Czy to są kwestie bezpieczeństwa, czy to są kwestie wydajnościowe, czy to są kwestie funkcjonalne, czy jeszcze zupełnie coś innego. Czy to jest utrzymanie, rozwój i tak dalej. Co oczekujemy od tego systemu, co on przestał nam spełniać. Że ten koszt jest za duży w stosunku do wartości, które on wnosi. I w zależności jak odpowiemy sobie na to pytanie, jak postawimy właśnie ten priorytet dla projektu, no to tych podejść może być dużo. Ja mogę powiedzieć o kilku przykładach z mojego doświadczenia, bo miałem przyjemność pracować przy wielu projektach właśnie przejmowania systemów Legacy od innych dostawców, czy brania udziału nawet w takich projektach, gdzie pomagaliśmy wyciągnąć system Legacy. Miałem przyjemność pracować w jednym z projektów, gdzie rzeczywiście była sytuacja, gdzie nowy system od razu po wejściu na produkcję był systemem Legacy, ponieważ architektura była troszeczkę źle zaprojektowana. No i kiedy nas poproszono o pomoc w wyprostowaniu tego systemu, to po wywiadach z zespołem i z użytkownikami właściwie wszyscy mówili trzeba to przepisać od zera co jest jednym ze sposobów radzenia sobie ze systemami legacy no ale jak pewnie się domyślasz, przyjście do klienta i powiedzenie o jezu, kto panu to tak zepsuł. No nie zawsze jest najlepszą strategią, jednak jako poważna firma staramy się unikać tego typu komunikatów, bo to zawsze można łatwo powiedzieć i zrzucić na poprzednika. A więc pierwszą rzeczką zrobiłem w tamtym projekcie to poświęciłem naprawdę miesiąc czasu na odpowiednie zrozumienie tego problemu, tak, na wywiady z biznesem, na warsztaty z zespołem, który tworzył ten system, wtedy już tam nie było architekta, który zapłacił za niepowodzenie stanowiskiem, więc nie było od kogo wyciągnąć tej wiedzy. No a właśnie też na czytanie kodu, rozumienie wzorców architektonicznych, na których został ten system postawiony, no i to pozwoliło mi wypracować takie podejście, gdzie, Stosując trochę podejście właśnie do Mojave & Design, identyfikując bounded konteksty, zidentyfikowaliśmy obszar tego systemu, który może być wyniesiony na bok w prosty sposób, gdzie to spięcie między. Różnymi funkcjonalnościami systemu było bardzo małe, bo to był proces importu jakichś danych do tego systemu, więc łatwo go było wynieść na zewnątrz i wyłączyć go w tym istniejącym systemie. A więc zaprojektowaliśmy nową architekturę, która rozwiązywała problemy, wynieśliśmy ten kawałek na tą nową architekturę, dzięki czemu pokazaliśmy zespołowi na przykładzie, jak ta nowa architektura ma wyglądać, więc oni szybko się zorientowali, wszystko zrozumieli. Jaką mamy wizję i dlaczego ma to działać. No i też od razu klientowi szybko pokazaliśmy, że jesteśmy w stanie dostarczyć wartość w krótkim czasie, mimo że to mały kawałek, no to on zaczął działać dobrze, to odciążyło ten stary system, który też troszkę zaczął działać lepiej dzięki temu. No a z czasem po kolei idąc tym krokiem, czyli to jest właśnie ten podejście dusiciela, wyciągaliśmy kolejne bounded contexty, no bo architekturę aż w końcu przepisaliśmy cały system z czasem, nie psując go. No więc to jest chyba takie preferowane przeze mnie podejście, jeżeli chodzi o systemy legacy, czyli umiejętność zdekomponowania, istniejącego systemu na bounded contexty, niezależne zrozumienie relacji między nimi i zaprojektowanie architektury, która lepiej odpowiada albo adresuje te problemy, które były w starym systemie. I tak. Natomiast też są projekty, gdzie właściwie żeby przepisać system legacji musimy go napisać od zera. Tego typu przykładem był projekt, gdzie istniał system, który był rozproszony w taki sposób, że była centralna baza danych, ale każdy miał swoją aplikację desktopową do pracy z tą bazą danych. To fatalnie działało tam, jeżeli był więcej niż jeden użytkownik, bo nie było wystarczających zabezpieczeń do pracy równoległej. No i nie miało tych funkcjonalności, które biznes sobie życzył. Tam de facto nie było innego podejścia, bo nie będziemy tej aplikacji desktopowej, poprawiać. Przepisaliśmy to na webową i właściwie napisaliśmy ten system od zera na nowo. Więc takie podejścia też stosujemy.

Krzysztof:
Myślę, że zawiodłeś wszystkich tych, którzy pewnie oczekiwali, że lekarstwem na problem z systemem legacy jest zainstalowanie nowej wersji frameworka czy języka oprogramowania.

Krzysztof:
Okazuje się, że ten proces wymaga znacznie więcej kroków. Ale tak zupełnie serio wspomniałeś tutaj o tym, że poświęciłeś całkiem sporo czasu na zrozumienie projektu i na rozmowy z biznesem o tym, jak ten system przynajmniej w taki deklaratywny sposób działa albo powinien działać. I chcę cię zapytać, czy to są takie według ciebie niezbędne, elementy do tego, żeby ten proces migracji całościowej bądź też częściowej mógł się zakończyć sukcesem albo ewentualnie co jeszcze jest potrzebne, żeby w ogóle można mówić o potencjalnym sukcesie właśnie takiej migracji.

Adam:
Tak, żeby zrozumieć, co jest niezbędne, żeby proces zakończył się sukcesem, to myślę, że trzeba odpowiednio zdefiniować sukces, czyli właśnie dokonać tego, analizy punktów bólu, zrozumieć, czemu ten system legacy jest określany jako legacy w organizacji i dlaczego przestał wnosić oczekiwaną od niego wartość albo jest za drogi do wnoszenia tej wartości. No i poświęcić rzeczywiście tutaj czas na zaprojektowanie tego rozwiązania, bo tutaj możemy popełnić, tutaj błąd popełniony na tym etapie kosztuje nas bardzo dużo później. To właśnie jeżeli te projekty, które się nie udają, to moim zdaniem w tym miejscu popełniają najczęściej błąd.

Krzysztof:
W takim idealnym świecie pewnie część tego flow, tego procesu, o którym mówiłeś, dałoby się skrócić do przeczytania dokumentacji, ale wiemy, jak to z tą dokumentacją jest. W teorii powinna odwzorowywać to, jak system działa, jak wygląda architektura, właśnie jakie są te wszystkie elementy składowe. W praktyce wiadomo, że bywa z tym różnie.

Krzysztof:
Jak jako Finture rodzicie sobie właśnie z przebudową tego typu projektów Legacy, gdzie dokumentacja nie jest mocną ich stroną?

Adam:
No to właśnie fajne pytanie, bo potkanie jest z zeszłego roku, Wygraliśmy projekt właśnie na przyjęcie systemu takiego dużego systemu centralnego w jednej z organizacji. No i tam rzeczywiście klient rozstał się z byłym dostawcą w sposób taki nagły, właściwie odcięty z dnia na dzień, więc nie było za bardzo skąd wyciągnąć wiedzy. Dokumentacja, wiadomo, jest nieaktualna w momencie jej napisania, więc nie mogliśmy się na niej za bardzo opierać. na dodatek system był, z dosyć mocno rozproszoną logiką. Część w procedurach w bazie danych, część w back-endzie, trochę we front-endzie, więc rzeczywiście bardzo trudno się było w nim połapać i nasi deweloperzy zaczęli sobie łamać zęby na tym, żeby zrozumieć jak on działa, żeby go umieć utrzymywać, wprowadzać poprawki. No i ponieważ mój dział w tej chwili, bo od ponad już dwóch lat mam przyjemność prowadzić dział R&D w naszej firmie i właśnie tego typu wyzwania, tego typu problemy staramy się adresować w naszych zespołach. Zaczęliśmy kombinować wtedy, jak można tym naszym deweloperom pomóc i w ten sposób. I stworzyliśmy system dokumentowania systemu na podstawie kodu, który stał się później naszym produktem SDOC. No i początkowo myśleliśmy, okej, zacznijmy od po prostu udokumentowania wszystkich klas, czyli wytłumaczymy, co robi dana klasa w kodzie. To prosty skrypt, jedzie AI-em każdą klasę według jakiegoś szablonu, tłumaczy, co ta klasa robi, jakie ma główne metody publiczne, jaka jest logika biznesowa w niej zawarta, jakie ma zależności, No i dzięki temu rzeczywiście łatwo jest taką klasę zrozumieć każdym programiście. Natomiast jak się pewnie domyślasz, stworzenie tylu ile klas, tylu plików z dokumentacją nie pomogło za wiele naszym deweloperom, no bo to nie o to chodzi, żeby zrozumieć pojedynczą klasę, tylko żeby zrozumieć jednak, jak funkcjonalność biznesowa jest zrealizowana na całym zbiorze klas, i którą z nich należy zmienić, żeby tę funkcjonalność naprawić, poprawić, zmienić, tak, więc zaczęliśmy kombinować dalej, idąc właśnie tym tropem do korzystywania AI, który no rzeczywiście bardzo dobrze potrafi tłumaczyć kod, dobrze go rozumie, dobrze go pisze. No ale ponieważ no tutaj się już nie dało tak skryptem przylecieć klas i wyciągnąć z tego funkcjonalności, trochę musieliśmy dać temu AI-owi autonomii, żeby on sam, znajdując jakiś punkt wejścia do systemu, jakąś komendę, jakieś query czy jakiś start procesu, umiał ją prześledzić w dół, wyciągnąć klasy, które ją realizują i opisać tak de facto na tej podstawie tego zestawu klasy, jak ta funkcjonalność jest zaimplementowana. No więc się rzeczy powstało rozwiązanie multiagentowe, gdzie AI jako agent ma swój cel właśnie dokumentowania biznesowo, czy nawet tak architektonicznie tego zastanego kodu, I ma do tego narzędzia, ma do tego narzędzia czytania odpowiednich klas, ma narzędzia analizy relacji między tymi klasami i narzędzia już pisania plików, tworzenia dokumentacji. No i w ten sposób udało nam się właśnie stworzyć te kolejne, warstwy dokumentacji, czyli tą dokumentację przepływów biznesowych w systemie, i dokumentację architektoniczną, czyli podział na komponenty, w ten sam sposób, tylko trochę innymi promptami, ale tak samo podejściem multiagentowym z dostępem do narzędzi. No ale tak, to jeszcze właśnie też nie do końca dało spodziewany efekt, mimo że już mieliśmy dobrą dokumentację, to. Dużo ludzi, właśnie szczególnie, wydaje mi się, osób technicznych ma trochę uczulenie na czytanie dokumentacji biznesowej, czy wolą czytać kod. I dopiero kiedy tą dokumentację de facto wpięliśmy w nasze rozwiązanie regowe, takiego asystenta organizacji, który umożliwia rozmawianie z tą dokumentacją, zadawanie jej pytań, jak coś działa. I dopiero wtedy deweloperzy przyszli i powiedzieli, o, to nam pomaga, to korzystamy z tego, o, super.

Krzysztof:
Czy to jest, to narzędzie SDOC, to był taki protoplasta albo element składowy Legacy Intelligence Platform, który budujecie, jak te dwa rozwiązania tutaj idą ze sobą w parze?

Adam:
Tak, dokładnie tak. W sensie Legacy Intelligence Platform to jest trochę jak nazwa kodowa na zestaw narzędzi, które budujemy do tego typu projektów. SDOC, czyli właśnie umiejętność udokumentowania tego, jak dany system działa, umiejętność wskazania, w jaki sposób są zaimplementowane w nim funkcjonalności, wyekslachowanie tego do bazy danych i umiejętność przeszukiwania tej bazy rozmawiania z nią. To jest taki pierwszy element, który właśnie służy tej części, rozpoznawczej, tej fazie discovery, co ten system tak naprawdę robi, czy tutaj są jakieś ukryte funkcjonalności w tym kodzie i jak one są zrealizowane. Pozostałe dwa elementy tej platformy to jest właśnie ten asystent. Z którym na Teamsach bot, którym możemy po prostu rozmawiać, zadawać pytania o system, dowiadywać się o jego konstrukcji. No a trzecim elementem tej platformy to jest, Apro, czyli nasza autorska implementacja podejścia Specification Driven Development, która de facto, jest taką naszą odpowiedzią trochę na te wyzwania, o których mówiłem na początku, czyli ciągle przyspieszający świat, coraz mniej czasu na zmiany, coraz mniej czasu na utrzymywanie tych systemów i projektowanie. No i tutaj, wierzę, że jestem przekonany, że, Używając podejścia Specification Live and Development, czyli poświęcając więcej czasu na projektowanie rozwiązania na podstawie właśnie tej wiedzy, którą wyciągnęliśmy przy pomocy SDoc z istniejącego systemu, na odpowiedniej dekompozycji, na bounded konteksty, subdomeny i podziale właśnie odpowiedzialności na te komponenty, poświęcając więcej czasu w tym obszarze, a zostawiając generowanie kodu już bardziej dla AI, Jesteśmy w stanie tworzyć lepiej dopasowane i systemy, które lepiej wytrzymają próbę czasu niż przy klasycznym podejściu. I te trzy narzędzia właśnie stanowią fundament tej naszej platformy, Legacy Intelligence Platform.

Krzysztof:
Okej, a jakie są takie przykładowe scenariusze użycia? Najbardziej oczywisty wydaje się ten, o którym wspomniałeś, czyli po prostu dowiadujemy się coś o zastanym kodzie, ale domyślam się, że bazując na tych możliwościach, tych funkcjonalnościach, o których wspomniałeś, na tym się ta paleta nie zamyka.

Adam:
Tak, tak, tak, tak, tak, tak, w sensie to, jak możemy użyć tego narzędzia, no to na wiele sposobów, w zależności oczywiście z jakim problemem próbujemy sobie dać śladę. Natomiast jeżeli chodzi o taki pełen refaktor systemu Legacy, no to możemy tego narzędzia użyć w taki sposób, że z jednej slocy przy pomocy, AIPRO definiujemy sobie, jak taki system powinien wyglądać modelowo. Czyli dokonajemy analizy archetypu tego systemu, szukamy wzorców, sprawdzonych wzorców, które są stosowane w tego typu systemach i tworzymy taki projekt idealny. Czyli powiedzmy taki rynkowy projekt takiego systemu do tego problemu. A z drugiej strony przy pomocy właśnie analizy istniejącego kodu i analizy domeny, klienta jesteśmy w stanie. Wyciągnąć te specyficzne dla danego klienta, danej organizacji informacje i nałożyć je na ten system modelowy stworzony przy pomocy Aprila. I to jest właśnie taki proces, który to narzędzie umożliwia. Czyli jakby z jednej strony mamy całą specyfikę organizacji, z drugiej mamy jakąś, modelową specyfikację, bo to jeszcze nie jest kod, modelową specyfikację takiego systemu, jak ona powinna mniej więcej wyglądać i zderzając jedno z drugim, naciągając właśnie tą specyfikację domenową na ten system modelowy, no tworzymy de facto nowy system zastępujący ten stary.

Krzysztof:
Zastanawiam się, jak się w praktyce używa takiego rozwiązania. Co jest artefaktem, co jest wynikiem końcowym? Kod, dokumentacja, diagramy?

Adam:
Tak jak to powiedziałem przed chwilą, i słusznie zauważyłeś, dokumentacja, diagramy, czyli specyfikacja. Specyfikacja, ale nie taka specyfikacja w rozumieniu dokumentacji po staremu, ponieważ staramy się. Żeby ta specyfikacja była w pełni rozliczalna, czyli ta specyfikacja w jasny sposób dokumentuje, jaka jest potrzeba biznesowa, w jaki sposób system musi działać, żeby tę potrzebę wypełnić, zrealizować i jakie komponenty w kodzie odpowiadają za jej realizację. Przyjmując tutaj odpowiednią właśnie podejście do Domain Driven Design, korzystając z building blocków DDD, no jesteśmy w stanie tą pełną rozliczalność osiągnąć i rzeczywiście jeżeli w trakcie trwania projektu pojawia się. Jakaś nowa okoliczność, nowe wymaganie biznesowe, zmienia się rzeczywistość, to jesteśmy w stanie też przy pomocy narzędzi AI na tę specyfikację dokonać analizy wpływu, czyli zmieniła się potrzeba biznesowa, to sprawdzamy, jak ta zmiana w potrzeby biznesowej wpływa na projekt systemu, jak zmiana w projekcie wpływa na kod, jak to wpływa na już istniejące rzeczy. Jeżeli się pojawia nowa potrzeba, to patrzymy, co musi zmienić się w systemie, co trzeba doprojektować albo przeprojektować, żeby on tę potrzebę wypełnił. I o tyle, o ile to jest system produkcyjny, tutaj mamy ograniczone pole, ale jeżeli jesteśmy jeszcze w tej fazie tworzenia systemu i coś się zmieni znaczącego na tym etapie, no to dzięki narzędziom AI jesteśmy dzisiaj w stanie go wygenerować właściwie od zera, więc nawet, w trakcie właśnie trwania projektu, który tworzenia systemu jeszcze przed włożeniem na produkcję, wyjdzie nam zmiana, która nam trochę zmienia architekturę, zmienia granice między modułami, to w tym podejściu nas to tak bardzo nie boi, tak? Więc jestem przekonany, że jest to podejście bardziej dopasowane do wymagań

Adam:
dzisiejszego świata po prostu.

Krzysztof:
No tak, jeśli tutaj mamy narzędzie oparte o AI, to domyślam się, że język programowania czy framework nie ma pewnie znaczenia, ale czy każdy projekt może być, że tak powiem, w cudzysłowie potraktowany tym rozwiązaniem? Jak się go w ogóle wdraża?

Adam:
Praktycznie każdy projekt. Oczywiście są języki niszowe, których te narzędzia, chociażby analizy relacji między klasami nie obsługują, bo też korzystamy z takich narzędzi i tutaj są jakieś bardziej egzotyczne języki, które nie są obsłużone, bo nie są wystarczająco mainstreamowe, ale w takich głównych językach to właściwie każdy projekt można w ten sposób potraktować z tym narzędziem. Wdraża się go, w zależności od tego, jak duże są tutaj wymogi bezpieczeństwa w organizacji, czy to jest bardziej instytucja finansowa, czy może coś lżejszego, jakiś własny biznes nie obrysający pieniędzmi, to, Można to albo korzystać z naszej chmury, albo można to wdrożyć we swojej infrastrukturze przy pomocy właśnie skonteneryzowanych obrazów dokerowych, które zawierają to nasze rozwiązanie i uruchomić już na własnym repozytorium kodu, żeby ten system dokumentować i dalej z nim pracować.

Krzysztof:
Czy mamy całkiem dużą swobodę? No właśnie, jeszcze tutaj nawiążę do tych możliwości AI, jeśli chodzi o wiedzę czy posługiwanie się różnymi językami, różnymi frameworkami. Wiele osób twierdzi, że ten szczegół implementacyjny w postaci kodu jest faktycznie dość mocno zastępowalny przy wykorzystaniu narzędzi AI, że implementacja dysponując odpowiednio wcześniej przygotowaną dokumentacją, specyfikacją to jest tylko szczegół i właściwie możemy sobie z jednego języka na drugi dosyć swobodnie tą implementację przepisywać. Zastanawiam się, czy ty też tak to widzisz, czy dla ciebie to też jest swego rodzaju nieistotny, można powiedzieć, wręcz szczegół, czy też jednak trzeba się w jakiś sposób przygotować, nawet wykorzystując narzędzia tego typu, o których mówisz, jednak technologia w postaci języka programowania czy frameworka ma znaczenie i nie jest to tak zupełnie obojętne, z czego korzystamy.

Adam:
Na pewno nie jest to w 100% obojętne. Na pewno musimy rozumieć, jeżeli chcemy dokonać transizji z jednego na drugi, a jak należy to przeprowadzić na takim wyższym poziomie, ale w tym też nam AI może pomóc wytłumaczyć i dokonać takiej analizy. AI bardzo dobrze rzeczywiście potrafi czasem rozumować i pokazać nam, wykonać za nas myślenie, czyli możemy spróbować, dokonać analizy przejścia z jednego frameworka na drugi i poprosić o przygotowanie raportu. Natomiast AI, tak jak może wykonać za nas trochę myślenia w danym obszarze, nie wykona za nas zrozumienia tego obszaru. Więc możemy sobie poprosić o analizę, ale to finalnie my musimy zrozumieć konsekwencje, takiej a nie innej decyzji i ją podjąć. Ale jeżeli chodzi o, rzeczywiście, tak jak mówisz, o translację między językami, między frameworkami, to, tak, te narzędzia AI w tego typu projektach transformacji systemów legacy bardzo dobrze się sprawdzają. Mieliśmy, no to nie był duży projekt, to była aplikacja mobilna, która była napisana w, natywnym Swiftie na iOS-a i natywnie na Androida i uruchomiliśmy projekt właśnie przepisania jej na Fluttera. I w założeniu tego projektu było, żeby spróbować wykorzystać właśnie AI tutaj, no i po przygotowaniu planu przepisania, czyli AI, która umie zrozumieć specyfikę zarówno jednej technologii, jak i drugiej, przygotować, zaproponować plan, oczywiście to wszystko jest zweryfikowane i tam opiniowane przez architekta, No ale po przygotowaniu takiego planu ten projekt przepisania takiej aplikacji zajął właściwie dwa dni i zakończył się sukcesem, zamiast dwóch, trzech tygodni, więc tutaj ten zysk rzeczywiście w tego typu projektach jest duży. No ale to są projekty, gdzie właściwie tylko podmieniamy technologię. Rzadko kiedy, To stanowi o problemie z systemem legacy, tak? Raczej systemy legacy to są takie systemy, gdzie wybrana na początku architektura albo zarosła, albo przestała rozwiązywać problem w sposób optymalny. I tam już niestety AI nam tak prosto nie pomoże, bo jeżeli chodzi o taki właśnie upgrade architektoniczny, no to jest zbyt dużo czynników. Ten kontekst, który musielibyśmy AI załadować, żeby ona potrafiła się w tym zorientować, znacząco wykracza poza to, co dzisiejsze modele potrafią przyjąć.

Krzysztof:
Tak, możliwości to jedno, ale też sens biznesowy, czy też finansowy, to pewnie drugie musi to iść w parze.

Krzysztof:
Mówiłeś tutaj o dokumentacji, wspominaliśmy, że może być mniej lub bardziej aktualna. Jak podchodzisz do takiej wiedzy plemiennej, albo wiedzy osób, które przez wiele lat istnieją, gdzieś tam działają w projekcie, wiedzą, jak on działa, to właściwie tutaj dokumentacja można powiedzieć, że jest żywa. Jak sobie radzić z tym problemem, jak wpisywać to w ogóle w działanie mechanizmów, rozwiązań tego typu, o których dzisiaj mówimy?

Adam:
To jest bardzo ważny czynnik, bo rzeczywiście wydobycie wiedzy z istniejącego kodu, z istniejącej bazy kodu systemu legacy, raczej jest niewystarczające, bo ono po pierwsze nie odzwierciedla oczekiwań biznesowych wobec tego systemu, jak biznes wyobrażałby sobie, że on by chciał być, no bo rozumiem, że on takim nie jest, skoro mówimy o systemie legacy, więc. Z tego systemu nie wyczytamy. Nie wyczytamy też takich rzeczy, które nie są w tej bazie kodu, bo tak jak właśnie, nie wiem, cronjobs czy jakieś rzeczy, które są, nie wiem, w pipeline’ie devopsowym, a są istotne, mogą nam umknąć, bo są rozproszone. No albo właśnie jakieś, nie wiem, poboczne integracje przez systemy plików czy coś takiego. No i żeby uniknąć takich sytuacji, przeprowadzić tą fazę rozpoznania, tą fazę projektowania, rozwiązania problemu systemu legacy, uzupełniamy nasze podejście o warsztaty. W szczególności staramy się stosować warsztaty event stormingowe gdzie zbieramy, różne osoby z różnych części biznesu, które dotykają ten system, czy to techniczne osoby czy właśnie użytkowników biznesowych czy właścicieli biznesowych, i dokonujemy z nimi mapowania event stormingowego które polega na tym, że właściwie wszyscy próbujemy, zidentyfikować jak największą liczbę zdarzeń dziejących się w naszej domenie. Dzięki temu uzyskujemy obraz behawioralny tego systemu. Jesteśmy w stanie zrozumieć, jak on się zachowuje, bo jeżeli, pojawiło się zdarzenie, jakieś naliczenie faktury, zaimportowanie faktury czy coś takiego, to rozumiemy, że coś je strigolowało, jakaś komenda, interakcja z innym systemem, więc dzięki temu ten obraz jest pełniejszy dzięki takim warsztatowi. Często właśnie nawet na takich warsztatach zdarzało nam się, że osoby z jednej organizacji, tylko z dwóch różnych działów są zupełnie zdziwione, że takie rzeczy się w tym systemie dzieją i to w ogóle pokazuje ten system w innym świetle, więc ta praca z. Użytkownikami, ta praca z ludźmi, ta praca warsztatowa, analityczna, ona dalej jest w naszym tutaj pipeline’ie, ten AI jej absolutnie nie zastąpi, ale on ją rzeczywiście wzmacnia, zwiększa jej jakość, bo jednak po pierwsze że ta właściwość AI, że on, potrafi dosyć dobrze strukturyzować mił strukturyzowane dane, czyli właśnie jakieś notatki z warsztatów, transkrypcje ze spotkań, czy jakieś dokumenty biznesowe i wyciągać z nich wnioski i przedstawiać raport, no to to rzeczywiście przyspiesza, zwiększa efektywność i podnosi jakość naszej pracy. Ale dalej trzeba z tymi ludźmi porozmawiać, trzeba ich zaprosić, trzeba dać im możliwość podzielenia się swoją wiedzą.

Krzysztof:
Właśnie to jest według mnie bardzo ważny aspekt z mojego doświadczenia. Wynika też, że warto zaprosić taką osobę, warto pozwolić jej podzielić się wiedzą, niejako zabłysnąć na tego typu spotkaniach. I w ten sposób często, w sposób taki nieoczywisty, zyskujemy ambasadora zmian, który to będzie te planowane zmiany, gdzieś tam później pchał, gdzieś dalej o nich mówił i wdrażał. Myślę sobie, że to jest też niezwykle istotne, żeby nie narzucać wszystkiego z góry, aby raczej pozyskać właśnie osoby, które gdzieś będą z wewnątrz też upatrywały sens w planowanych zmianach.

Adam:
Zdecydowanie tak.

Krzysztof:
Tutaj tą dzisiejszą rozmowę prowadzimy trochę na kanwie raportu, który dawno jako Finture opublikowaliście. Raportu od długu technologicznego do poprawy zwinności biznesu, skuteczna modernizacja systemów legacy w praktyce. Do kogo ten raport jest adresowany? Co można w nim znaleźć?

Adam:
Właściwie raport jest adresowany do, wszystkich osób pracujących w branży, ale szczególnie do osób, które czują, że ich systemy może nie do końca są sprawne, nie do końca już spełniają swoją rolę i co z tym zrobić, tak? Czy takie problemy też mają inni? No, nie będę tutaj się rozwodził dokładnie, co można znaleźć w Laporcie. Zapraszam do lektury. Można go odnaleźć na stronie ITWIS, jak i zarówno na naszej stronie firmowej. Chyba zaproszę do czytania.

Krzysztof:
Jak najbardziej dla ułatwienia link, czy też linki oczywiście będą w otaczce do odcinka. Adam, ja Tobie dziękuję za bardzo interesującą rozmowę już po raz drugi, mam nadzieję, że nie ostatni. Powiedz proszę na koniec, gdzie Cię możemy znaleźć w internecie?

Adam:
Ja tak w internecie za dużo się nie udzielam raczej jestem introwertykiem i, nie szaleję na mediach społecznościowych, ale oczywiście jest mój profil LinkedIn, który tam czasem zaglądam i czytam wiadomości, jeżeli ktoś byłby zainteresowany kontaktem w sprawie jakichkolwiek tematów, które poruszaliśmy, to bardzo chętnie wchodzę w interakcje one on one, chętnie odpiszę właśnie, jeżeli chodzi o merytorykę tutaj zagadnienia i jakieś doradztwo, czy, nawet podzielenie się własnymi doświadczeniami Super.

Krzysztof:
Zatem tam odsyłamy. Odsyłamy też do raportu, w którym oczywiście twoje komentarze do wybranych elementów również się znajdują. Myślę, że to będzie takie dosyć fajne i ciekawe rozszerzenie tego, o czym dzisiaj mówiliśmy. Zatem jeszcze raz dzięki za rozmowę. Do usłyszenia. Cześć.

Adam:
Dzięki, cześć.

Krzysztof:
To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, Archiwum czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Możesz się ze mną skontaktować na social mediach albo mailowo na krzysztof@porozmawiajmyoit.pl. Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o radzeniu sobie z wyzwaniami systemów legacy. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!