Krzysztof:
To jest 301 odcinek podcastu Porozmawiajmy IT. Dziś rozmawiamy o tym, jak przepisać system bankowy obsługujący 10 milionów klientów. Sponsorem odcinka jest mBank SA. Notatkę, linki i transkrypcję, czyli wszystko to, co porządny słuchacz powinien mieć pod ręką, znajdziesz na porozmawiajmy.it.pl, łamane na 301. Nazywam się Krzysztof Kempiński, tworzę ten podcast, napisałem też książkę o markę osobista w branży IT i lubię, jak ludzie z naszej branży rozwijają się z głową, a nie na oślep. Możesz mi w tym pomóc, wystarczy, że ocenisz podcast w swojej aplikacji albo puścisz ten odcinek dalej Tylko tyle, bo przecież mówią, że karma wraca No dobra, a teraz odpalamy Cześć, mój dzisiejszy gość to dyrektor Departamentu Rozwoju i Utrzymania Aplikacji w mBank SA. Lider z kilkunastoletnim doświadczeniem menedżerskim w branży bankowej. Od początku kariery pasjonował się programowaniem i inżynierią oprogramowania, co do dziś inspiruje go do wdrażania nowoczesnych rozwiązań IT. Specjalizuje się w zarządzaniu zespołami oraz realizacji projektów transformacyjnych. Odpowiada za rozwój kluczowych systemów bankowych i modernizację platform technologicznych. Moim Waszym gościem jest Michał Niedźwiecki. Bardzo miło mi gościć Cię w podcaście.

Michał:
Cześć Krzysztof, bardzo cieszę się, że jestem twoim gościem.

Migracja z COBOL-a do .NET

Michał:
Witam wszystkich słuchaczy. Mam nadzieję, że ta nasza rozmowa będzie dla was interesująca.

Krzysztof:
Dzisiaj w odcinku rozmawiać będziemy o niewątpliwej przygodzie, jaką jest przepisanie systemu bankowego obsługującego 10 milionów klientów z nieco przestarzałych już rozwiązań opartych o Cobola i Mainframe’a, nowoczesne, oparte o .NET i architekturę rozproszoną. Już teraz możemy zdradzić, że ta podróż kończy się happy endem, A ja będę dzisiaj pytał Michała o to, jak podchodzi się do planowania i przede wszystkim wdrożenia tego typu migracji oraz z jakimi wyzwaniami trzeba sobie radzić po drodze, bo domyślam się, że jest ich sporo. Zanim do tego przejdziemy, to chciałbym Cię, Michał, zapytać, czy słuchasz podcasty i być może jakieś rekomendacje dla naszych słuchaczy będziesz w stanie przedstawić.

Michał:
Tak, słucham podcastów. To dla mnie taki moment, kiedy mogę na chwilę oderwać się od operacyjnej rzeczywistości i posłuchać jak inni myślą o technologii czy o przywództwie. Bardzo cenię CTO Morning Coffee, bo tam nie ma takich tanich sensacji, tylko rozmowy z ludźmi, którzy naprawdę prowadzą złożone organizacje technologiczne. Nie tylko to jest dyskusja o nowinkach w tym podcaście, ale również o tym jak budować trwałą kulturę technologiczną. Kiedyś regularnie też słuchałem Dobrego Przodka, zupełnie inny klimat, ale ten podcast uczył mnie myślenia o konsekwencjach naszych decyzji, a u nas w IT przecież to jest kluczowe. My często podejmujemy decyzje, których skutki będą widoczne dopiero za 5 czy 10 lat, a nie od razu. No i oczywiście porozmawiajmy o IT, Krzysztof, Twój podcast, który znam od dawna i który bardzo cenię za to, że, pokazuję prawdziwe historie z różnych projektów, a ja lubię prawdziwe historie, nie tylko prezentacje sukcesów, ale rozmowę o tym, jak naprawdę wygląda budowanie czegoś naprawdę dużego.

Krzysztof:
Super, dziękuję Ci za tą rekomendację. Niezmiernie miło, że porozmawiajmy o IT też się na Twojej liście znajduje.

Michał:
Jak mogłoby być inaczej? To jest tak fajny podcast.

Krzysztof:
Dzięki śliczne jeszcze raz. Tą naszą dzisiejszą rozmowę oprzemy o jeden z głównych projektów, którym się obecnie zajmujesz, więc myślę, że na początek dobrze byłoby ten projekt właśnie w mBanku przedstawić. Na czym polega, jakie były, jakie są jego cele?

Michał:
Wiesz co, ja w mBanku prowadzę wiele projektów, ale wiemy, o który projekt pytasz. Ja się domyślam i słuchacze pewnie też, więc od kilku dobrych lat prowadzę projekt, w którym zmieniamy fundamenty technologiczne banku. I to jest replatforming naszego systemu centralnego bankowości detalicznej. W mBanku obsługujemy grubo ponad 5 milionów klientów detalicznych i każdego dnia realizujemy miliardy złotych transakcji. Nasz system centralny nie może się zatrzymać ani na chwilę i to jest mega wyzwanie. Ten system centralny jest z nami wiele lat. Na nim postawiliśmy pierwszy bank internetowy w Polsce. Przez niego przez lata wiele w niego inwestowaliśmy i go dalej rozwijaliśmy.

Michał:
Serce tego systemu, tak jak powiedziałeś, jest napisane w COBOL-u, działające zarówno u nas, jak i na świecie, na mainframe’ach. Źródło tego systemu sięga dużo dalej niż w mBanku i naprawdę wiele generacji tych maszyn mainframe’owych przemknęło się przez nasze serwery. Z punktu widzenia historii tej perspektywy mojej na pracę z tym systemem, bo pracuję, tak jak powiedziałeś, w banku już kilkanaście lat, to system stabilny, niezawodny, ale widzieliśmy, że coraz mniej elastyczny z punktu widzenia dalszego rozwoju. Naszym celem było stworzenie nowoczesnej, rozproszonej architektury opartej o serwery x86 i środowisko dotnetowe, które pozwoliłoby nam na skalowanie horyzontalne, a nie tylko pionowe. Nie jest tajemnicą, że rozwiązania mainframe są po prostu drogie. Dają Ci możliwość praktycznie nieograniczonego skalowania pionowego, ale to generuje naprawdę duże koszty. I w pewnym momencie musieliśmy podjąć trudną decyzję. Wymienić system na nową platformę. Tylko stanęliśmy przed pytaniem, jak to zrobić?

Michał:
No właśnie, zaplanować tą modernizację w taki sposób, aby to się odbyło bez zatrzymania banku, bez zatrzymywania biznesu. Wszystko co robiliśmy musiało się dziać na żywym organizmie i to jest tak porównując do życia, do tego co mamy w otoczeniu, dla mnie to jest jak wymiana silni w samolocie. Nie można by było go po prostu wyłączyć, postawić na ziemi i powiedzieć wróćmy do tego za rok. Po prostu trzeba było lecieć w tym samolocie i działać na żywym organizmie.

Planowanie i strategia modernizacji

