Jak radzić sobie z wyzwaniami systemów legacy? Gość: Adam Skąpski - POIT 317

Witam w trzysta siedemnastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy są sposoby radzenia sobie z wyzwaniami systemów legacy.

Dziś moimi gościem jest Adam Skąpski – 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 generatywnych sztucznych inteligencji. Próbuje znaleźć sposoby, w jakie może ona wygenerować wartość w obszarze inżynierii oprogramowania.

Sponsor odcinka

Sponsorem odcinka jest Finture.

W tym odcinku o systemach legacy rozmawiamy w następujących kontekstach:

• definicji systemów legacy i ich związku z długiem technologicznym
• wpływu przestarzałych systemów na funkcjonowanie biznesu
• najczęstszych przyczyn nieudanych modernizacji
• strategii radzenia sobie z systemami legacy w praktyce
• warunków skutecznej migracji na nowe rozwiązania
• roli dokumentacji w przebudowie istniejących systemów
• wykorzystania AI do odkrywania wiedzy ukrytej w systemach
• działania i zastosowań Legacy Intelligence Platform
• efektów i artefaktów powstających podczas analizy systemów
• możliwości wdrożenia tego typu rozwiązań w różnych projektach
• granic automatycznego przepisywania kodu z pomocą AI
• znaczenia wiedzy plemiennej i zarządzania wiedzą w organizacji

Subskrypcja podcastu:

• zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
• poproszę Cię też o polubienie fanpage na Facebooku

Linki:

• Profil Adama na LinkedIn – https://www.linkedin.com/in/adam-sk%C4%85pski-24224038/
• Raport „Od długu technologicznego do poprawy zwinności biznesu” – https://itwiz.pl/od-dlugu-technologicznego-do-poprawy-zwinnosci-biznesu-skuteczna-modernizacja-systemow-legacy-w-praktyce/

Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/317

Transcript

SPEAKER_00 0:00

To jest 317 odcinek porozmawiajmy. Dziś rozmawiamy o radzeniu sobie z wyzwaniami systemów

Legacy w praktyce

SPEAKER_00 0:06

legacy. Sponsorem odcinka jest Fincher. Dotatkę, linki i transkrypcję, czyli wszystko to, co porządny słuchacz powinien mieć pod ręką, znajdziesz na porozmawiajmy.plamane na 317. Nazywam się Krzysztof Kępiński, tworzę ten podcast, napisałem też książkę Marka osobista branż 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 Wdziału Elektroniki i Technik Informatycznych Politechniki Warszawskiej, otwartej 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, architektor rozwiązań oraz doradca IT. Zafascynowany postępem w dziedzinie generatywnej sztucznej inteligencji, próbuje znaleźć sposoby, w jaki może ona wygenerować wartość w obszarze inżynierii oprogramowania. Moim waszym gościem po raz drugi zresztą jest Adam Skąski. Cześć Adam, bardzo miło mi gościcie w podcaście.

SPEAKER_01 1:10

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

SPEAKER_00 1:13

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 wariancie, z którym mamy pewnie na co dzień do czynienia, bo będzie dotyczył systemów legacji, 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.

SPEAKER_01 1:56

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 podcast. Ten bardzo ciekawy, o właśnie Spac Leven 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 kogokolwiek, co się interesuje jajem. 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 meczu Go z ruchem 37, z Lisy Do. No to fascynujące rzeczywiście podcast, więc polecam każdemu, kto się AJ interesuje. Ale tak poza tym cały czas się skupiam głównie jednak na audiobookach, tak, te podcasty gdzieś tam w międzyczasie.

SPEAKER_00 2:50

Jasne.

SPEAKER_01 2:50

No i tak, jeżeli ktoś się interesuje geopolityką, to raport to stanie świata dariusza Rosiaka też jest bardzo fajny podcast niezmiennie co tydzień tam wchodzi, żeby się orientować, co tu dalej będzie z tym naszym światem.

SPEAKER_00 3:02

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

Czym jest legacy

SPEAKER_00 3:06

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

SPEAKER_01 3:37

