Cześć, moim Waszym gościem jest IT Deputy Director w mBank SA, doświadczony deweloper i architekt oprogramowania, lider zespołu i menadżer w mBanku, z którym związany jest zawodowo od kilkunastu lat. Specjalista takich technologii jak .NET, CC++ i JBasic. Moim Waszym gościem jest Leszek Włodarski. Cześć Leszku i witaj ponownie w moim podcaście. Cześć Krzysiek, miło mi, że ponownie możemy rozmawiać. Właśnie ostatnio rozmawialiśmy trzy lata temu, jak się okazuje, ten czas bardzo szybko leci i wówczas tematem naszej rozmowy było to, jak to jest być inżynierem w banku. Dzisiaj niejako będziemy kontynuować ten temat, ponieważ na kanwie dużej zmiany technologicznej w części korporacyjnej banku. Będziemy rozmawiać o tym, jak to jest, gdy bank wdraża nową platformę, adaptuje nowoczesne technologie, więc oczywiście jest to kontynuacja rozmowy o różnych praktykach inżynierskich. Myślę, że to nam się tutaj dobrze jedno z drugim będzie łączyło.

Zmiany w Liście Podcastowej

Zanim do tego przejdziemy, to chciałbym cię Leszku zapytać, czy coś się zmieniło na twojej liście podcastowej od naszej ostatniej rozmowy? Tak, jest jedna duża zmiana.

Tak jak mówiłeś, spotkaliśmy się trzy lata temu i ja wtedy bardzo uważałem, żeby nie mówić o tym projekcie, o którym dzisiaj będziemy mówić. I trzy lata temu trochę się zamknąłem w sobie, więcej pracowałem, mniej słuchałem, więc lista nie wzbogaciła się, nie zmieniła. Raczej kontynuowałem ten trend, o którym wtedy rozmawialiśmy. Jasne. Dobrze, to chciałbym Cię właśnie poprosić na wstępie, żebyś opowiedział o tym dużym, wówczas tajemniczym projekcie, który zajawiłeś podczas naszej ostatniej rozmowy, projekcie Houston, czyli dużej zmiany technologicznej w części korporacyjnej mBanku. Na czym ten projekt polegał, z jakich etapów się składał? No dobrze, to tak. Projekt Houston to taki projekt transformacja. Kiedyś mówiliśmy na to re-platforming, bo mówił tylko o technologii, ale na końcu okazało się, że to jest taka pełna transformacja w obszarze core banking w części korporacyjnej, bo to jest migracja całego kodu źródłowego systemu ze starych technologii. Mieliśmy taką technologię J-Basic do .NET-a, bazę danych ze starej technologii J-Base do Postgresa, to też migracja User Interface i User Experience, jakby zupełna poprawa, zmiana ze starego Visual Basic, którego na szczęście nawet nie mieliśmy kodów.

Do nowoczesnej aplikacji webowej, Angularowej, gdzie nasz pracownik banku, bo to jest aplikacja używana przez pracownika banku, Tak jak każdy cywilizowany człowiek jest w stanie wysłać sobie link do danej transakcji, do danego obiektu. W starym systemie to było niemożliwe. To też jest zmiana API.

Aż strach powiedzieć, że ten stary system opierał się na telnecie, to było ten główne medium komunikacyjne i odbrzymia zmiana, transformacja w obszarze developer experience. To jak pracują developerzy, to co robią, w jaki sposób, to była też duża zmiana i z tej perspektywy dobrze, że to zajęło 9 lat, bo mieli czas na to, żeby się zaadaptować. To też nowe podejście do jakości. Gdy zaczynaliśmy projekt, testów automatycznych, które weryfikowały działanie systemu, mieliśmy mniej więcej zero. Teraz te liczby wchodzą w tysiące, o tym też będę mówił, więc w zasadzie zmieniło się wszystko w obszarze core banking. Od technologii, po zespoły, jak ludzie pracują, w czym pracują, te techniki inżynierijskie, to też jest coś, co się zmieniło. A to wszystko robiliśmy i to było bardzo ważne założenie tego projektu bez zatrzymania rozwoju biznesu. Nie wyobrażam sobie, żebyśmy 9 lat temu zatrzymali biznes, powiedzieli, no sorry, teraz już nic nie robimy, migrujemy system. I teraz jakby spytałaś o etapy projektu. Z perspektywy czasu mogę je nazwać. Wtedy, gdy to robiliśmy, to etap był zawsze taki, za rok kończymy. My co roku kończyliśmy projekt, tak planowaliśmy pracę, no bo okazywało się, że to jest w ogóle jest w ogóle bardzo skomplikowane to, co jest przed nami. Jakby tak się teraz zmusić nazwać te etapy.

Definicja problemu to była bardzo ważna rzecz, bo w ogóle zaczęło się od czegoś błahego. Szef powiedział, Leczek, musimy bazę wymienić, ta stara zupełnie nie funkcjonuje, nie sprawdza, nie wyryfkuje danych i w ogóle ten disaster recovery to jest w ogóle dramat. Więc wymieńmy bazę. Szybko się okazało, że to jest cała platforma, to jest język czwartej generacji, to tak brzmi dumnie, więc to jest i język programowania, i baza danych, i cały runtime, który jest pod spodem, który w zasadzie musimy wymienić, no ale ważne było dojść do tego, że to nie jest tylko baza danych, więc jakby sama definicja problemu. Potem była coś, to była jedna z piękniejszych przygód, którą tutaj przeżyłem, to jest translacja kodu. Wybraliśmy ścieżkę translacji kodu automatycznej, nie przepisania ręcznego, tylko automatycznej translacji z jednego języka w drugi. I to była naprawdę czysta frajda, taka czysta inżynierska praca AST, Abstract syntax tree, analiza kodu, budowanie z tego dotneta, naprawdę super sprawa, to o tym też. Potem jeszcze mam nadzieję, że będę mógł opowiedzieć.