Krzysztof:
Taka zmiana platformy, wyobrażam sobie, że to nie jest tylko olbrzymi refaktor kodu i całej architektury, ale też konieczność takiej strategicznej decyzji ze strony firmy i w związku z tym nie tylko zaangażowanie się osób technicznych, które oczywiście później są odpowiedzialne za implementację, wdrożenie i utrzymanie, ale też wyobrażam sobie, że cały pion zarządczy musi być tutaj włączony, no bo to jest,

Michał:
Tak jak tutaj wspomniałeś.

Krzysztof:
Wielka rzecz, duża decyzja, która ma przełożenie na realne, codzienne działanie banku. Właśnie, gdybyś mógł powiedzieć, na ile to jest strategiczna decyzja, na ile wymaga to właśnie zaangażowania się całej firmy, ewentualnie jakich działów, które to muszą być zaangażowane w tego typu projekt?

Michał:
Z mojej perspektywy jakby bez dwóch zdań wymaga zaangażowania całej firmy i to nie jest tylko zarząd, albo to nie jest tylko IT, to nie jest tylko biznes, więc jakby podejmując decyzję o tym projekcie, najpierw oczywiście wykonaliśmy proof of concept, zbadaliśmy rynek, ale wiesz, proof of concept, a wejście głęboko w projekt to są dwa światy, więc rzeczywiste podjęcie decyzji o rozpoczęciu projektu wymagało odwagi, Bo mówiliśmy i mówimy o systemie, który działał dobrze, stabilniej i który obsługiwał miliony klientów. Więc trudno w takiej sytuacji było powiedzieć, to działa, ale musimy to przepisać od nowa.

Michał:
Samo prowadzenie tego projektu, utrzymanie priorytetu wymagało nie tylko decyzji strategicznej na samym początku, ale też cierpliwości na każdym poziomie, na wszystkich poziomach ze wszystkich stron, zarówno zarządu banku, zespołu, biznesu, jak i IT w dowolnej kolejności. I to, co było z perspektywy czasu dla mnie najbardziej istotne, to że mieliśmy pełne wsparcie zarządu banku nawet w trudnych okresach, kiedy postęp nie był taki, jak zakładaliśmy. Kiedy podejmuje się decyzje, które nie przyniosą efektu w trzy miesiące, tylko za trzy lata lub więcej, to trzeba mieć ludzi, którzy rozumieją, że to, co robisz, ma sens albo ufają, że to jest potrzebne. I to jest mowa o takim partnerskim patrzeniu na to wszystko ze wsparciem kluczowych interesariuszy, czy to szefa, czy szefa szefa, czy zarządu banku. Także na każdym poziomie, bym powiedział, to zaangażowanie firmy było potrzebne. No nie powiem, były też po drugiej stronie, bym powiedział, wyzwania z tym związane albo poświęcenia, które trzeba było ponieść. No ale tak jak powiedzieliśmy na początku, mamy się z czego cieszyć, dowieźliśmy.

Krzysztof:
To na koniec dnia jest najważniejsze, ale mnie bardzo interesuje cała ta droga, jak doszliście do tego momentu, że możecie powiedzieć, że jest ten projekt, oczywiście nadal jeszcze gdzieś tam po części w trakcie, ale można już śmiało powiedzieć, że z dużym sukcesem wdrożony. Jak wyglądało planowanie, jak wyglądały te kolejne etapy wdrażania migracji? Myślę, że to też od strony technicznej pewnie jest ciekawe dla słuchaczy naszego podcastu.

Michał:
Nie wiem jak głęboko mam wchodzić w śródki, ale powiem tak, od początku wiedzieliśmy, że nie możemy pozwolić sobie na tak zwany Big Bang, jednorazowe przełączenie całego systemu dla wszystkich klientów. To byłby zbyt duży poziom ryzyka i nie oszukujmy się z istotnym wpływem na cały sektor bankowy. Jeśli mBank w jakimś zakresie przestałby działać, czy mniejszym, czy większym, to wszyscy by to zauważyli. Więc przyjęliśmy podejście iteracyjne. I kluczową decyzją na starcie projektu było, bym powiedział, założenie, że zachowujemy jedną linię kodu. Dlatego też wybraliśmy ścieżkę z kompilatorem Cobola.neta. Pracowaliśmy z dostawcą nad tym, żeby dostosował ten kompilator, a nie żebyśmy my zmieniali ciągle linię kodu. Abyśmy przy niewielkich zmianach aplikacyjnych byli w stanie do końca projektu, do samego końca projektu utrzymać założenie, że trzymamy jedną linię kodu. Co więcej, budowaliśmy nowy system równolegle z dotychczasowym, wprowadzając funkcje i domeny biznesowe stopniowo.

Michał:
Najpierw z tego, co pamiętam, zbudowaliśmy taką warstwę wspólną, infrastrukturę, taką warstwę opakowującą te dwa światy w jeden bąbel. Co nam to dało? Że z punktu widzenia świata te modernizowane systemy, bo tak naprawdę to my modernizowaliśmy system, ale zmieniliśmy jego architekturę w środku, z punktu widzenia świata to był nadal jeden bąbel, zupełnie przezroczysty bez wpływu na infrastrukturę zewnętrzną, na systemy, które to wołały. Więc najpierw tak jak powiedziałem, zbudowaliśmy tą infrastrukturę, potem kolejne moduły przenosiliśmy, rachunki, kredyty, płatności, aż później uruchomiliśmy pełną obsługę klientów. Każdy z tych etapów był testowany zarówno funkcjonalnie, jak i integracyjnie. I to nie jest tak, że tylko robiliśmy to w zamkniętym laboratorium, ale w realnym ruchu danych, żeby zobaczyć, jak system zachowuje się przy pełnej skali. I to była z mojej perspektywy ogromna aplikacja, ale taka operacja na ogromnej aplikacji, ale dzięki temu mogliśmy podchodzić etapami. Dzięki temu, tak jak powiedziałem, że zbudowaliśmy tę koegzystencję światów, mogliśmy bez zakłóceń dla klientów i bez ryzyka utraty ciągłości działania przejść przez te kolejne etapy migracji, no bo etapy i niespodzianek było dużo. Czasami się zatrzymywaliśmy, czasami musieliśmy coś przeprojektować.

Michał:
Zrobić krok do tyłu, zatrzymać. Czasami te zatrzymania były dłuższe niż tydzień i miesiąc. Musieliśmy zrobić jakiś refaktor, ale cały czas szliśmy do przodu. Z punktu widzenia świata szliśmy przezroczyście.

Krzysztof:
Tak, o testowanie zapewnienia jakości na pewno będę chciał dzisiaj zapytać, bo myślę, że tutaj jest to kluczowa rzecz. Może małe takie pytanie miałbym jeszcze do tego co powiedziałeś. Zastanawiam się czy z tym uruchamianiem kolejnych modułów, przepisywaniem, migracją kolejnych modułów wyłączaliście stare czy one nadal działają równolegle?