Tak, jak mówisz, tak, system legacji to jest bardzo pojemne pojęcie, i tutaj myślę, że każdy branż rozumie je trochę po swojemu. Ale rzeczywiście możemy w tym pojęciu zmieścić zarówno systemy przestrzeń technologicznie, jak których technologicznie rozwierane, albo systemy zależności na dodania funkcjonalności. Albo po prostu źle zaprojektowane. Jak któryś systemu właściwie legacji na produkcji? No, też nawet takie z którymi technologicznie, nie wszystko jest okej, ale zatwierdziliśmy kompetencje i wiedzy w organizacji funkcjonować jak one działają i defektują sobie system technologicznych. Zarówno na koszty utworzyć rozwijaniem takich systemów, jak i korzyści, jeżeli mamy wystarczałe technologie, aplikacje desktopowe i webowe. Więc te pojęcia są ze sobą bardzo ściśle powiązane.

Skąd bierze się dług

SPEAKER_00 5:24

Niestem to wobec tego dlaczego wiesz, mówimy o problemach wynikających z systemów legacji? Czy to jest jak gdyby taki znak równości trochę, tak, pomiędzy, jakimś potencjalnym problemem w fie, a tym, że ta firma korzysta z systemów legacji, czy zawsze system legacji 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 firm?

SPEAKER_01 5:55

Tutaj dochodzimy do ciekawej kwestii, bo wydaje mi się, że zjawisko systemów legacji 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 zasobna. 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 decyzję 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 Edil, żeby się lepiej dopasowywać, no ale tutaj w tym EJ'u trochę zatleciliśmy tą zdolność projektowania tych systemów odpowiednio i skupiamy się na tym tylko, żeby dowadzić kolejne funkcjonalności. Mało które organizacja jest gotowa na taki sposób pracy długoterminowo. No i ta plesja 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 labiona na skróty, to jest jakiś kolejny punkt w tym naszym długu technologicznym, kolejny zacięgięty kawałek długu. Istotną konsekwencją tego długu technologicznego jest krótko i długoterminowo zdolność systemu do zmiany ewolucji w czasie, czyli odpowiadania na te potrzeby biznesu, które biznes ma i ma ich coraz więcej i coraz szybciej. Ponieważ system zarasta, dług technologiczny rośnie, bo podejmujemy decyzje skrótowe, to coraz ciężej się ten system utrzymuje. Ponieważ 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 z systemu legacy, gdzie wychodząc od tej presji czasu, idąc na skrócie, 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 odzwierciedlenie troszeczkę właśnie tego świata, w którym żyjemy, gdzie ta presja czasu tempo zmian powoduje takie, a nie inne konsekwencje i systemy legacji są tego, moim zdaniem, bardzo dobrym objawem.

Jak modernizować legacy

SPEAKER_00 9:07

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ć impact na działanie biznesu. Natomiast nie ma co też ukrywać, że nie wszystkie te podejścia do unowocześniania systemów legacji kończą się pozytywnie takie 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 tworzonych wcześniej i to się skończyło fiaskiem. Więc trzeba byłoby się zastanowić, i to pytanie jakby tutaj kieruje właśnie do ciebie. Jakie mogą być przyczyny tego, że taka inicjatywa w postaci, zróbmy jakiś update, tak? Wprowadźmy unowocześnienie systemu Legacji, kończy się w efekcie fiaskiem.

SPEAKER_01 10:07

No, to trudne pytanie, bo osobiście nigdy nie brałem udziału w takim klękcie, który zakończył się fiaskiem unowocześniania Legacy, ani nie znam takich 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. Tak, 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, tak, ż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, startujemy go. No i w trakcie okazuje się, że tego nie przewidzieliśmy, że to jeszcze ten system rozmawia z tamtym systemem, albo że robi to i tamto, bo to nic nie był udokumentowany, nikt o tym nie wiedział. Dopiero gdzieś za kamarka kodu na jakimś kurde dysku leży, który jest zaczytywany crą jobem, 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 same idei przepisania systemu legacji, bo de facto od razu już zaczynamy powoli tworzyć bazę pod ten dług, który kiedyś można przytłoczyć i sprawić, że ten nowy system będzie tym systemem legacji, 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.

SPEAKER_00 12:04

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, prawda? Więc mnóstwo zmiany, których po prostu ciężko przewidzieć, ciężko wszystko zaplanować. A też trzeba pamiętać, że ktoś jest sponsorem tych zmian, tak? Ten tak zwany mityczny biznes też ma jakieś swoje założenia, budżet, depliny, o których my nawet jako osoby techniczne nie zawsze musimy wiedzieć, więc te różne perspektywy się mogą właśnie spotkać i gdzieś minąć po drodze,

Podejścia do naprawy

SPEAKER_00 12:57