Potem szybko się zorientowaliśmy, że tego systemu, core banking, serice banku, nikt nie przetestuje ręcznie. Przez lata, wtedy 13 lat developmentu, 15 lat developmentu, przez lata on powstawał, był budowany, były dokładane kolejne funkcjonalności, ale na końcu nikt nie wie jak on powinien działać. Więc założyliśmy, że bez testów automatycznych, bez podejścia do tego, jak zweryfikować, że ten system tak samo dobrze i tak samo źle działa, bez tego nie mamy szans się wdrożyć. No i też marzyło nam się, żeby to robić w sposób pływający, to znaczy migrację wykonać pływająco, więc bezpiecznie, w jakiś sposób, krokowo, nie robić big bang. Bo ponoć statystyki mówią, że nie dość, że projekt, który trwa dłużej niż 3 lata, ma 30% mniej szans na sukces, to jeszcze takie transformacyjne projekty 3 na 10 kończą się sukcesem.

To jeszcze Big Bang powoduje, że 50% jest szans na to, żeby się projekt udał. Więc bardzo marzyło nam się, żeby tego nie robić w ten sposób na Big Bang. Więc cały duży wysiłek, był taki etap, który pamiętam, gdzie jakość, testy, jakość, weryfikacja, to były te rzeczy, które były istotne. Po drodze staraliśmy się wyłączać te elementy systemu, które nie rokowały w nowym świecie, chociażby klientobarty od interneta, tego nie chcieliśmy zostawić. Więc to co mogliśmy wyłączaliśmy to też jest coś co.

Ważną cechą inżyniera umieć zrezygnować z czegoś i coś zamknąć w końcu i tu też mieliśmy całkiem niezłe sukcesy ostatnia prosta to była walka o wydajność, to były to ostatnie testy z biznesem już wtedy na pokładzie no i Big Bang, ostatni etap największy, jednak mimo wszystko nie było wyjścia ale o tym też jeszcze opowiem.

Ale tak jak mówię, z roku na rok zawsze myśleliśmy, że skończymy w tym kolejnym roku, więc to planowanie nam nie wyszło, ale to też jest właśnie specyfika tego systemu, albo core bankingu w ogóle. To jest bardzo wrażliwe miejsce na błędy i bardzo musieliśmy być ostrożni. Tak, czyli duża rzecz, znacznie szersza niż tylko zmiany technologiczne.

Jestem przekonany, że wiele lessons learned, które będę dzisiaj chciał też tutaj od Ciebie wyciągnąć, ale właśnie powiedziałem, że to jest takie miękkie podbrzusze, że to jest bardzo wrażliwa część całego banku. Jakiś czas temu rozmawiałem z Michałem Niedźwieckim właśnie o takiej zmianie w tej części detalicznej. Tutaj dzisiaj poruszamy temat związany z częścią korporacyjną, więc w sumie powinienem zacząć od zapytania Ciebie, czym właściwie jest ta część korporacyjna banku i czy jest jakaś specyfika tej części, która wpływa na to, że zmiana technologiczna, o której rozmawiamy, no właśnie czymś się charakteryzuje jest jakaś inna, specyficzna. Już ostatnio o tym trochę rozmawialiśmy. Czym jest część kooperacyjna? To na pewno mniejsza liczba transakcji niż w części detalicznej. Natomiast mają one swój ciężar. Poza taką naturalną konsekwencją obsługi dużych firm, czyli czasami kilkadziesiąt tysięcy przelewów od jednego klienta naraz, mamy na przykład międzybank, czyli obsługę rachunków banków zagranicznych, banków polskich.

I to jest czasami kilka tysięcy przelewów dziennie, ale na kwotę około 150 miliardów polskich złotych. A gdy to wszystko dzieje się około godziny 16, łatwo sobie wyobrazić, że błąd w tym momencie, w tym miejscu może być bardzo, bardzo bolesny. Nawet proste odsetki od takich kwot są olbrzymie. I to są te zasady, które rządzą korporacją. Tutaj mamy dużych klientów, mamy duże transakcje i do tego duży wpływ na rynek bankowy w Polsce. Czy ta część korporacyjna, no właśnie w kontekście platformingu jakoś wpływała, ta specyfika tej części korporacyjnej wpływała na to, że musieliście inaczej podejść do zmiany platformy, czy też ta operacja na otwartym sercu właśnie w jakiś specyficzny sposób przez to musiała przebiegać? Na pewno ważne było to, że to było kilkanaście lat developmentu, który wprowadził bardzo dużo produktów szytych na miarę. To też jest powód, dla którego my z tym systemem, który mamy, mieliśmy, zostaliśmy, bo jest uszyty na miarę. Bardzo specyficzne, bardzo dedykowane. Często ważne było, żeby raz dziennie dany proces uruchomił się, przetworzył dwie transakcje. To było na ścieżce krytycznej. My wyizolowaliśmy około 600 procesów, takich, które działają w tym naszym systemie.

Mniej więcej też podobną liczbę funkcji API, które są wykorzystywane codziennie z perspektywy zewnętrznych systemów, zewnętrznych do core bankingu. No i część z nich była rozwijana kilkanaście lat temu i ludzie, którzy to definiowali wymagania do tych funkcjonalności którzy to dewelopowali, już dawno z nami nie pracują i to było duże wyzwanie tak naprawdę to było to największe wyzwanie no bo w tych wszystkich obszarach w których pracujemy na co dzień bo tam toczą się projekty, życie regulacyjne, mamy tam doświadczenie mamy już teraz dużo testów automatycznych to wszystko jest coś, czego byliśmy pewni, najgorsze były te obszary które faktycznie przez dawę, od dawna nie były dotykane i modyfikowane i w zasadzie wkraczaliśmy tam znowu po raz pierwszy. Z tego co rozumiem, projekt Houston jest swego rodzaju parasolem, takim czymś, co łączy wiele różnych działań. Jego elementem jest projekt Globus.net. Prosiłbym, żebyś może właśnie chwilkę o tym opowiedział. Skąd wynikała potrzeba replatformingu właśnie w postaci projektu Globus.net i w jakich obszarach IT był realizowany? Tak, masz rację. W zasadzie można byłoby powiedzieć, że Houston był programem, który zaczął się 9 lat temu.