Michał:
My do samego końca, do migracji ostatniego klienta utrzymywaliśmy pełną spójność kodu i uruchamianie modułów na obu systemach. Tak naprawdę to jest dłuższa historia, jak my to zbudowaliśmy technicznie i jak zapewniliśmy tę egzystencję, ale do samego końca zarówno na platformie poprzedniej, mainframe’owej, jak i na nowej platformie x86 mieliśmy pełną kopię funkcjonalności bankowości detalicznej. I to pozwalało nam podejmować decyzję, że idziemy do przodu lub były przypadki, że na przykład któryś klientów, których zmigrowaliśmy, stwierdziliśmy, że trzeba wrócić na starą platformę, bo jeszcze nie jest czas i miejsce.

Krzysztof:
To też daje dużą swobodę i dużą elastyczność i myślę, że też swego rodzaju plan taki zapasowy, backupowy, prawda, bo takie przełączenie, tak jak powiedziałeś, z zera na jedynki w jednym momencie mogłoby być problematyczne i mogłoby zamknąć nam drogę odwrotu. Natomiast utrzymywanie tych dwóch systemów równolegle, przynajmniej przez pewien czas, z pewnością obarczone jakimś tam kosztem, daje właśnie tego typu korzyść, że jeśli zauważymy, że dana rzecz jeszcze wymaga pewnego dopracowania, zawsze możemy wrócić do tego wcześniej działającego i sprawdzonego w boju rozwiązania.

Michał:
Dokładnie, przede wszystkim założenie na wejściu, że nie robisz Big Bangu pozwala ci po prostu iść iteracyjnie i małymi krokami. Nie stoi nad tobą ktoś, kto mówi teraz trzeba zmigrować milion klientów. My założyliśmy, że lepiej zrobić 500 migracji po dziesiątki tysięcy klientów niż 5 migracji po milionie każda. I to jest taki pattern, który moim zdaniem dał nam to bezpieczeństwo i pewność, że ta migracja rzeczywiście dojdzie do skutku, bo takiej migracji nikt na skalę światową nie prowadził przed nami.

Krzysztof:
Tak, to jest na pewno wielka rzecz. Chciałbym dopytać jeszcze o ten koszt utrzymywania dwóch systemów równocześnie. Utrzymywania to może jedno, ale rozwoju, no bo jeśli mamy na przykład jakiś moduł przepisany na nową technologię, na nowe rozwiązanie, a ten system cały żyje, można powiedzieć bankowy, nawet nie chodzi mi tutaj o konkretne rozwiązanie informatyczne, tylko bankowość się rozwija, Więc domyślam się, że istniała też taka potrzeba, żeby rozwijać albo dopisywać nowe funkcjonalności do tych dwóch systemów równocześnie. Czy to jest znaczący koszt, znaczący problem?

Michał:
Nie w naszym podejściu, dlatego że ja to powiedziałem wcześniej, ale może nie wybrzmiało wystarczająco. My podeszliśmy do tego projektu stosując kompilator kodu Cobolowego do .NETa. I my ten kod COBOL-owy nadal mamy. Założyliśmy.

Michał:
Że mamy jedną linię kodu, więc wszystkie zmiany związane z rozwojem biznesu implementowaliśmy w języku COBOL, w naszej aplikacji, w centralnym systemie bankowym. I ten kod był uruchamiany na środowisku mainframe’owym w starych procesach, jak i kompilowany kompilatorem od dostawcy RainCode, który nam pomógł zrobić ten projekt, do maszyny wirtualnej dotneta. Dzięki temu ten sam kod byliśmy w stanie utrzymywać na dwóch platformach. Oczywiście był koszt utrzymania dwóch platform stojących obok siebie, koszt procesu administracji, ale z drugiej strony stopniowo przenosimy klientów z platformy mainframe’owej na systemy otwarte, zdejmując po trochu koszty utrzymania i opłat licencyjnych, które musieliśmy płacić do IBM. Więc z punktu widzenia rozwoju założyliśmy, że trzymamy jedną linię kodu do migracji ostatniego klienta i teraz tak, jak zmigrowaliśmy już wszystkich klientów, możemy myśleć o tym, żeby pisać również w C-Sharpie, bo my jesteśmy bardzo dotnetowi C-Sharpowi i ten kod, ta architektura, którą stworzyliśmy jest taka, że ona rzeczywiście może się przenikać. Ale w etapie, bym powiedział, migracji założyliśmy, że otrzymamy jedną linię kodu i ten rozwój biznesu nie był zatrzymany.

Michał:
Wielkość linii kodowej urosła prawie dwukrotnie i to nie jest związane z samym re-platformingiem naszego systemu, tylko rozwojem banku dla naszych klientów, które prowadziliśmy.

Krzysztof:
Wspomniałeś tutaj o wsparciu firm zewnętrznych, partnerów zewnętrznych, która ta pomoc pewnie jest nieoceniona. Chciałbym Cię właśnie zapytać o tą metodologię pracy, którą przyjęliście, no bo MBank jest też sporym, można powiedzieć, takim pracodawcą IT w Polsce. Ten zespół jest tam naprawdę spory.

Wsparcie i współpraca z partnerami

Krzysztof:
Czy tego typu projekt da się zrealizować wewnętrznymi zasobami banku, czy też właśnie była konieczność posiłkowania się pomocą z zewnątrz?

Michał:
No, fajnie, że to zauważasz, bo mBank to naprawdę duży software house na rynku, znakomitych ekspertów, inżynierów. To jest grubo ponad tysiąc osób w IT, które pracuje wewnątrz i z punktu widzenia tego, jak ten projekt był realizowany, to rzeczywiście to był projekt wewnętrzny prowadzony siłami mBanku, ale nie w izolacji. Jeśli chodzi o tą naszą modernizację, to wiedzieliśmy, że mamy silny zespół wewnętrzny, który zna domenę, procesy i wszystkie zależności między systemami.

Michał:
Ale z drugiej strony wiedzieliśmy, że wchodzimy w nieznane, w taki obszar, który nie jest naszą domeną i żeby ten projekt się udał, to musieliśmy się wesprzeć partnerami zewnętrznymi. Więc pozwoliło to nam połączyć tę wiedzę domenową z kompetencjami specjalistycznymi, na przykład wspomniany przeze mnie wcześniej kompilator kodu Cobola do .neta, firma Raincode, taka belgijska, nieduża firma, która okazała się, bym widział, genialna w swojej zdolności, znajomości platformy kompilatorów. Oczywiście współpracowaliśmy z Microsoftem, bo to jest, bym powiedział, platforma, na którą się przenosimy, czy z innymi dostawcami, z którymi mamy długą historię. Chociażby nasz system bankowy jest na licencji Accenture. My mamy możliwość rozwoju tego systemu wewnątrz naszymi siłami, ale w momencie, gdy potrzebowaliśmy się wyskalować, to też nam pomogli i dodatkowe osoby wspomogły nas w tym projekcie.

Krzysztof:
Rozumiem. To jak teraz po tej migracji wygląda architektura całego rozwiązania? Mówiłeś wcześniej o tym aspekcie kosztowym jako takim driverze, który przyczynił się do podjęcia takiego projektu, ale myślę sobie, że też te możliwości techniczne, które teraz posiadacie z racji na nowe rozwiązania, nową architekturę, to jest również coś istotnego, co jest taką korzyścią dodatkową wynikającą z tej migracji, prawda?