może w ten sposób. Dobrze dam. 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 legacji radzić w praktyce.

SPEAKER_01 13:11

Jasne, no nie będę tutaj wymieniał za Wikipedią, czy za chatem GTT podejść, jak się klasycznie takie systemy jak się zabrać do tych systemów legacji, bo tych podejść jest kilka i one wszystkie mają swoje zastosowanie. Myślę, że podkreślę, jeszcze raz nawiązuję do poprzedniej wypowiedzi, że najważniejszym w takim projekcie, najważniejszym czynnikiem, czy tam aspektem radzenia sobie systemami legacji, jest odpowiednie zidentyfikowanie, jaki aspekt systemu legacji 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, tak, co oczekujemy od tego systemu, co on przestał nam spełniać, że ten kosz 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 legacji 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 legacyjna, 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. Więc pierwszą rzecz, którym w tamtym projekcie, to poświęciłem naprawdę miesiąc czasu na odpowiednie zrozumienie tego problemu. 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 stanowisk, więc nie było od kogo wyciągnąć tej wiedzy. No ale właśnie też na czytanie kodu, rozumienie wzorców architektonicznych, na który został ten system postawiony. No i to pozwoliło mi wypracować takie podejście, gdzie stosując trochę podejście właśnie do Miglian 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ści 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 wymieć 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 architekturę ma wyglądać, więc fani 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 konteksty na nową architekturę, aż w końcu przepisaliśmy cały system z czasem, tak, 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ść zdomponowania istniejącego systemu na bounded konteksty. 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śnie żeby przypisać 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 nacialiśmy ten system od zeru na nowo, tak. Więc takie podejścia też stosujemy.

SPEAKER_00 18:07

Myślę, że zawiodłeś wszystkich tych, którzy pewnie oczekiwali, że lekarstwem na problem system legacji z zainstalowaniem nowej wersji frameworka czy języka oprogramowania. Okazuje się, że ten proces wymaga znacznie więcej

Co decyduje o sukcesie

SPEAKER_00 18:19

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 chcecie 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?

SPEAKER_01 18:55

Tak, no żeby zrozumieć, co jest niezbędne, żeby proces zakończył się sukcesem, to myślę, że trzeba odpowiednie zdefiniować sukces. Czyli właśnie dokonać tego analizy punktów bólu. Zrozumieć, czemu ten system legacji jest określany jako legacji w organizacji i dlaczego przestał wnosić oczekiwaną od niego wartość, albo jest za drogi wnoszeniu 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.

SPEAKER_00 19:46

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 odzorowywać to, jak system działa, jak wygląda architektura. Właśnie jakie są to wszystkie elementy składowe, no w praktyce wiadomo, że bywa z tym różnie.

Gdy brak dokumentacji

SPEAKER_00 20:09

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

SPEAKER_01 20:21

No to właśnie fajne pytanie, bo pod koniec 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 dociągnąć wiedzy. Dokumentacja wiadomo, jest nieaktualna z momencia jej napisania, więc nie mogliśmy się na niej za bardzo opierać. Na dodatek, system był dosyć mocno rozproszoną logiką. Część w procedurach w bazie danych, część w backendzie, trochę we frontendzie, 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ć, prowadzać poprawki. No i ponieważ mój dział w tej chwili, bo od dwóch ponad już dwóch lat mam przyjemność prowadzić działanie 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 stworzyliśmy system dokumentowania systemu na podstawie kodu, który stał się później naszym produktem S-Dok, tak. No i początkowo myśleliśmy, okej, zacznijmy od po prostu udokumentowania wszystkich klas, czyli wytłumaczmy, co robi dana klasa w kodzie. To prosty skrypt je dziejem 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żdemu 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ć i zmienić, tak? Więc zaczęliśmy kombinować dalej, idąc właśnie tym tropem wykorzystywania Ej, który rzeczywiście bardzo dobrze potrafi tłumaczyć kod, dobrze go rozumie, dobrze go pisze. No ale ponieważ tutaj się już nie dało tak z skryptem przylecieć klasy, wyciągnąć z tego funkcjonalności, trochę musieliśmy dać temu AJ-owi autonomii, żeby on sam znajdując jakiś punkt wejścia do systemu, jakąś komendę, jakiś query, czy jakiś start procesu, umiał ją prześledzić w dół, wyciągnąć klasę, które ją realizują, i opisać tak de facto na tej podstawie tego zestaw 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 czytanie odpowiednich klas, ma narzędzia analizy relacji między tymi klasami i narzędzia już pisania plików, tworzenia dokumentacji. Tak. 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 udziału 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 wydają się, osób technicznych, ma trochę uczulenie czytanie dokumentacji biznesowej czy wolą czytać kod. I dopiero, kiedy tą dokumentację de facto wpięliśmy w nasze rozwiązanie Ragowe 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 super.