Składał się z wielu ścieżek. Ta, na które się koncentruję, to jest GlobusNet i migracja, transformacja systemu centralnego, Korkbanking. No i wszystko zaczęło się od takich wstrząsów przepowiadających, że za chwilę będzie problem. Zrobiliśmy coś zupełnie prostego 9 lat temu, może 10 lat temu, czyli zaktualizowaliśmy system operacyjny, na którym działał nasz system bankowy i, No i całość nam się zatrzymała. Szybko to odkręciliśmy, wycofaliśmy te zmiany, które były wgrywane na poziomie systemu operacyjnego. To jest coś, co większość developerów w ogóle nie zdaje sobie sprawy, że my też patrzujemy systemy operacyjne. I już 6 miesięcy później mieliśmy diagnozę, że to było jedno takie pokrętło, które się zmieniło, które się okazuje, że ono już nie pasuje do naszej starej bazy danych, bo ona już wtedy była stara. Rok później wydarzyła się kolejna sytuacja trudna, to znaczy błąd w kodzie, ale takim starym kodzie, który był niedotykany przez pewnie 20 lat, jeszcze nawet nienapisany w Polsce, spowodował, że w wyniku innych naszych rozwiązań, które się otoczyły i zaczęły działać w systemie produkcyjnym, mieliśmy duży problem, duży błąd w systemie, który potem sprzątaliśmy.

No i te dwa wstrząsy, to było enough, żeby stwierdzić, że stoimy nad krawędzią, coś trzeba zrobić, bo te dwa razy sobie poradziliśmy, ale co dalej będzie? Technologia, którą mamy jest długim technologicznym, jest nierozwijana, niewspierana, nie jest nowoczesna.

Mamy monolit, który jest posadzony na jednej maszynie i mamy jakiś disaster recovery, które na szczęście nie musimy z niego korzystać. Do tego wszystkiego, nasze wszystkie próby unowocześniania tego systemu, stosu technologicznego, kończyły się na tym, że w tym systemie operacyjnym, w którym pracowaliśmy, nie było open source’a, nie było nowych płatnych bibliotek, ciężko było cokolwiek zrobić, co miało znajome nowoczesnego developmentu. Użycie web serwisów prawie niemożliwe. Zrobiliśmy to tak naokoło. Resty, konsumpcja restów prawie niemożliwa. Wszystko było trudne, wszystko było bardzo trudne. Na szczęście wtedy jeszcze skala developmentu w systemie centralnym nie była duża, no bo wszyscy czuli, że tam się ciężko cośkolwiek robi, więc budowaliśmy na zewnątrz, naokoło. Ale w 2011 roku, to ja pamiętam, to było już po roku trwania naszego projektu, rozpoczęła się taka i nie skończyła ścieżka projektów regulacyjnych. Po drodze był spółpayment, jakiś MIFID, teraz mamy ISO. Projektów regulacyjnych, które już nie da się zrobić nigdzie indziej, one muszą być zrobione w systemie centralnym. No i całe szczęście, że my zaczęliśmy to 9 lat temu, bo teraz mamy możliwość realizowania tych projektów w sposób wydajny. Jeśli chodzi o te obszary, w których my pracowaliśmy.

To dotknęło na końcu całego IT, który pracuje z częścią konkuracyjną, no bo dotknęło samego systemu centralnego zespołów deweloperskich. Nasi administratorzy bardzo dzielnie pracowali nad tym, żeby zaupgridować, przygotować nowe środowiska, żeby je testować, weryfikować. W ogóle przez te 9 lat wydarzyło się bardzo dużo w świecie bankowym, w IT bankowym, dostosowaniu do regulacji, które powodowało, że my zawsze mieliśmy ruch, zawsze coś się musiało dziać. nie mówiąc o pandemii, która w ogóle zrobiła swoje.

Czyli mamy tutaj dane z powiązaną bazą danych, mamy infrastrukturę, mamy testy, no i oczywiście kod aplikacji. Czy te wszystkie obszary były, można powiedzieć, migrowane, ulepszane równocześnie, czy też może było to jakoś podzielone na etapy? Najpierw infrastruktura, później kod w takim tradycyjnym pojęciu właśnie, jak to do tej migracji tych poszczególnych obszarów podeszliście? My zaczęliśmy oczywiście od kodu, pracujemy w Software House, ale to też dlatego, że zrobiliśmy duży ruch w tym okresie.

Duży ruch shift left, czyli tak naprawdę ta infrastruktura ostateczna powstała na końcu, to nie jest do końca prawdą, to też o tym za chwilę powiem. To wszystkie elementy się przenikały, no bo sukces w migracji danych spowodował, że mogliśmy zacząć myśleć o testach automatycznych. Jak myśleliśmy o testach automatycznych, które nam się udały, mogliśmy myśleć spokojnie o dużym rozwoju runtime’u i platformy. Duży rozwój runtime’u spowodował, że mogliśmy myśleć znowu o testach automatycznych i tak każdy mały sukces w tym obszarze powodował, że powstawały nam nowe możliwości, otwierały nam się nowe drzwi do tego, żeby ten projekt z sukcesem i wbrew wszystkiemu o co można było wymyślić 9 lat projekt, Wbrew wszystkiemu, w sposób optymalny doprowadzić do końca. Więc każdy z etapów, każdy ze strumieni, które staraliśmy się izolować, żeby nie miało na siebie wpływu, każdy dawał coś od siebie i to powodowało, że byliśmy w stanie zrobić duży zazwyczaj krok w pozostałych obszarach. Wspomniałeś tutaj o monolicie w tym pierwotnym wydaniu systemu. Jak teraz wygląda architektura całego rozwiązania?

Jakie takie główne możliwości daje teraz ta architektura w stosunku do tego, co było wcześniej? Więc tak, przede wszystkim jesteśmy na nowoczesnym stosie technologicznym. Większość systemu mamy na klastrze kubernetasowym, więc mamy skalowanie wbudowane w rozwiązanie. Nie dlatego, że kubernetesa, ale dlatego, że tak to zaplanowaliśmy i faktycznie z tego skalowania już skorzystaliśmy, żeby zwiększyć wydajność systemu. Pod spodem mamy nowoczesną bazę danych, która działa w trybie Master, Slave, Active, Passive. To jest też coś, co spowodowało, że zarówno z Kubernetesem, jak i z nowoczesną bazą danych, nasze disaster recovery jest, liczy się w minutach, ale możemy spać spokojnie. Wiemy, że ten element infrastruktury działa poprawnie. Na DSR, bo to jest na DSR, w takim dużym systemie UI jest troszeczkę na DSR. Aplikacja webowa oparta na angularze cały kod systemu w dotnecie chciałem powiedzieć w najnowszym dotnecie ale niestety 3 tygodnie temu pojawił się dotnet 10.