Michał:
Moim zdaniem dzisiaj to jest zupełnie inny świat, czyli takiego systemu monolitycznego, zamkniętego wcześniej w ramach jednego mainframe’a przeszliśmy na w pełni rozproszoną architekturę działającą na serwerach x86. I największa różnica to sposób skalowania. Jak wspominałem w mainframe, wszystko skalowało się pionowo, czyli trzeba było dokładać moc procesora, pamięć, licencję i w większości przypadków to było skuteczne, ale kosztowne. Z drugiej strony nie zawsze wystarczające, bo kilka razy w historii spotkaliśmy się ze ścianą i dowiedzieliśmy się, że mimo iż dokładaliśmy większą moc sprzętową, aplikacja się nie wyrabiała, bo jednak to skalowanie pionowe nie zawsze działa. To, co mamy dzisiaj, to skalujemy się horyzontalnie.

Michał:
Możemy uruchamiać kolejne instancje serwisów w zależności od obciążenia i to daje ogromną elastyczność. Dokładamy kolejne maszyny aplikacyjne, jeśli jest taka potrzeba. Druga rzecz, którą zmieniliśmy, to sposób komunikacji między komponentami. To jest ta zmiana architektury. Wykorzystujemy asynchroniczne mechanizmy komunikacji i z mojej perspektywy to zwiększa odporność na warię pojedynczego serwisu lub usługi. Dzięki temu możemy coraz więcej zmian w naszym systemie wdrażać bezprzerwowo, a to nie jest nasze ostatnie słowo. Co więcej, wprowadziliśmy w samej aplikacji sharding bazy danych. To jest, w sumie nie wiem, czy to jest popularne stwierdzenie sharding danych. Często się o tym mówi, ale nie dyskutuje się, jak to jest skomplikowane, żeby rzeczywiście aplikację modelu eletyczną wyszardować. Ale my rzeczywiście wprowadziliśmy ten sharding danych i to pozwala nam równolegle przetwarzać segment klientów i lepiej wykorzystywać te zasoby infrastruktury.

Michał:
Dzięki logice shardingu mogliśmy połączyć właśnie dwa światy, o których mówiłem, czyli mainframe i systemów rozproszonych. Dzięki temu udało nam się przeprowadzić migrację stopniowo, bez Big Bang, bo mogliśmy po troszeczku klientów przenosić z jednej platformy na drugiej, a z punktu widzenia świata cały, Cały system wyglądał jak jeden system, bym powiedział, jak taki bąbel, tak jak wcześniej powiedziałem. No i nowy świat, to ja na to patrzę tak, że to nie jest też tylko technologia, to jest też nowe podejście do projektowania, inne myślenie o dalszym rozwoju, sposobie integracji, czy wreszcie otwarcie możliwości na przykład zasilania nowego hurtowni danymi systemu centralnego.

Krzysztof:
To, co powiedziałaś, myślę, bardzo dobrze obrazuje połączenie i wpływ IT i biznesu, bo tutaj jednoznacznie wynika, że te nowe możliwości, jakie teraz dzięki tej architekturze posiadacie, też dadzą pewnie dodatkowy boost, dodatkowy wpływ na to, że sam biznes pod tytułem usługi bankowe mogą się rozwijać szybciej. Szybciej można wprowadzać nowe rozwiązania, a to na koniec dnia często jest tą właśnie przewagą konkurencyjną, która decyduje o być albo nie być. Więc bardzo tutaj ładna nam powstała taka, można powiedzieć, połączenie. takie połączenie i wpływ jednego z drugim IT na biznes i biznes na IT.

Michał:
Wiesz, w tym projekcie byliśmy z biznesem wspólnie i razem do tego podchodziliśmy i moim zdaniem ten projekt rzeczywiście otwiera dużo więcej opcji niż mieliśmy wcześniej.

Krzysztof:
To porozmawiajmy może chwilę o jakości, o testowaniu, o zapewnieniu właśnie odpowiedniego quality, bo myślę sobie, że to zwłaszcza w tej domenie bankowej jest jednak kluczowe. No i widzę tutaj przynajmniej trzy takie obszary, w którym takie specjalne, można powiedzieć, zaangażowanie albo atencja jest potrzebna, jeśli mówimy o tej migracji. To jest migracja jako taka, prawda, tutaj ona jest pewnym procesem, czymś co się dzieje, też oczywiście wymaga to z pewnością przetestowania. Mamy dwa współistniejące systemy, co też nie jest zbyt standardowym i powszechnym

Jakość i testowanie systemu

Krzysztof:
tutaj modelem, to też wymaga pewnie odpowiedniego zapewnienia jakości. No i mamy to docelowe rozwiązanie, które samo w sobie jest powiedzmy nowym produktem i tutaj oczywiście znowu zapewnienie jakości jest niezbędne, więc właśnie jak to realizowaliście, może jakieś ciekawe praktyki, podejście, jeśli chodzi o testowanie, mógłbyś opowiedzieć, zdradzić?

Michał:
No ja nie wiem, czy my wynaleźliśmy coś wielkiego w tym projekcie, bo wydaje mi się i tak jak patrzę z perspektywem banku, to jakość jest numerem jeden, jasz niż naszego działania, bo wiemy jakie są konsekwencje, gdy rzeczywiście tej jakości się nie pilnujemy. Ale z punktu widzenia takiego projektu to ja patrzę na to, że to był jeden z najtrudniejszych aspektów całego projektu. Od początku projektu przejęliśmy zasadę, że testowanie to nie jest jakiś etap, ale to jest część codziennego procesu. Nie pracujemy w waterfallu, pracujemy przyrostowo, więc to musiało być częścią naszego projektu.

Michał:
Kodu, zmiana kodu, każda zmiana w logice biznesowej musiała być przez nas weryfikowana względem wyników uzyskanych z systemu uruchamianego na Mainframe. Dlaczego? No bo, tak jak powiedziałem, my zmieniliśmy platformę, używaliśmy kompilatora i on mógł w jakikolwiek inny sposób się zachowywać. Więc dla nas było bardzo ważne, żeby te systemy działały jeszcze przed migracją, przed pierwszą migracją klienta, równolegle, zarówno stary i nowy. I dorobiliśmy się narzędzi, które porównywały wyniki transakcji. Co to jest transakcja? Transakcja to jest, bym powiedział, taki serwis, który uderza do systemu centralnego, robi przelew, pytasz o saldo, no to to dociera przez wszystkie warstwy kanałów elektronicznych do systemu centralnego. No i zbudowaliśmy logikę, które porównywały wyniki działania tych transakcji na starej i nowej platformie. Mieliśmy szereg raportów i danych, Część z tych danych badaliśmy w czasie rzeczywistym, inne asynchronicznie porównując dane między środowiskami. To był ogromny wysiłek, myślę, że wspólny wysiłek, ale tylko dzięki temu mogliśmy mieć pewność, że nowa platforma zachowuje się identycznie jak dotychczasowa.

Michał:
I tam, gdzie się różni, robiliśmy to świadomie. No bo teraz bardzo ważne było to, że działamy tak samo dobrze i tak samo źle jak stara platforma. Znajdowaliśmy, W trakcie projektu też w kodzie, bym powiedział, produkty, usługi, które dawno nie funkcjonowały, więc przy okazji zrobiliśmy też porządki w kodzie, ale znowu, trzeba było to testować. No i automatyzacja. Bym powiedział, automatyzacja testów była i jest kluczowa.