Platforma Legacy Intelligence

SPEAKER_00 24:45

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

SPEAKER_01 24:57

Tak, dokładnie tak. W sensie Legacy Intelligence Platform, to jest trochę jaka 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, wyksachowanie 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 Team Sach Bot, którym można 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 Specyfication 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 specyfication Even 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 SDOK-a z istniejącego systemu na odpowiedniej dekompozycji na bounded konteksty, subdominy 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ą takie jakby fundament tej naszej platformy Legacy Intelligent Platform.

Scenariusze użycia narzędzia

SPEAKER_00 27:15

Okej. A jakie są takie przykładowe scenariusze użycia? No, 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.

SPEAKER_01 27:34

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 strony przy pomocy APR definiujemy sobie, jak taki system powinien wyglądać modelowo, czyli dokonujemy 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, dla organizacji informacje i nałożyć je na ten system modelowy stworzony przy Monacla. I też właśnie taki proces, który to narzędzie umożliwia, czyli z jednej strony mamy całą specyfikę organizacji, z drugiej mamy jakiś modelową specyfikację, bo to jeszcze nie jest kod modelą specyfikację takiego systemu, jak ona powinna mniej więcej wyglądać. I zejżając jedno z drugim, naciągając właśnie tą specyfikację domenową na ten system modelowy, tworzymy de facto nowy system zastępujący ten stary.

SPEAKER_00 29:09

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

SPEAKER_01 29:19

Tak jak powiedziałem przed chwilą, i słusznie zauważyłeś, dokumentacja degramy, czyli specyfikacja, tak? Specyfikacja, ale nie taka specyfikacja w rozumieniu dokumentacji powstałemu, bo 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ć i zrealizować, i jakie komponenty w kodzie odpowiadają za jej realizację. Przyjmując tutaj odpowiednią właśnie podejście do mandyw design, korzystając z building blokó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ż przemocy narzędzi AI na tę specyfikację dokonać analizy wpływu, tak? 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, tak? 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 odgenerować właściwie od zera, więc nawet w trakcie właśnie trwania projektu, który tworzenia systemu jeszcze przedłożeniem na produkcję, wyjdzie nam zmiana, które nam trochę zmienia architekturę, zmienia granice między modułami, to w tym podejściu nas to tak bardzo nie boli, tak? Więc jestem przekonany, że jest to podejście bardziej dopasowane do wymagań dzisiejszego

Czy technologia ma znaczenie

SPEAKER_01 31:18

świata po prostu.

SPEAKER_00 31:19

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?

SPEAKER_01 31:35

Praktycznie każdy projekt. Oczywiście są języki niszczę, gdzie te narzędzia, których te narzędzia chociażby analizacji 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. Więc ale w takich głównych językach to właściwie każdy projekt można w ten sposób potraktować tym narzędziem, a 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 obracający pieniędzmi, to można to albo korzystać z naszej chmury, albo można to wydaje się we swojej infrastrukturze przy pomocy właśnie skonteneryzowanych obrazów doktorowych, które zawierają to nasze rozwiązanie, uruchomić już na własnym repozytorim kodu, żeby ten system dokumentować i dalej z nim pracować.

SPEAKER_00 32:39

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ółu i właściwie możemy sobie z jednego języka na drugi dosyć swobodnie tą implementację przepisywać. Znawiam się, czy Ty też tak to widzisz, czy dla ciebie to też jest swego rodzaju nieistotne, można powiedzieć, wręcz szczegółu, czy też jednak trzeba się w jakiś sposób przygotować, nawet wykorzystując narzędzia tego typu, o których mówisz, że jednak technologia w postaci języka programowania, czy frameworka ma znaczenie i nie jest to tak zupełnie obojętne, z czego korzystamy.

SPEAKER_01 33:42