Tego ruchu jeszcze nie zrobiliśmy, ale tak, .NET Core, 8 to jest to, na czym pracujemy i to, co najważniejsze, my przez te 9 lat stopniowo, krok po kroku, robiliśmy upgrade w platformie .NETa do coraz to nowszych wersji. I to jest ważne, my jesteśmy gotowi na kolejny upgrade w związku z tym, mając tam tysiące, czterdzieści tysięcy testów automatycznych, które weryfikują jakość działania platformy, jesteśmy gotowi na 10 i na to, co przyniesie dalej świat. Co wbrew pozorom jest bardzo ważne no bo w tym starym systemie monolitycznym w tym obszarze nie było zawirowań, bo my od 2004 roku nie zrobiliśmy upgrade do technologii, no i nikt nie zauważył tego braku tak, o disaster recovery mówiłem to jest bardzo ważny element coraz bardziej ważny element, szczególnie gdy zaczynamy się rozpraszać i bardzo ważne to co z nami zostało i jest i to ja wrzucam w architekturę rozwiązania to są testy automatyczne Mamy takie narzędzie, które budowaliśmy zaraz na samym początku Hustona, które miało za zadanie wycisnąć z organizacji testy automatyczne. Chodziło o to, żeby je dobrze zdefiniować i móc automatycznie wykonać. Nazwaliśmy je Squeezer.

No i zaczęło się oczywiście od zera testów, potem stu testów. Teraz mamy około pięciu tysięcy testów, które są wykonywane codziennie na trzech środowiskach. Każde środowisko, każde te pięć tysięcy testów to jest czterdzieści tysięcy, pięćdziesiąt tysięcy kroków testowych, które kiedyś, zażertuję, robił biznes ręcznie. Oczywiście, że nie robił. A teraz mamy je w cyklu dziennym uruchamiane i ten nasz shift left jest naprawdę super. I pamiętam ten dzień, kiedy no właśnie, jeden z etapów rozwoju tego narzędzia to nie było to, żeby mieć jak najwięcej testów automatycznych, tylko żeby móc diagnozować błędy, które mamy na produkcji w stałym środowisku, które, uwaga, to narzędzie nie było dla deweloperów, tylko było dla analityków, dla użytkowników biznesowych, tak żeby oni byli w stanie bardzo łatwo wprowadzić przypadek testowy i pokazać deweloperowi, że jest błąd. I pamiętam taki wieczór, godzina 18, taka jedna z analityczek, najlepsza, którą mieliśmy w zespole, Superbeata, wstaje w pewnym momencie od komputera i mówi, mam to.

Powtórzyłam, błąd produkcyjny. i zrobiła to w narzędziu, zrobiła to, ustawiając odpowiednie parametry transakcji w ciągu godziny weryfikując różne możliwości bo miała możliwość eksperymentowania bez tego co do tego momentu było takim naszym developer experience, czyli pełen restore środowiska próba uruchomienia tego jeszcze raz no nie udało się, więc jeszcze raz robimy restore środowiska to był game changer i to jest ważny element teraz architektury nadal to inwestujemy przez te, Grube lata, my te tysiące testów utrzymywaliśmy, to też jest mega ważne. To znaczy, kultura w zespołach zmieniła się właśnie w tą stronę, że my to utrzymujemy, badamy. Jeśli coś jest czerwone, to patrzymy dlaczego.

Bo to też słyszałem o takich eksperymentach, które skończyły się dużą liczbą testów, ale wszystkimi błędnymi. Tak, i teraz to, co jest jeszcze ważne, bo to jakby architektura nie jest dla samej siebie, ona jest po coś. No i teraz my to zrobiliśmy wszystko po to, żeby nam było łatwiej. No i to, co jest przed nami, to jest wszystko. To na przykład sky is the limit. Możemy użyć każdej nowoczesnej technologii, która jest na rynku. Teraz rozmawialiśmy z innym zespołem o projekcie. No i nas pytają, czy możemy użyć strumieniowania. Nie ma problemu. Możecie my użyć resta. To nie ma problemu. Możemy kolejki? Jakiej? Tak, nie ma problemu. Drzwi stoją otworem, bo mamy ten nowoczesny stos technologiczny, który ma wsparcie narzędziowe, ludzie wiedzą jak z tym pracować, na rynku są firmy, które wiedzą co z tym robić, wróciliśmy do żywych. Powiedziałeś tutaj o wielu takich pozytywach dla deweloperów, coś co powoduje, że programiści i deweloperzy są bardziej szczęśliwi, jeśli mają za zadanie coś właśnie dołożyć, coś zmodyfikować. Czy ta nowa architektura, nowy stos technologiczny to również lepszy performance, łatwiejsze operations, rozumiane właśnie jako administrowanie tym systemem, obserwability i wszystko to, co w tym dzisiejszym świecie jest niezbędne, aby monitorować, nadzorować aplikację działającą właśnie produkcyjnie? To był jeden z elementów projektu tak naprawdę.

Musieliśmy wiedzieć, co musimy zmigrować, co musimy ztransformować, I monitoring, observability to były podstawowe klocki, które zbudowaliśmy w pierwszych miesiącach projektu. Bo to też jest… Pewnie ktoś, kto ma jakieś wykształcenie związane z prowadzeniem projektów zastanawia się, jak to jest możliwe, gdzie w dużej instytucji finansowej, w której jest cykl czteroletni, gdzie się zmienia zarząd albo się nie zmienia, mamy dziewięcioletni projekt. On powinien być zatrzymany po pierwszych dwóch latach i potem po kolejnych dwóch latach. To wszystko dlatego, że my co roku, co kwartał, co miesiąc dostarczaliśmy wartość organizacji. Monitoring, observability to było jeden z tych elementów, które mieliśmy zupełnie na początku. Nasze podejście do analizy tego, co się dzieje w systemie. Widoczność, wykrywanie błędów, problemów, to jest nieboziemia między tym, co było kiedyś, a co mamy teraz. Trzeba wziąć pod uwagę, że przez te 9 lat ten ruch transakcyjny w banku rósł znacząco. Trzeba wziąć pod uwagę to, że gdy zaczynaliśmy projekt, to zespół, który zajmował się systemem centralnym, to było około 20 deweloperów. Teraz jesteśmy na poziomie 80-100.