Michał:
Drobiliśmy się setki tysięcy przypadków testowych, walidowanie danych i ciągły monitoring. Co więcej, to jest taka ciekawostka i przemyślenie z ostatnich moich kilku dni, że dorobiliśmy się ponad milion testów samego kompilatora napisanych po stronie mBanku, poza tym, co przygotował wcześniej dostawca. On nas zapewniał, że ten kompilator działa właściwie, a my jednak ponieśliśmy ten koszt i stworzyliśmy ponad milion testów. No i właśnie tutaj też się pojawiła innowacja, bo przecież niecały milion testów napisaliśmy manualnie. To było nasze autorskie rozwiązanie, które generowało takie testy łącznie z warunkami brzegowymi. I uruchamialiśmy te testy zarówno na starej platformie, jak i porównywaliśmy na nowej, żeby wiedzieć, tak jak powiedziałem, że te platformy działają tak samo dobrze i tak samo źle. Bo w trakcie tego projektu też znaliśmy dziwne zachowania kompilatora czy platformy mainframe’owej. Wydawałoby się, że logicznie to powinno inaczej działać, ale stwierdziliśmy, że musimy to odwzorować tak samo, żeby nie miało to wpływu na nasz projekt. I wracając do tych milionów testów, to pewnie jakbyśmy zaczynali projekt teraz, to jest taka moja refleksja, to skorzystalibyśmy ze wsparcia AI. W jaki sposób? Ale 10 lat temu nie mieliśmy takiej możliwości, więc to robiliśmy się takich, bym powiedział, autorskich smaczków, z których myślę, patrząc na historię.

Michał:
Duba mnie rozpiera, że takie, bym powiedział, pomysły pojawiały się w naszym zespole. No i do tego, co jeszcze w trakcie etapów projektu, który miał, różne etapy, różne podejście, no weryfikacja na środowiskach produkcyjnych z realnym ruchem, ale przy pełnej ochronie danych klientów, więc mówiąc krótko, sukces migracji to w dużej mierze sukces jakości testów i bez tego nie byłoby bezpiecznego przełączenia systemu, A my od początku powiedzieliśmy sobie zero przerw, prawie nam się to udało, zero strat, to się udało i zero niespodzianek. Do dnia dzisiejszego nie mieliśmy takiej niespodzianki, która by nas zaskoczyła, a przynajmniej istotnie wpłynęła w jakimkolwiek punkcie na klientów.

Krzysztof:
Ja tak z pewnością mogę pogratulować. Gdy o tym opowiadałeś, to pojawiła mi się taka myśl, że tak naprawdę może nie powinniśmy mówić tutaj o migracji, bo to jest właściwie migracja połączona z pewną refaktoryzacją, pewnym ulepszeniem.

Michał:
Modernizacją, tak?

Krzysztof:
Modernizacja to jest myślę bardzo dobre, lepsze słowo faktycznie, bo dużo więcej rzeczy się dzieje z tego co mówiłeś, nie tylko przepisujemy jeden do jeden, wy przepisujecie, natomiast robimy też tutaj pewne dodatkowe wzbogacenie tego naszego systemu, to jest pewnie taka wartość dodana.

Refaktoryzacja jako element migracji

Michał:
To by się nie dało naszego systemu skalować poziomo, czy jakby koegzystować w dwóch platformach. Także to nie czysta migracja, to jest modernizacja połączona z migracją. Świetnie to podsumowałeś.

Krzysztof:
A drugi aspekt, czy druga taka myśl, która mi się pojawiła, to właśnie ten tooling, te dodatkowe rozwiązania, te dodatkowe narzędzia, które może nie są bezpośrednio frontem do klienta banku, ale z drugiej strony są tymi narzędziami, które będą jeszcze pewnie długo wykorzystywane i używane i to jest kolejna wartość dodana, która w przypadku takiej modernizacji nam się pojawia, że budujemy w trakcie narzędzia, które właśnie będą nam służyć i będziemy dalej je wykorzystywać.

Michał:
I co wierze, te narzędzia nie wykorzystujemy i nie będziemy wykorzystywać tylko na produkcji z punktu widzenia obsługi naszych klientów, ale te narzędzia też bardzo nam pomagają budować kolejne środowiska testowe, integrować je między sobą, bo przecież mBank detaliczny to nie też system centralny, to jest dużo większy ekosystem i w moim portfelu, za który odpowiadam, to nie jest też tylko system centralny i trzeba myśleć o tym, jak ten świat ma funkcjonować w przyszłości.

Krzysztof:
Powiedziałeś na początku, że konieczna była decyzja o zrezygnowaniu z dobrze działającego, jakby nie było, systemu od IBM. Pytanie takie, czy to nie jest przypadkiem też rezygnacja z pewnego vendor lock-inu, czy to nie jest taka troszkę ucieczka przed swego rodzaju blokadą i związaniem się z jednym dostawcą. Z jednej strony może się wydawać, że tak, ale z drugiej strony straciliście też wsparcie potężnego dostawcy, więc jestem ciekawy, jak właśnie ważycie te dwie strony tej decyzji.

Zmiana architektury i vendor lock-in

Michał:
Mógłbym na to pytanie odpowiedzieć krótko tak, ale to jednak wymaga rozwinięcia. Więc tak, można to traktować jako pozbycie się vendorlocka, ale to nie była decyzja przeciwko IBMowi, tylko decyzja za niezależnością, tak jak zauważyłeś. I IBM przez lata dawał nam stabilność i niezawodność i tego nie sposób im odebrać. Ale świat się zmienił, banki potrzebują elastyczności, otwartych ekosystemów i możliwości szybkiego reagowania na potrzeby rynku. I przejście na rozwiązania oparte o x86 i .NET dało nam wolność. To trzeba wyraźnie powiedzieć, zarówno technologiczną, jak i kosztową. Dziś możemy sami decydować, jakie komponenty wykorzystujemy, jak je rozwijamy, gdzie je uruchamiamy, czy w chmurze, czy lokalnie, czy hybrodowo i to całkowicie zmienia paradygmat pracy IT. Więc z mojego punktu widzenia nie mamy już jednego dostawcy, od którego zależy nasza przyszłość. Mamy za to ekosystem, który możemy rozwijać w tempie, jaki sami sobie wyznaczymy. I to jest z mojej perspektywy prawdziwe pozbycie się vendor locking, bo nie robimy tego poprzez zmianę firmy, ale poprzez zmianę sposobu myślenia o architekturze.

Michał:
Tak jak powiedziałem, mamy elastyczność, możemy podłączać inne niezależne systemy monitoringu, łatwiej nam integrować się ze światem i to jest, bym powiedział, taka zmiana, którą osiągamy dzięki temu projektowi, dzięki tej modernizacji.