Na pewno nie jest to 100% obojętne. Na pewno musimy rozumieć, jeżeli chcemy dokonać transcyznego na drugi, a jak należy to przeprowadzić na takim wyższym poziomie, ale na tym w tym też nam AI może pomóc wytłumaczyć i dokonać takiej analizy, tak? AI bardzo dobrze rzeczywiście potrafi czasem rozumować i pokazać nam wykonać za nas myślenie, tak, czyli możemy spróbować dokonać analizy przejścia z jednego frameworka na drugi i poprosić przygotowanie raportu. Natomiast AI, tak jak może wykonać za nas trochę myślenia, w danym obszarze nie wykona za nas zrozumienia tego obszaru, tak? Wem 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, to nie był duży projekt, to była aplikacja mobilna, która była napisana w natywnym Swift'ie na iOSA i natywnie na Androida, i uruchomiliśmy projekt właśnie przepisania jej na Flatera, 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óry umie zrozumieć specyfikę zarówno jednej technologii, jak i drugiej. Przygotować, zaproponować plan. Oczywiście to wszystko jest weryfikowane 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, nie wiem, dwóch, trzech tygodni, więc tutaj ten zysk rzeczywiście w tego typu projektach jest duży, ale to są projekty, gdzie właściwie tylko podmieniamy technologię, tak. To rzadko kiedy, to stanowi problemie z systemem legacy, tak? Raczej systemy Legacji, 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, 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ąć.

SPEAKER_00 36:26

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

Wiedza plemienna w projekcie

SPEAKER_00 36:33

parze. Mówiłeś tutaj o dokumentacji, wspominaliśmy, że może być mniej lub bardziej aktualna. Jak podchodzisz do takiej wiedzy plemiennej, tak? 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że 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?

SPEAKER_01 37:04

No 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 taki nie jest, które mówimy o nim, o systemie Legacy, więc z tego systemu nie wyczytamy. Nie wyczytamy też takich rzeczy, które nie są w tej bazie kodu, bo takie, właśnie, nie wiem, kląjby, czy jakichś rzeczy, które są, nie wiem, w pipeline 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 mapowanie 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ś nalzenie faktury i zaimportowanie faktury czy coś takiego, to rozumiemy, że coś jest figerował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 wióź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, ten AI jej absolutnie zastąpi, ale on ją rzeczywiście wzmacnia, zwiększa jej jakość. Bo jednak, po pierwsze, ta właściwość AI, że on potrafi dosyć dobrze strukturyzować i nieustrukturyzowane dane, czyli właśnie jakieś notatki z warsztatów, transkrypcji ze spotkań, czy jakieś dokumenty biznesowe i wyciągać z nich wnioski i przedstawiać raport, no to rzeczywiście przyspiesza, zwiększa efektywność i podnosi jakość naszej pracy. Ale dalej trzeba trzeba z tymi ludźmi porozmawiać, trzeba ich zaprosić, trzeba dać im możliwość podzielenia się swoją wiedzą.

SPEAKER_00 39:56

No właśnie to jest według mnie bardzo ważny aspekt mojego doświadczenia wynika też, że warto zaprosić taką osobę, warto pozwolić jej podzielić się wiedzą, nie jako zabłysnąć na tego typu spotkaniach. I w ten sposób często 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, tak, ż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.

Raport o modernizacji

SPEAKER_01 40:35

Zdecydowanie tak.

SPEAKER_00 40:36

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

SPEAKER_01 40:54

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ę zgodził dokładnie, co można znaleźć w raporcie. Zapraszam do lektury. Można go odnaleźć na stronie IT, jak i zarówno na naszej stronie filmowej. Chyba zaproszę do czytania.

SPEAKER_00 41:27

Jak najbardziej do ułatwienia link, czy też linki oczywiście będą wadać do odcinka. Adam, ja Tobie dziękuję za bardzo interesującą rozmowę. Juaz drugi. Mam nadzieję, że nie ostatni. Powiedz proszę, na koniec, gdzie się możemy znaleźć w internecie.

SPEAKER_01 41:44

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 przeczytam wiadomości, jeżeli ktoś byłby zainteresowany kontaktem 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.

SPEAKER_00 42:14

Super, zatem tam odsyłamy. Odtrzymamy 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ść.

SPEAKER_01 42:31

Dzięki, cześć.

SPEAKER_00 42:32

To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, archiwł czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Może się ze mną skontaktować na social mediach albo mailowo na krzyżomma.prosmaimit.pl. Nazywam się Krzysztof Kępiński, a to był odcinek podcastu porozmawiamy i o radzeniu sobie z wyzwaniami systemów legacji. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!