I rośniemy. I to nie dlatego, że potrzebujemy więcej ludzi, bo oni wolno robią, no tylko mamy takie jakby tyle rzeczy do zrobienia, bo regulacje, bo zmiany biznesowe, bo kolejne pomysły. I jak widać, jest jak to robić. Bank widzi to, że może tu inwestować i będzie to dobrze wydany pieniądz. Wspomniałeś tutaj o zespole. No i właśnie o ile nowe klocki, nowe narzędzia, nowe jest tak technologicznie oczywiście bardzo ważny, żeby realizować te kolejne pomysły biznesowe, o tyle odpowiedni zespół jest tutaj niezbędny do tego,

Transformacja i Projekt Houston

żeby cokolwiek mogło się wydarzyć. Jak ten zespół tego wewnętrznego software house, o którym mówiłeś się, zmieniał, jakie kompetencje musiał nabywać w trakcie, aby ten dziewięcioletni projekt dowieźć? To jest w ogóle piękna historia, bo to zaczęło się 9 lat temu. Zespół, w którym zacząłem wtedy pracować, miał swój obszar biznesowy no i było to wyzwanie z migrucie bazy danych, bo ta stara nie ten deres. Więc zaczęliśmy małym teamem, czteroasobowym, który zajmował się tylko i wyłącznie tą migracją badaliśmy co można zrobić, jak można zrobić a obok mieliśmy zespół biznesowy który żył z tym systemem no i to był bardzo ważny układ.

No bo zaczynając od czterech, my tak troszeczkę rośliśmy, co pół roku re-planning zasobów, coraz więcej ludzi, coraz więcej ludzi. Ten zespół też był bardzo ważny w tym początkowym okresie, bo on był blisko mnie, więc było łatwo, on pokazywał, że da się.

Nie musiałem nikogo specjalnie przekonywać, po prostu zaprzyjaździony zespół wykonywał testy automatyczne, wykonywał analizy, było widać, że to wszystko zaczyna działać. To co jest ważne, żeby pokazać innym zespołom, które może trochę nie wierzą, trochę się boją zmiany, może trochę czekają, aż ktoś pokaże, że to da się zrobić, no to drzwi otworzyliśmy. Na końcu pracowaliśmy w czterech, pięciu w sumie intensywnych strumieniach prac około dwudziestu kilku osób, które bezpośrednio pracowały w tym ostatnim etapie nad transformacją, ale to wszystko była kropla w morzu, no bo to miało wpływ na 80-osobowy zespół, który pracował w ogóle nad systemem centralnym, rozwijając go dzień w dzień. W ostatniej fazie to były setki ludzi z biznesu, którzy razem z nami to jakby weryfikowali zachowanie systemu, testowali, pomogli nam zrobić Big Bang i wdrożenie, więc na samym koncie to był olbrzymi zespół, który dołożył kropeczkę na D, tak, że całe te 9 lat wysiłku mogło się wdać.

Pytałem się o kompetencje, które są które były ważne jako, że wcześniej mówiłem o tym byciu inżynierem który używa odpowiednich narzędzi do odpowiednich wyzwań, ja myślę, że to najważniejsze było to ta odwaga, bo to jest odwaga przed zmianą odwaga przed wyjściem ze strefy komfortu, bo zaczynamy robić inaczej, to zawsze wiąże się z pewnymi.

Potencjalnymi problemami, bo ktoś bierze na siebie ryzyko, że, No to może zająć na początku dłużej, więcej czasu. To też odwaga, no bo przez lata wspierając ten system, zajmując się nim tak dzień w dzień, wiemy co to znaczy błąd w tym systemie, wiemy ile on kosztuje, ile on waży, wiemy jak to jest ciężkie później, post facto, po sprzątaniu tego wszystkiego, no i utrzymanie relacji z biznesem czy z klientem. Więc widziałem wiele razy, jak zespół się wahał, żeby ten enter wcisnąć na końcu, żeby na końcu postawić kropkę zdania i ta odwaga była bardzo ważną kompetencją, żeby w ogóle dalej sobie z tym poradzić i to też pewna odwaga, no bo pracowaliśmy w dużej niepewności, tak jak mówiłem, 20 lat developmentu systemu i nie zawsze było tak jak jest teraz, że piszemy testy automatyczne, że mamy ich coraz więcej umiemy pisać dokumentację i piszemy to jeszcze w nowożytnym języku, który.

Daje się jakoś ustrukturyzować, Więc duża praca w niepewności, czy to zachowanie, które obserwujemy, to była intencja dewelopera 10 lat temu, czy może to jest bug, który stał się ficherem, czy może to jest coś, co nas może uderzyć w przyszłości, bo do tej pory nie było takiej transakcji.

No i mieliśmy taki super team, mamy, wszyscy nadal pracujemy, który miał tą odwagę i tą czelność dokonania takiej zmiany odważnej. To jest bardzo budujące, że wspominasz tutaj głównie o tych kompetencjach właśnie takich związanych z postawą, z wewnętrznymi wartościami, a nie ze znajomością kolejnego języka programowania. Myślę, że z perspektywy czasu to właśnie te kompetencje są kluczowe.

Dużo ważniejsze niż ekspertyza z jakiejkolwiek gałęzi technologicznej. Czy te wewnętrzne zasoby, że tak to nieładnie nazwę, były wystarczające, żeby tą migrację, tą transformację dokonać, czy też posiłkowaliście się pomocą z zewnątrz? W początkowej fazie bardzo pomogła nam belgijska firma, która zajęła, to są specjaliści, eksperci od kompilatorów i translatorów i oni, ja myślę, że zupełnie subiektywnie umując, przyspieszyli ten projekt o kilkadziesięć lat. Pamiętam, jak dzisiaj oni po dwóch miesiącach pracy nad dokumentacją, która była mało pełna, to znaczy były takie głosy, że język programowania J-Basic formalnie nie jest językiem. To mówi dużo za siebie, jeśli ktoś zajmował się kompilatorami, a chłopaki w ciągu dwóch miesięcy z tej firmy zrobili analizator kodu, dali narzędzie, które też u nich się sprawdzało, na bazie którego zrobiliśmy translację. I bez nich zrobienie tego to byłoby naprawdę niezłe wyzwanie.