Krzysztof:
Taką, myślę, tutaj zgodzisz się ze mną, podstawą każdej refaktoryzacji jest to, żeby była ona w jakiś sposób transparentna, czyli przepisujemy to nasze rozwiązanie na jakąś nowszą technologię, na jakąś być może inną architekturę, ale tak naprawdę ona nie powinna nam wnosić jakiejś zmiany funkcjonalności, powinna być swego rodzaju transparentna. Zastanawiam się, jak to właśnie jest tutaj w przypadku, jak to już ustaliliśmy, modernizacji w mBanku, o której rozmawiamy. Czy ona oprócz tych niewątpliwych korzyści technologicznych, technicznych, o których powiedziałaś, daje też coś klientowi końcowemu, czy też może właśnie jest dla niego transparentna i powinna być transparentna?

Michał:
Moim zdaniem transparentna jest i powinna być transparentna z punktu widzenia tego, że klientowi nie damy gorszego poziomu usług. Tym głównym założeniem naszym na samym początku rzeczywiście była ta transparencja. Jak ja się nad tym bym teraz zastanowił, to do klientów ta zmiana jest prawie niewidoczna. I właśnie tak miało być. Czyli system, który działa dobrze i generalnie jak system działa dobrze, to nie powinien on zwracać na siebie uwagi. I z perspektywy użytkownika końcowego, zarówno klienta banku, jak i klienta wewnętrznego, tak się zadziało. Ale moim zdaniem efekty są głębsze. I jakbyś teraz się zapytał, jaki jest wpływ na klientów, to moim zdaniem ta nowa, jak mówisz o klientach, to ja zawsze myślę o kliencie wewnętrznym i zewnętrznym, zarówno o tym kliencie, który z nami bankuje, jak i kliencie wewnętrznym.

Michał:
Myślę o pracownikach banku, którzy korzystają z naszych systemów, też na bazie tych systemów budujemy nowe produkty, więc trzeba myśleć o tym szerzej. I moim zdaniem ta nowa architektura, tak jak mówiłem, otwiera nam drogę do dostarczenia szybciej zmian i to przekłada się na innowacje w produktach i usługach, które u nas się pojawią. Dla klienta technicznie nic się nie zmieniło, ale w praktyce zmieniło się wszystko. Bank stał się bardziej zwinny, a technologie wokół tego systemu przestają być ograniczeniem. Mamy nowe narzędzia monitoringu, dużo więcej i na bieżąco wiemy, jak coś nieprawidłowo działa w naszym systemie. Bo ja myślę, że są takie elementy, które klient powinien zauważać i na pewno nie wiąże tego klient z tą modernizacją, którą zrobiliśmy. Ponad 20 miesięcy temu uruchomiliśmy nowy system autoryzacji kartowych działających 24 na 7 365 dni w roku. Co to oznacza? Że nieważne, czy bank wyłączamy na przerwę, czy nie, możesz zapłacić kartą w terminalu. I to jest efekt tego projektu. My zdecydowaliśmy się w ramach tego projektu przepisać ten system w ramach tej modernizacji od nowa, od pierwszej linii kodu do C-sharpa. I on działa od 20 miesięcy ponad, bez wyłączenia.

Michał:
Drugi element, który powinien być zauważalny, ale to też małymi kroczkami będzie widać, zmniejszamy ilość przerw. To jest mowa o tym w naszej nowej strategii, ale właśnie dzisiaj, dokładnie dzisiaj nagrywamy podcast, udało się wdrożyć na produkcję zmiany taki mini-release, których nie udałoby się wcześniej wdrożyć bez zatrzymania banku, jak system centralny był uruchomiony w całości lub nawet części na mainframe. I czy to są zauważalne równice? No pozostawiam ocenić Tobie, słuchaczom, ale bym powiedział, dla mnie to istotna zmiana. Z jednej strony klient dostaje to samo, ale z drugiej strony będzie widać już zmiany, które po prostu będą procentowały i będziemy kapitalizować je w przyszłości.

Krzysztof:
Ująłbym to może w ten sposób, że podnosi się jakość i podnosi się user experience, a to jakby nie patrzeć w dzisiejszych czasach są takie dwie rzeczy, które bardzo często przyciągają użytkowników właśnie do danego rozwiązania. Myślę, że to jest istotny element konkurencyjny. Wspomniałeś tutaj, bo zacząłeś właśnie mówić też o wpływie na biznes, na to jak działa mBank na co dzień. Chciałbym jeszcze, żebyś może tutaj właśnie nieco więcej o tym wpływie na biznes, na współpracę, którą realizujecie, na tworzenie nowych produktów bankowych powiedział takie rzeczy, które właśnie wynikają z wdrożenia tego nowego projektu.

Michał:
Wiesz co, my z biznesem od lat pracujemy bardzo blisko. Pracowaliśmy, robiliśmy duże projekty, na przykład projekt nowego mBanku,

Wpływ modernizacji na biznes

Michał:
robiliśmy ramię w ramię kolejne projekty, które ten projekt zapoczątkował, robiliśmy razem. Ale moim zdaniem ten projekt modernizacji, replatformingu, jakkolwiek go nazwiemy, jeszcze bardziej zbliżył IT i biznes. Wcześniej potrafiliśmy mówić różnymi językami. Biznes mówi o produktach, IT o architekturze. I w tym projekcie, kiedy pracowaliśmy ramię w ramię, to był projekt technologiczny, mówimy o tym samym i jeszcze lepiej się rozumiemy. I to nie jest może nawet zasługa samego projektu, tylko wielu zmian, które w tym projekcie prowadziliśmy, tej wzajemnej edukacji, którą prowadzimy. Przez ten projekt re-platformingu, który w świecie, taki projekt re-platformingu dla mnie wcześniej był utożsamiany jako taki projekt typowo IT, utożsamiany z technicznym zajęciem, zdecydowaliśmy się przejść wspólnie z biznesem.

Michał:
Co daje nam ta nowa platforma? Ja już przed chwilą powiedziałem. Wdrożyliśmy komponent, którego nie byliśmy w stanie wdrożyć bez zatrzymania banku. Nowa platforma nam skraca cykle wdrożeniowe, otwiera drogę do automatyzacji, więc w efekcie produkty będzie można z biznesem wdrażać szybciej i szybciej reagować. To chyba takie, bym powiedział, wspólne spojrzenie i taka zmiana mentalna. Nie wiem, czy mógłbym powiedzieć, że z defensywnego myślenia nie da się, ale jednak, że jest trudno, że jest niemożliwe, na to partnerskie zróbmy to razem, bo skoro zrobiliśmy tak trudny, niemożliwy do zrobienia projekt modernizacji tak dużego systemu centralnego, jaki małem bank, no to czego się jeszcze nie da zrobić?

Krzysztof:
No tak, to na pewno dodaje pewności siebie. Oczywiście technologia to jest jedno, a z drugiej strony, i pewnie to jest nawet ważniejsze, to są ludzie, którzy tą technologię używają, wdrażają i wykorzystują. Mówiłeś tutaj o mBanku jako o dużym software house, jako o dużym pracodawcy IT. Czy takie wdrożenie tej nowej platformy i teraz już jej utrzymanie wymaga jakiegoś innego zakresu umiejętności niż te kompetencje, które już u siebie mieliście? Czy na przykład musieliście dotrudniać osoby o jakichś określonych rolach czy też kompetencjach technicznych?