Bylibyśmy dwa, trzy, pięć lat wcześniej tak naprawdę i chyba tego byśmy nie uzasadnili, dlaczego tak długo nad tym pracuję. Tak, ta firma to było super wsparcie. W ogóle ta translacja to jest niesamowita rzecz, która się wydarzyła. Trzystopniowa translacja, pierwszy etap, który pomaga, wyczyścić JBasic w JBasicu, żeby był trochę bardziej czytelny, koszerny. W ogóle magia, którą zrobił zespół z Belgii, czyli pozbycie się takich konstrukcji, które… No wszyscy wiemy, że w nowożytnych językach się tego nie robi, takie jak GoTo, ale w tamtym języku to był chleb powszedni, co łamało strukturę i w ogóle nasz pomysł na translację. Dzięki nim udało się tego pozbyć. Drugi etap translacji to zbudowanie .neta, takiego dotneta, na który rady dotnet deweloperu by nie spojrzał.

Niezmuszony więc trzeci etap to było zrobienie tak, żeby w tym dotnecie było jeszcze więcej dotneta, żeby on był czytelny i był widoczny, no i na końcu efekt mamy taki, że jeśli kod był napisany przez normalnego dewelopera który trochę wie o kodowaniu to ładny kod w jbasicu był ładny w dotnecie, a ten brzydki nadal jest brzydki ale w dotnecie i to co jest istotne, bo zastanawiałem się nad tym punktem. Teraz nam się dopiero otworzyły drzwi współpracy z firmami zewnętrznymi, no bo Postgresa zna kilka firm na rynku. Wie, co z tym robić. Dotneta zna kilka firm na rynku. Kubernetes tak samo. Oprócz tego, że mamy świetnych ludzi w banku, którzy się tym zajmują, to tak, teraz mamy możliwość korzystania z ludzi, z umiejętności, które są na rynku. No bo w tym starym świecie nie byłoby to możliwe. Już.

Konieczność Zmiany Staku Technologicznego

Od kilku lat. Próbowaliśmy, ale nie było już specjalistów.

Z tego co mój żołownika, że właściwie byliście poniekąd skazani na ten ruch, ponieważ pozostawanie w tym wcześniejszym stacku technologicznym groziło po prostu stagnacją, brakiem możliwości rozwoju. To jest ciekawe, to co mówisz, ale nadal COBOL jest i funkcjonuje na świecie. Sam JBASIC, tylko że w nowszej formie w Stanach Zjednoczonych jest językiem, który jest rozpoznawany, ale w zupełnie nowszej wersji, nie to co u nas funkcjonuje od 2004 roku.

Trochę tak, ale jak widać, trochę nie. Moglibyśmy zostać tam, gdzie byliśmy. Ale wtedy pewnie byśmy pracowali w zupełnie innym składzie już. No tak, to jest też ważna rzecz, prawda, że to deweloperzy tutaj, którzy zazwyczaj są zainteresowani raczej bawieniem się nowymi klockami niż wchodzeniem w starsze, są niezbędni do tego, żeby system mogł iść do przodu. No i też taki szeroko rozumiany developer experience mógłby ucierpieć, jeśli faktycznie żadnych nowych technologii do Waszego staku by nie było dodawane. Chciałbym Cię zapytać o metodologię, o takie podejście związane właśnie z praktykami inżynierskimi, z jakimś podziem na zespoły w tych kolejnych etapach.

Metodologia i Praktyki Inżynierskie

Jakie tutaj podejście zastosowaliście? Pamiętam, kiedyś na uczelni byłem Politechnicja Poznańska, jak jeszcze studiowałem, więc dawno temu, wbrew pozorom, i było spotkanie ze znamienitą firmą, jedną z top firm konsultanckich na A, no i mój profesor, który zajmował się inżynierom oprogramowania, zapytał to w jakiej metodologii robicie projekty? I tutaj się zupełnie nie dogadali. Więc cieszę się, że pytasz o praktyki inżynierskie, które używaliśmy.

No bo jak widać, metodologia prowadzenia projektu przez 9 lat jest zupełnie nietrafiona, bo co roku myśleliśmy, że skończymy. Tak, jeśli chodzi o praktyki inżynierskie, to no to były praktyki inżynierskie. My lubiliśmy zmierzyć, my lubiliśmy wiedzieć tak naprawdę z czym się mierzymy, łącznie z tym, że to mocno wpłynąło na nasze observability i opomiarowanie tego, co realnie dzieje się w środowisku produkcyjnym, żebyśmy nie migrowali tych obumarłych tkanek, które troszeczkę bez sensu przenosić. W ogóle walka o jakość, testy automatyczne, automatyzacja, to mówiłem trochę w poprzednim przy podcaście, Ale to jest niby taka oczywista rzecz, a cały czas trzeba powtarzać, że to jest ważne, testy, automatyzacja testów, jakość.

Zadawać takie trudne pytania, jak za 5 lat sprawdzić ten moduł, który właśnie napisałeś? Będziesz pamiętał, co tam jest? Niektórzy młodzi mówią, że będą pamiętać, ale oni są młodzi. Ważnym elementem tych 9 lat było to, że my faktycznie co kwartał, co miesiąc, co pół roku wdrażaliśmy na produkcję coś, co już się wygrzewało. Nasz serwer aplikacyjny, który teraz jest podstawą całej komunikacji Globus Neta ze światem zewnętrznym, był wdrożony 7 lat temu. User interface nowy, aplikacja webowa wdrożona 7 lat temu. Przez te 7 lat było używane oczywiście z różną intensywnością, na początku mniejszą, potem większą, no a dzięki temu nie było zawału w organizacji. Byliśmy, jakby kontrowowaliśmy jakby tą przestrzeń i to wydaje mi się, że też bardzo ważny element, że jednak planowaliśmy to krokowo. Dzielenie się wiedzą to jest temat, który jest trudny i złożony, ale staraliśmy się to robić, praktykować. No bez tego byłoby ciężko zrobić to, co się udało zrobić, czyli mieć zespół, który po transformacji pracuje w dotnecie i nawet nie zauważył, że mu się coś zmieniło. Są pojedyncze osoby, które tak długo pracowały w tym starym świecie, czują się tak mocno ekspertami, że dla nich to przejście było trudne, ale większość zespołu, która pracowała, po prostu przeszła na nowe technologie.

Chociażby pod pretekstem pisania testów automatycznych, już dawno, dawno temu i dla nich to nie był problem. Na samym końcu taka rzecz, która nas spowodowała w ogóle, że to się wszystko udało, to są testy porównawcze. My to nazywaliśmy tak brzydko po polsku testy komparacyjne, takie black box’owe testy i rozwiązanie problemu, jak przetestować jakość w systemie, który jest tak mocno współbieżny, jakim jest system bankowy i jak to zrobić na danych produkcyjnych. No nam się udało, udało się rozwiązać tak naprawdę te zależności i zrobić to w ten sposób, żeby, to testy porównawcze tych 600 procesów, które działają w trakcie dnia w systemie, żeby były miarodajne i żeby pokazać, że faktycznie to zachowuje się bit do bita tak samo jak w starej technologii. To jest chyba w ogóle podstawa tego projektu. W ostatniej fazie oczywiście mieliśmy super project management, który pociągnął temat, bo to już nie była tylko i wyłącznie synchronizacja pracy na poziomie 20 osób, tylko tak jak mówiłem ten.

Zespół ludzki, który zajmował się tym wszystkim był dużo, dużo szerszy ale tak, to są te podstawowe zasady, mierzenie, staraliśmy się też to jest istotne, budować te strumienie prac, które toczyły się równolegle w taki sposób, żeby one od siebie mocno nie zależały żeby one były w stanie pracować w sposób ciągły bez czekania na innych, w dłuższej perspektywie czasu i to jest coś, co To faktycznie spowodowało, że nie musieliśmy rozwiązywać zależności między tematami, zadaniami. No i na końcu się udało. Mamy nowy system w dotnecie, on nowy platformy. Ta współpraca człowieka z technologiem zespołu deweloperskiego z technologią zazwyczaj działa w dwie strony.

Deweloperzy dokonują wyboru technologii tam, gdzie oczywiście mogą. Stosują te praktyki, które technologia nie daje, ale zazwyczaj ta pętla feedbacku działa też w drugą stronę, czyli ten dobór narzędzi inżynierskich wpływa na zespół, na jego kulturę pracy, na takie codzienne praktyki. Czy zauważyliście coś podobnego na przestrzeni tych lat? Razem z nowymi ludźmi, razem z nowymi możliwościami, razem z pojawieniem się do neta Faktycznie ta asymilacja nowoczesnych metod, narzędzi.

Znacząco się zwiększyła, bo ona w ogóle się wydarzyła Bo w starym świecie to był taki dylemat, czy używać Notepad++, czy jakiegoś innego edytora tekstu Nic więcej tam się nie działo Ewentualnie, czy używać takiego klienta Telnet albo innego.

W nowym świecie faktycznie dużo więcej możliwości, nie mówię już o tym co jest w dotnecie typu dot trace i pokrycie kodu testami, to są w ogóle magia, która teraz mamy po prostu pod ręką i możemy z niej korzystać. Ale nawet takie najprostsze rzeczy, to jest istotne, jak debagowanie, to jest coś co zatrybiło w ludziach, którzy do tej pory działali w tylu check-a-na-lisa. Czyli patrzyli na kod tak długo, aż kod się poddał i powiedział, gdzie ma błędy. No teraz można to zrobić pewnie inaczej, tak? Może to jest trochę mniej cierpliwe, może to jest mniej profesjonalne, zdebagowanie tego 50 razy, aż w końcu się znajdzie błąd, ale za to bardziej efektywne. I to jest ważne, to my trochę się do tego szykowaliśmy jeszcze przed projektem, no bo, nasze zespoły były tak skonstruowane, że to nie był zespół, który zajmował się tylko i wyłącznie starą technologią, i tylko tam był ekspertem. Mieliśmy zespoł, który zajmował się i systemem centralnym, i systemami naokoło, które były opisane w dotnecie lub w C++, więc już był ten miks skilli umiejętności, który spowodował, że to nie była taka totalna manipulacja duszami ludzkimi, że teraz dotnet i teraz wpatrujcie się w obrazek. Nie, to było przygotowane.

Większość wskoczyła na tego nowego konia bardzo szybko, bo wiedzieli z czym to się jest, z czym to się wiąże, nie bali się. I potem już ta transformacja w zespołach poszła płynnie. Bank to oczywiście część IT, ale również część biznesowa i musi dochodzić do takiej codziennej współpracy tych dwóch części. Jak ten biznes, tak w cudzysłowie, postrzega, postrzegał projekt Houston? Co dzięki niemu zyskał? No to jest dobre pytanie. W sumie to najlepiej byłoby zadać się biznesowi, ale jakby moja perspektywa tego jest taka uproszczona, bo przez wiele lat biznes nie czuł ciężaru tego projektu. No bo my wzbogacaliśmy developer experience, poprawialiśmy swoje jestestwo, budowaliśmy wiedzę o systemach, robiliśmy testy automatyczne, co tak bezpośrednio tego biznes nie odczuwał. No może jakość się podnosiła tego wszystkiego. Potem był ten etap, kiedy wyminaliśmy UI’a i wtedy był opór przed zmianą. Klasyczny opór przed zmianą jest nowy. Wygląda tak samo, a jest nowy, więc może trochę bez sensu z tego korzystać. Ale jako, że to zaczęło się wcześniej, więc przeszliśmy przez ten opór i mieliśmy wszystkich na pokładzie.