Michał:
Tutaj mógłbym mówić bardzo długo, bo element ludzki był bardzo istotny w tym projekcie i to jest projekt nie tylko o zmianie technologicznej, ale również taki duży changement i podejście do tego. Tak zdecydowanie to było wyzwanie. Tak jak rozmawialiśmy, ta nowa platforma to zupełnie inny zestaw technologii, nowy zestaw narzędzi, sposobów pracy. W świecie mainframe’a, tak jak mówiłem, przez dekady.

Michał:
Już można powiedzieć, przez dekady z nimi byliśmy, dominowała stabilność, dość konserwatywne podejście, długie cykle wdrożeniowe i silna kontrola jakości. Jakość to u nas się cały czas przewija. W nowym środowisku potrzebowaliśmy większej zwinności, więcej automatyzacji.

Michał:
Devopsów, procesów CICD i zaplecza procesowego, który pozwala na ciągłe dostarczanie zmian. No ale właśnie, jakby podeszliśmy się do tego, że nie musimy budować wszystkiego zera, wręcz przeciwnie.

Michał:
Wielu naszych specjalistów z Mainframe ma niezwykle cenne doświadczenie, rozumieją co to znaczy niezawodność, jak utrzymać system o krytycznym znaczeniu, Jak zarządzać tranzakcyjnością i integralnością danych? Te kompetencje były, są i będą bezcenne niezależnie od technologii. Teraz bym podzielił to na dwa aspekty, dlatego że w moim obszarze jest zarówno development, jak i utrzymanie. Jeśli chodzi o development, to większość systemu centralnego nadal pozostała w Cobolu. Więc wiedza i kompetencje naszych deweloperów i architektów odnośnie sposobu działania systemów jest cały czas w użyciu. Oczywiście pojawiają się zmiany, jest inne środowisko pracy. Już nie trzeba kodować zmian w tzw. czarnym terminalu lub trzymać kodu w przesadzałym repozytorium kodu ISPW. Korzystamy z Visual Studio Code, mamy repozytorium kodu w Git, nowoczesne procesy wdrożeniowe z testami automatycznymi i podejmiemy też decyzje takie strategiczne o wynoszeniu części systemu centralnego Cobola. Tak się stało o tym systemie autoryzacji kartowych, o której mówiłem, który działa 24 na 7, 365 dni w roku i które napisaliśmy w C-Sharpie od nowa. I będziemy dalej podążać tą drogą w obszarze developmentu, ale w sposób przemyślany, zaplanowani tam, gdzie rzeczywiście widzimy z tego wartość.

Michał:
Jeśli chodzi, mówiłem o utrzymaniu aplikacji, o administratorów, to, w zakresie utrzymania aplikacji naprawdę zainwestowaliśmy wspólnie dużo czasu w przekwalifikowanie ludzi. To były szkolenia, warsztaty, wspólne wdrożenia z zespołami. Najlepiej jakby to ludzie z mojego obszaru powiedzieli, ale ja bardzo czuję się z tym fair, nie zostawiliśmy ich samych. Do zespołów, które utrzymywały system centralny na mainframe, dołączyli administratorzy, dla których platforma x86 czy MS SQL były natywnym środowiskiem pracy i pracowali razem przez miesiące i kwartały. Nie chodziło tylko o naukę nowego środowiska, ale też o zmianę sposobu myślenia z tego monolitycznego świata na rozproszony. I to była droga. Dzisiaj uważam, że to jest sukces, że zespoły, które łączą dośpienia z Mainframe, jeśli chodzi o te wymagania stabilności, integralności danych, patrzenia na to takim jednym obrazkiem znajomości naszego systemu z podejściem do architektury. I to jest chyba największy sukces. Nie wymieniliśmy ludzi w tym projekcie. Po prostu ich rozwinęliśmy, daliśmy szansę. To oni chcieli się rozwinąć, bo gdyby nie chcieli po to sięgnąć, no to nie byliby z nami w miejscu, w którym są, za co bardzo, bardzo jestem im wdzięczny.

Krzysztof:
No właśnie, chciałem zapytać o te osoby, które wcześniej pracowały z rozwiązaniami opartymi na mainframe. Po części już odpowiedziałeś, że te osoby równolegle do tej migracji, do tej modernizacji się rozwijały. Domyślam się, że tutaj duże wsparcie ze strony mBanku miało miejsce, jeśli chodzi o rozwój kompetencji. Taki reskilling czy też upskilling występował, prawda?

Michał:
No właśnie, wiesz co, mówiłem o tym już sporo, ale to jest dla mnie osobiście to był jeden z najważniejszych wątków tego projektu, ten aspekt ludzki. Ja sobie nie wyobrażałem, że możemy przeprowadzić tą transformację technologiczną, modernizację, replatforming, zostawiając ludzi z tyłu. Wiele, z tych ludzi pracowało przy systemie przez dekady. Zdecydowanie dłużej niż ja. Od pierwszego dnia mBanku znali każdy zakamarek, każdą tabelę, każdą zależność. I tutaj postanowiliśmy zaangażować włączyć ich zmiany. Oczywiście to nie jest proste, to wymagało czasu, ale to są naprawdę ludzie z nieocenionym źródłem wiedzy.

Michał:
Oni potrafią zrozumieć, dlaczego coś działa tak, a nie inaczej. I pomogli nam przełożyć to na nowy świat. Więc organizowaliśmy szkolenia, wspólne warsztaty, gdzie osoby z Mainframe’a i z .NETu siedziały obok siebie i tłumaczyły swoje światy. I to nie znaczy, że było łatwo. To nie znaczy, że bym powiedział, czasami nie obrzucają się pomidorami. Ale z tego brainstormingu powstaje taki niesamowity efekt. Moim zdaniem wzajemny szacunek i poczucie, że robimy to razem, a nie jedni po drugich. i patrząc na perspektywy czasu, ja myślę, że to dla niektórych była życiowa zmiana zawodowa. Taka przejście z tego z Cobola z możliwością przejścia na dotneta, z SPW na C i CD, ale w mojej perspektywy to trzeba dać tylko.

Michał:
Otworzyć drzwi, dać wsparcie i tak naprawdę jak jest mobilizacja i też skupienie i odpowiedzialność za ten system, który przez lata nasi eksperci, ekspertki, inżynierowie rozwijali, to naprawdę można zrobić ze sobą wszystko i to mnie naprawdę bardzo buduje.

Krzysztof:
Z pewnością właśnie natrafienie w swojej karierze na taki projekt, który daje takie możliwości, myślę sobie, że to też jest cenna rzecz, bo nie każdy ma na tyle takiej, można powiedzieć, wewnętrznej motywacji, żeby właśnie się na jakieś inne technologie przesiadać. W momencie, kiedy ten system, na którym działamy przechodzi tego typu rewolucje, to uczymy się można powiedzieć łącznie czy też w trakcie tej drogi i to jest wtedy pewnie znacznie prostsza sprawa. Była pałem też, że podkreśliłeś znaczenie tej wiedzy domenowej, która często u tych osób pracujących z wcześniejszymi systemami już bardzo mocno się tam skumulowała i to też jest bardzo cenna wartość dla firmy. Myślę, że można nawet założyć, że niekiedy ważniejsza niż te umiejętności techniczne. Zgodzisz się?

Michał:
Zdecydowanie, tak jak mówiłem i to podkreślam, to są inżynierowie, eksperci, ekspertki, więc istotna była z historią i doświadczeniem technicznym, więc ważniejsza jest wiedza o tym, jak system działa, jakie są zależności, Abym powiedział, że nowego środowiska pracy można się nauczyć. To jest bułka z masłem. Więc ta wiedza domenowa to jest fundament, na którym budowaliśmy i będziemy budować w przyszłości.

Krzysztof:
Pomimo, czy też może dzięki różnym sukcesom, różnym takim benefitom, które wynikają właśnie z tej transformacji, z tej modernizacji, no to projekt nie jest jeszcze zamknięty, prawda, ponieważ niektóre rzeczy można powiedzieć, że są w trakcie. Więc co jeszcze w waszych planach jest, co udało się osiągnąć, a co jeszcze jest planowane na przyszłość?

Michał:
No, bym powiedział, to był długi projekt i ja uważam, że udało się już naprawdę bardzo, bardzo dużo. Dzisiaj mamy już ze spokojem, mogę powiedzieć, w pełni działającą nową platformę centralną, zmigrowaną, na której funkcjonują już wszystkie procesy bankowości detalicznej. Kilka dni temu od produkcji odpięliśmy mainframe’a i już…

Plany na przyszłość i dalsza optymalizacja

Michał:
Żaden róg kliencki do niego nie jest kierowany. Więc to jest, bym powiedział, mega sukces i miejsce, w którym jesteśmy i moim zdaniem jest to świętować. Co więcej, to co wcześniej było monolitem jest dzisiaj rozproszone i elastyczne. Mamy nową architekturę, narzecją automatyzacji, monitoringu, pełną kontrolę nad przepływem dan. Ja myślę, że to co się udało osiągnąć i co jest ważne, że cały czas działaliśmy w trybie produkcyjnym. Nie było dnia, w którym bank przestałby działać. Migracja była niewidoczna dla klientów, co było naszym głównym celem. My zmigrowaliśmy ponad 80% aktywnych klientów, nie zabierając im dostępu do systemu. I to było, bym powiedział, to, co się udało osiągnąć. Jak się pytasz, co jeszcze jest w trakcie, to nie jest nasze ostatnie słowo. Wciąż trwa dalsza optymalizacja, refaktoryzacja niektórych procesów. Przygotowujemy się do całkowitego wyłączenia wtyczki zasilania z Mayframe’a, bo odpięliśmy go od produkcji. Logicznie system jest już odpięty od kilku dni, ale na pewno wyciągnięcie wtyczki zasilania odbędzie się w tym roku i na pewno będziemy to świętować, bo to będzie taki symboliczny moment zamknięcie pewnej epoki i rozpoczęcie nowej.

Krzysztof:
Jasne, no to czy już wam tego zazdroszczą? Czy to może być inspiracja dla innych instytucji, innych firm? No bo tak jak tutaj powiedziałeś na początku, tego typu projekty nie występują zbyt często, bo są wręcz bardzo rzadkie globalnie, więc tak, czy to może być inspiracja, czy to może być też obiekt jakiejś zazdrości ze strony innych?

Michał:
No wiesz, teraz można by obrosnąć w piórka i opowiadać długą historię, ale z tego co widzimy to tak. Ja już często słyszę pytania z innych instytucji, jak to zrobiliście, jak utrzymaliście ciągłość działania. Jak przekonaliście zarząd. I to pokazuje, że w sektorze finansowym dojrzewa świadomość, że modernizacja to nie opcja, tylko konieczność. Kilka tygodni temu miałem okazję być z moim szefem w Londynie, gdzie odbieraliśmy nagrodę Forrestera za realizację całej strategii IT za lata poprzednie.

Michał:
Jednym z filarów była tam modernizacja naszego systemu detalicznego, ale drugim z filarów była modernizacja systemu korporacyjnego. Ponieważ słucham twoich podcastów, to wiem, że jakiś czas temu był u ciebie Leszek Włodarski, opowiadał o tej modernizacji. A my w tym banku zrobiliśmy dwie modernizacje. No i wtedy w tym Londynie zaczepiali mnie ludzie i się pytali, jak to było, jak przeszliście wszyscy ten projekt, jak wam się udało zrobić ten projekt i skąd wzięliście na to tak dużo determinacji. Mówiłem o tym wsparciu zarządu, o tej kulturze firmy, myślę, że to nam pomogło. Ale wracając do twojego pytania, ja nie uważam, że my zrobiliśmy coś magicznego. Zrobiliśmy coś, co wymagało odwagi, konsekwencji i cierpliwości. I pokazaliśmy, że można przepisać system obsługujący miliony klientów, nie zatrzymując banku ani na chwilę. Że można połączyć stare z nowym, wiedzę z doświadczeniem, stabilność i nowoczesnością. Jeśli to może być inspiracja dla innych, to świetnie, bo ta modernizacja to nie jest tylko historią technologii. Tak jak powiedziałem, to historia o ludziach, którzy mieli odwagę coś zmienić, mieli wsparcie, zmienić, ruszyć coś, co działało, żeby działało jeszcze lepiej przez kolejne 20 lat.

Krzysztof:
Michał, ja oczywiście bardzo jeszcze raz tutaj gratuluję, bo niewątpliwy sukces tego typu modernizacji z pewnością będzie inspiracją dla różnych instytucji. Myślę, że śmiało mogę zaryzykować powiedzenie, że globalnie nie tylko w naszym kraju. I to jest na pewno duża rzecz i duże też pokazanie, jak IT może mieć przełożenie na biznes i jak bardzo te dwa światy są ze sobą połączone. Także bardzo Ci serdecznie gratuluję i dziękuję za naszą dzisiejszą rozmowę.

Podsumowanie sukcesu i inspiracje dla innych

Michał:
Dzięki Krzysztof za zabranie mnie w tą podróż. To wyjątkowa podróż i dla mnie, i dla mojego zespołu. Mam nadzieję, że ta rozmowa pokaże, że nawet w tak dużych organizacjach złożonych jak my, Może można robić coś mądrze z planem i z ludźmi w centrum. Także bardzo dziękuję Tobie, słuchaczom, za obecność na tym podcaście.

Krzysztof:
Dzięki jeszcze raz i powiedz proszę na koniec, gdzie Cię możemy znaleźć w internecie?

Michał:
Możecie znaleźć mnie na moim profilu LinkedIn. Łatwo go znaleźć, Michał Niedźwiecki, mbank.pl. Zapraszam. Jeśli ktoś jest zainteresowany, to proszę o kontakt.

Krzysztof:
Do ułatwienia oczywiście link będzie w notatce do odcinka. Michał, jeszcze raz bardzo dziękuję i do usłyszenia. Cześć.

Michał:
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 lub mailowo na krzysztof@porozmawiajmyoit.pl Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy.it o tym, jak przepisać system bankowy obsługujący 10 milionów klientów, czyli od Cobola i Mainframe do .NET i rozproszonej architektury. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!