W momencie, gdy robiliśmy Big Bang, ta współpraca z biznesem, którą mieliśmy, na piętrze. Ten Dzień Zero, który obserwowaliśmy, to była piękna synergia pracy ludzkiej. Business IT, jakby te granice się zacierały, tak tak głupie brzmi teraz Business IT. Wszyscy trzymali za nas kciuki, wszyscy wiedzieli, że to jest potrzebne, że to jest ważne. Może dlatego, że były te wstrząsy przypowiadające, może dlatego, że to, co jest przed nami, To jest olbrzymie wyzwanie, które bez nowej platformy, w staryj tego nie dałoby się zrobić. Więc myślę, że i tak słyszałem od zaprzyjaźnionych kolegów z biznesu, że bardzo dobrze zrobiliśmy to, porę skończyliśmy, bo teraz możemy z przytupem ruszyć dalej. Cieszę się bardzo, że taki też jest odbiór, bo to jakby nie było pokazuje, że był sens, ale też dowiezienie się liczy i to, co na końcu zrealizowaliście, jest wartościowe.

Lekcje z Projektu Transformacyjnego

Pora chyba zapytać o lekcje wyniesione z tego wielkiego projektu platformingowego. Dla Was jako inżynierów, też dla osób zarządzających teamami inżynierskimi, co byś mógł tutaj wymienić? To jest dużo elementów, które są oczywiste dla inżyniera. Trochę tak jak, no warto robić testy automatyczne. Niby wszyscy wiedzą, ale tak różnie to wychodzi. Ale po co to robimy testy automatyczne? Ja już kilka razy to mówiłem u nas w zespole, jakże nasze życie byłoby prostsze, gdyby wszystko co robiliśmy przez ostatnie 20 lat miało swoje testy automatyczne. To nie byłby replatforming, tylko zrobilibyśmy kolejny refactoring systemu. Nie, tutaj trzeba było zrobić bardzo dużo, bardzo wiele, no i niby taki lesson learned, ale o którym trzeba cały czas mówić, że tak właśnie mniej więcej, między innymi z tego powodu warto mieć te testy. To mierzenie, inżynierskie mierzenie, postawa inżynierska to jest coś, co jest bardzo ważne i chyba to, że przez 9 lat przesuwaliśmy projekt, jego koniec, nauczyło takiej cierpliwości i to jest coś, co jest chyba ważne na każdym poziomie. Cierpliwości, no bo to nie jest aplikacja do urlopów, no jak nie będzie działać, to nie będzie działać, no nikt nie weźmie urlopu. Dużo bardziej poważne aspekty wchodzą w grę i tak samo chyba ważne to jest z perspektywy zarządzających, że to był projekt, który.

Wyrwał się wszelkim ramą. Bo my nie dość, że trwaliśmy 9 lat, to jeszcze 9 lat bez zmiany nazwy, bo to jest taka sztuczka, czasami zmienić nazwę projektu i wtedy będzie wiadomo, że nowy projekt 2 lata trwał. I utrzymać ten kierunek, wizję i kurs przez całe te 9 lat, mimo różnych zmian okoliczności przyrody. A więc znowu, niby taka rzecz oczywista. Ta wizja, mega ważna, dobrze ją narysować, nazwać, tak żeby wszyscy z tym korelowali. No i iść w tą stronę, Z rozwagą i rozsądkiem nie zawsze po trupach bo mamy deadline, bo się kończy rok i kończy się finansowanie.

Ja tu bardzo szanuję moich szefów, którzy mieli tą otwartą głowę i widzieli sens wprowadzenia tego projektu dalej i dalej. No i to też dzięki temu udało się to wszystko domknąć, mimo tego przeciągnięcia w czasie. I to są chyba te najważniejsze rzeczy, bo tych technologicznych lekcji, które wyciągnęliśmy.

Jak robić software, jak go komponować, jak budować repozytoria, że automatyzacja, to jest bardzo dużo rzeczy, o których już nie myślimy, bo to jest trochę jak tlen, to jest na co dzień, ale jeśli chodzi o duży projekt, duży projekt transformacyjny,

Zakończenie Projektu i Przyszłość

to jest chyba najważniejsze. Czy ten projekt jest oficjalnie uznany jako zakończony, czy też może w jakiejś formie będzie jeszcze kontynuowany? Oficjalnie projekt zakończył się, budżet został zamknięty, jeszcze rok budżetowy się kończy, Ale generalnie projekt zakończyliśmy. W zasadzie można sobie pomyśleć, że to nie był projekt, bo projekt to znaczy jakąś roadmapę, jakiejś milestone. To był trochę rozwój produktu. I tak do tego podchodzimy, że teraz będziemy ten produkt, jakim jest nowa platforma, utrzymywać. Będziemy go rozwijać, no tak, żeby zespoły, które na tym produkcie budują rozwiązania już biznesowe, no żeby mogły działać efektywnie i mogły działać sprawczo. Zostaje mi chyba tylko pogratulować tak dużego sukcesu. Z tego, co mówiłeś, naprawdę dużo energii widać, że Twój zespół, oczywiście przy współudziale całej firmy, został tutaj włożony. Z pewnością wiele cennych lekcji wyciągniętych. No i dobrze jest myślę o tego typu dużej zmianie technologicznej, mówić, bo to też jest inspiracja pewnie dla innych, więc cieszę się bardzo, że mieliśmy po raz kolejne okazje tutaj.

Porozmawiać, no i bardzo Ci dziękuję za to spotkanie. Dzięki. Powiedz jeszcze proszę na koniec, gdzie Cię możemy znaleźć w internecie? Pewnie się nie zmieni względem poprzedniego nagrania. No na LinkedIn’ie i chyba głównie tam. Wszystkie inne miejsca są prywatne, więc prywatnie możecie mnie znaleźć w jeziorze, bo lubię pływać i to jest coś, co się zmieniło w ostatnim czasie nawet jak jest zimno, więc pływatnie, szukajcie mnie w jeziorach super, to tam oczywiście zapraszamy link do LinkedIna i do naszej wcześniejszej rozmowy również znajdzie się w opisie do tego odcinka, Leszku jeszcze raz bardzo dziękuję do usłyszenia, cześć, 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@porozmawiajmy.it.pl Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy.it o tym, jak bank wdraża nową platformę i adaptuje nowe technologie. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!