Porozmawiajmy o IT
Porozmawiajmy o IT
Jak przepisać system bankowy obsługujący 10 milionów klientów, czyli od Cobola i Mainframe do .NET i rozproszonej architektury. Gość: Michał Niedźwiecki - POIT 301
Witam w trzysta pierwszym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak przepisać system bankowy obsługujący 10 milionów klientów, czyli od Cobola i Mainframe do .NET i rozproszonej architektury.
Dziś moimi gościem jest Michał Niedźwiecki – Dyrektor Departamentu Rozwoju i Utrzymania Aplikacji w mBank S.A., 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.
Sponsor odcinka
Sponsorem odcinka jest mBank S. A.
W tym odcinku o migracji bankowych systemów IT rozmawiamy w następujących kontekstach:
- migracja bankowych systemów informatycznych to strategiczna decyzja
- jak wyglądają kolejne etapy planowania i wdrażania
- jak wygląda docelowa architektura
- jak testuje się tego typu rozwiązania
- vendor lock-in versus wsparcie dużego dostawcy
- wpływ na biznes, współpracę, tworzenie nowych produktów bankowych
- zakres umiejętności niezbędny w takiej migracji
- wpływ na klientów
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 Michała na LinkedIn – https://www.linkedin.com/in/michal-niedzwiecki-/
Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
https://porozmawiajmyoit.pl/301
To jest 301 odcinek podcastu Prostmawiają IT. Dziś rozmawiamy o tym, jak przepisać system bankowy obsługujący 10 milionów klientów. Sponsorem odcinka jest MBank Esa. Dotatkę linki i transkrypcję. I wszystko to, co porządny słuchacz powinien mieć pod ręką, znajdziesz na rozmawiajmyit.pl łamany na 301. Nazywam się Krzysztof Kiempiński. Stworzą ten podcast, napisałem też książkę Marka Otopista Branche IT i lubią jak ludzie z naszej branży rozwijają się z głową, a nie na ośle. Możesz mi w tym pomóc. Wystarczy, że ocenisz podcast w Twojej aplikacji albo puścisz ten odcinek dalej. Tylko tyle. To przecież mówią, że karma wraca. No dobra, a teraz odpalamy. Cześć, mój dzisiejszy gość to dyrektor Departamentu Rozwoju i Utrzymania Aplikacji w M Bank 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łom godziny w podcaście.
SPEAKER_01:Cześć Krzysztof, bardzo cieszę się, że jestem Twoim gościem. Witam wszystkich słuchaczy. Mam nadzieję, że ta nasza rozmowa będzie dla Was interesująca.
SPEAKER_00: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 Kobola i mainframe na nowoczesne oparte o dotnet i architekturę rozpoczoną. Już teraz możemy, myślę, 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ć.
SPEAKER_01: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ę City of Morning Coffee, bo tam nie ma tanich sensacji, tylko rozmowy z ludźmi, którzy naprawdę prowadzą złożone organizacje technologiczne. Nie tylko to jest dyskusja o nowinka 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 przejść to jest kluczowe. My często podejmę decyzje, których skutki będą widoczne dopiero za 5 czy 10 lat, 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 pokazuje prawdziwe historie z różnych projektów, a ja lubię prawdziwe historie, nie tylko prezentację sukcesów, ale rozmowę o tym, jak naprawdę wygląda budowanie czegoś naprawdę dużego.
SPEAKER_00:Super, dziękuję Ci za to rekomendację zmi. Niezmiernie miło, że porozmawiajmy IT też się na Twojej liście znajduje.
SPEAKER_01:Jak mogłoby być inaczej? To jest tak fajny podcast.
SPEAKER_00:Dzięki śliczny 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.
SPEAKER_01:Wiesz co, ja wem banku 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, który zmieniamy fundamenty technologiczne banku. I to jest replatforming naszego systemu centralnego bankowości detalicznej. W wanku 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. Serce tego systemu, tak jak powiedziałeś, jest napisane w Kobolu, działające zarówno u nas, jak i na świecie na mainframach. Źródło tego systemu sięga dużo dalej niż w tym banku i naprawdę wiele generacji tych maszyn mainfraimowych przemknęło się przez nasze serwerowe. 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.netowe, 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 krzyw właściwie 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ć. 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 silnika w całącym samolocie. Nie można 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.
SPEAKER_00: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, tak jak tutaj wspomniałeś, 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.
SPEAKER_01: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 kurfową koncept, zbadaliśmy rynek. Ale wiesz, profokoncept, a wejście głęboko w projekt to jest 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, stabilnie 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. I samo prowadzenie tego projektu, utrzymanie priorytetu wymagało nie tylko decyzji strategicznej na samym początku, ale też cierpliwości na każdym poziomie, jakby 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 powiedzieć na początku, mamy się z czego cieszyć, dowieźliśmy.
SPEAKER_00: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.
SPEAKER_01:Nie wiem, jak głęboko mam wchodzić w środki, ale powiem tak, od początku wiedzieliśmy, że nie możemy pozwolić sobie na tak zwany Big Bank, jednorazowe przełączenie całego systemu dla wszystkich klient. To byłby zbyt duży poziom ryzyka i nie oszukujmy się z istotnym wpływem na cały sektor bankowy. Jeśli Mank 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ł, bym powiedział, założenie, że zachowujemy jedną linię kodu. Dlatego też wybraliśmy ścieżkę z kompilatorem kobolola do.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. 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 systemie, 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 imigracji. No bo etapy i niespodzianek było dużo. Czasami się zatrzymywaliśmy, czasami musieliśmy coś przeprojektować, zrobić krok do tyłu. Zatrzymać. Czasami te zatrzymania były dłuższe niż tydzień miesiąc. Musieliśmy zrobić jakiś refaktor, ale cały czas szliśmy do przodu. Z punktu widzenia świata szliśmy przezroczyście.
SPEAKER_00:Tak, testowanie i zapewnienie jakości na pewno będę chciał dzisiaj zapytać, no 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, jak gdyby uruchamianiem kolejnych modułów, przepisywaniem migracją kolejnych modułów, wyłączaliście stare, czy one nadal działają równolegle?
SPEAKER_01: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, mainframeowej, 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 czas i miejsce.
SPEAKER_00:No tak, 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ą oparczone 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 sprawdzanego poju rozwiązania, prawda?
SPEAKER_01:Dokładnie, znaczy przede wszystkim założenie na wejściu, że nie robisz Big Bangu, pozwala ci po prostu iść literacyjnymi 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ż pięć migracji po milionie każdy. 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.
SPEAKER_00:No 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ć bankowe, nawet nie chodzi mi tutaj o konkretne rozwiązania 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?
SPEAKER_01:Nie w naszym podejściu. Dlatego, że ja to powiedziałem wcześniej, ale może nie wyraźniało wystarczająco, my podeszliśmy do tego projektu stosując kompilator kodu kobolowego do.netu. I my ten kod kobolowy nadal mamy. Założyliśmy, że mamy jedną linię kodu, więc wszystkie zmiany związane z rozwojem biznesu implementowaliśmy w języku kobol w naszej aplikacji w centralnym systemie bankowym i ten kod był uruchamiany na środowisku mainfraimowym w starych procesach, jak i kompilowany kompilatorem od dostawcy rynkot, który nam pomógł zrobić ten projekt do maszyny wirtualnej.net. 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 mainfraymowej na systemy otwarte, zdejmując po trochu koszty utrzymania i opłat licencyjnych, które musieliśmy płacić do IBMa. 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 dotentowi S-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 trzymamy jedną linię kodu i ten rozwój biznesu nie był zatrzymany, wielkość linii kodowej urosła prawie dwukrotnie i to nie jest związane z samym replatformingiem naszego systemu, tylko rozwojem banku dla naszych klientów, które prowadziliśmy.
SPEAKER_00:Wspomniałeś tutaj o wsparciu firm zawręcznych paternów zewnętrznych, która ta pomoc pewnie jest nieoceniona? Chciałem cię właśnie zapytać o tą metodologię pracy, którą przyjęliście. No bo mank jest też sporym, można powiedzieć, takim pracodawcą IT w Polsce, prawda? Ten zespół jest tam naprawdę spory. 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?
SPEAKER_01:No, fajnie, że to zauważasz, bo Mank to naprawdę duży software house na rynku znakomitych ekspertów i inżynierów, to jest grubo ponad 1000 osób WT, 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 M banku, 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, 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 Kobola do.neta firma Rękot, taka belgijska, nieduża firma, która okazała się, bym powiedział, 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, dostawcami, którymi mamy długą historię, chociażby nasz system bankowy jest na licencjach Sench, 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 dodatkowo sobie wspomogły nas w tym projekcie.
SPEAKER_00: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 w ogóle 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?
SPEAKER_01:Moim zdaniem dzisiaj to jest zupełnie inny świat, czyli takiego systemu, takiego monolitycznego, zamkniętego wcześniej w ramach jednego Majema 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, Majme wszystko skalowało się pionowo, czyli trzeba było dokładać moc procesora, pamięć, licencje, 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. I to, co mamy dzisiaj, to skalujemy się horyzontalnie. Czyli możemy uruchamiać kolejne instancje serwisów w zależności od obciążenia i to daje nam 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 awarię 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ę modelityczną wyszardować. Ale my rzeczywiście wprowadziliśmy ten sharding danych i to pozwala nam równolegle przetwarzać segmenty klientów i lepiej wykorzystywać te zasoby infrastruktury. Dzięki logice shardingu mogliśmy połączyć właśnie dwa światy, o których mówiłem, czyli mainfraima i systemów rozproszonych. Dzięki temu udało nam się przeprowadzić migrację stopniowo bez Big Bank, bo mogliśmy po troszeczku klientów przenosić z jednej platformy na drugiej, a z punktu widzenia świata 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 onaj nowego hurtowni danami systemu centralnego. Wcześniej robiliśmy to w jakichś interwałach z pewnym opóźnieniem, a teraz jesteśmy w stanie po prostu online nowo zasilać, czy hurtownie, czy inne systemy, i bez tej modernizacji po prostu nie byłoby to możliwe.
SPEAKER_00:To, co powiedziałeś, myślę, bardzo dobrze obrazuje połączenie i wpływ IT biznesu, no bo tutaj jednoznacznie wynika, że te nowe możliwości, jakie teraz dzięki tej architekturze posiadacie, też dadzą pewnie dodatkowy bust, dodatkowy wpływ na to, że sam biznes pod wtuchem usługi bankowe mogłoby 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 powiedzieć, połączenie, takie połączenie i wpływ jednego z drugim IT na biznes i biznes na IT.
SPEAKER_01: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.
SPEAKER_00:To porozmawiamy może chwilę o jakości, o testowaniu, 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 imigracji. 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ółistniające systemy, co też nie jest zbyt standardowym i powszechnym modelem, to też wymaga pewnie odpowiednie jego 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 i podejście, jeśli chodzi o testowanie, mógłbyś opowiedzieć i zdradzić.
SPEAKER_01: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 najważniejszych aspekt naszego działania, bo wiemy, jakie są konsekwencje, gdy rzeczywiście w tej jakości nie pilnujemy. Ale z punktu widzenia takiego projektu, to ja patrzę na to, że to był jeden z najtrudniejszych aspektów cał projektu. Od początku projektu przyjęliśmy zasadę, że testowanie to nie jest jakiś etap, ale to jest część codziennego procesu. Nie pracujemy w waterfalu, pracujemy przyrostowo, więc to musiało być częścią naszego projektu. Więc każdy kawałek kodu, zmiana kodu, każda zmiana w logice biznesowej musiała być przez nas weryfikowana względem wyników uzyskanych systemu uruchamianego na mainfryte. 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ównoległy, 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, 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ęść w nich 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 dotychczasowych. 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. Drobiliśmy się setki tysięcy przypadków testowych, walidowanie danych i ciągły monitoring. Co więcej, to jest taka bym powiedział, ciekawostka i przemyślenie z ostatnich moich kilku dni, że dorobiliśmy się ponad milion testów samego kompilatora napisanych po stronie banku 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. I 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, znaliśmy dziwne zachowania kompilatora czy platformy mainframe. Wydawałoby się, że logicznie to powinno inaczej działać, ale stwierdziliśmy, że musimy to odwzorować tak samo, żeby nie miało wpływu to na naszy 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ę duma 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, tak jak pisałeś, 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.
SPEAKER_00:Ale 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. Modernizacji, tak? 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 1 do jeden, znaczy wy przepisujecie, prawda? Natomiast robimy też tutaj pewne dodatkowe ubogacenie, wzbogacenie tego naszego systemu. To jest pewnie taka wartość.
SPEAKER_01: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ś.
SPEAKER_00:A drugi aspekt, czy druga taka myśl, która by się pojawiła, to właśnie ten tooling, te dodatkowe rozwiązania, 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 mieć.
SPEAKER_01:Co więcej, te narzędzenie wykorzystujemy i nie będziemy wykorzystywać tylko na produkcji z punktu widzenia obsługi naszych klientów, ale te narzędzą nam pomagają budować kolejne środowiska testowe, integrować je między sobą, bo przecież ten bank detaliczny to nie też system centralny to jest dużo większa, bym powiedział, dużo większa ekosystem i w moim portfelu za które odpowiadam, to nie jest też tylko system centralny, trzeba myśleć o tym, jak ten świat ma funkcjonować w przyszłości.
SPEAKER_00: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 z przypadkiem też rezygnacja z pewnego wędro, czy to nie jest taka troszkę ucieczka przed swego rodzaju blokadą i związaniem się z jednym dostawcą. Z jednej strony możecie 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 tutaj dwie strony tej decyzji.
SPEAKER_01:Mógłbym na to pytanie odpowiedzieć krótko tak. Ale to jest jednak wymaga rozwinięcia. Więc tak, można to traktować jako pozbycie się wędroka, ale to nie była decyzja przeciwko IBM'a, IBM-owi, tylko decyzja za niezależnością, tak jak zauważyłeś. I IBM przez lata dawał nam stabilność i niezawodność, i tego nie jest 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 o X86 i dotnet 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 dostawca, 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ę wędroki, bo nie poprzez nie robimy tego poprzez zmianę firmy, ale poprzez zmianę sposobu myślenia o architekturze. Tak jak powiedziałem, mamy elastyczność, możemy podłączać inne, niezależne systemy monitoringu. Łatwiej nam integrować ze światem, i to jest, bym powiedział, taka zmiana, którą osiągamy dzięki ten projekt. Dzięki temu projektowi, dzięki tej modernizacji.
SPEAKER_00:Taką myślę, że to jest zgodzić się z jedną 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ś zmian we funkcjonalnie, powinna być swego rodzaju transparentna. Zastanawiam się, jak to właśnie jest tutaj w przypadku jak to już ustaliliśmy, modernizacji wębanku, 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 na niego transparentna i powinna być transparenta.
SPEAKER_01: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. I jak ja się nad tym bym teraz zastanowił, to dla klientów ta zmiana jest prawie niewidoczna. I właśnie tak miało być. Czyli system, który działał dobrze, i który system. I generalnie jak system działa dobrze, to nie powinien on zwracać na siebie uwagi. 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 tym kliencie, który z nami bankuje, jak i kliencie wewnętrzne, pracownika 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 ja 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ą. Więc 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, 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? ⁇ Nieważne, czy bank wyłączamy na przerwę, czy nie, możesz zapłacić kartą do 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 liniki kodu to się szarpa. I on działa 20 miesięcy ponad bez wyłączenia. Drugi element, który powinien być zauważalny, ale to też małymi kruczkami 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 rewiz, 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 mainfraie. I czy to są zauważalne różnice? Poostawiam ocenić tobie, słuchaczom, ale bym powiedział, dla mnie to istotna zmiana. Z jednej strony klient dostaje to sam, 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.
SPEAKER_00: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 powodują czy 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 M Bank 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óre realizujecie, na tworzenie nowych produktów bankowych powiedział takie rzeczy, które właśnie wynikają z wdrożenia tego nowego projektu.
SPEAKER_01:Wiesz, co, my z biznesem od lat pracujemy bardzo blisko. Pracowaliśmy, robiliśmy duże projekty, na przykład projekt Nowego Mbanku robiliśmy ramię w ramię, kolejne projekty, który ten projekt zapoczątkował robiliśmy razem. Ale moim zdaniem ten projekt modernizacji, replatformingu, jakkolwiek go nazwiemy, jeszcze bardziej zbliżył IT 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, 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 replatformingu, który w świecie. Taki projekt replatformingu dla mnie wcześniej był tożsami jako taki projekt typowo ITU, tożsami z technicznym zajęciem, zdecydaliśmy się przejść wspólnie z biznesem. I co daje nam ta nowa platforma? Ja już przed chwilą powiedziałem, wdrożyliśmy wdrożliwy 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 Mank, no to czego się jeszcze nie da zrobić?
SPEAKER_00: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ą? I mówiłeś tutaj o MBanku jako o dużym sołterhouse 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 kompetencji, które już u siebie mieliście? Czy na przykład musieliście dotrudniać osoby o jakiś określonych rolach, czy też kompetencjach technicznych?
SPEAKER_01:Oj, tutaj mógłbym mówić bardzo długo, bo bym powiedział, element ludzki był bardzo istotny w tym projekcie, i to jest projekt nie tylko o zmianie technologicznej, ale również taki duży część i podejście do tego. Więc jakby 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 tak jak mówiłem, przez dekady 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. Ta jakość to u nas się cały czas przewija. W nowym środowisku potrzebowaliśmy większej zwinności, więcej automatyzacji developsów, procesów CICD i z zaplecza procesowego, który pozwala na ciągłe dostarczanie zmian. No ale właśnie, jakby podróżimy się do tego, że nie musimy budować wszystkiego zera, wręcz przeciwnie, wielu naszych specjalistów z Mayframe ma niezwykle cenne doświadczenie rozumieją, co to znaczy niezawodność, jak utrzymać system o krytycznym znaczeniu, jak zarządzać transakcjonnością i integralnością danych. I te kompetencje były, są i będą bezcenne, niezależnie od technologii. I 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 Kobolu. 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 tak zwanym czarnym terminalu lub trzymać kodu w przestrazałym repozytori kodu ISPW. Korzystamy z Visual Studio Code, mamy repozytorium kodu w GICI, nowoczesne procesy wdrożeniowe z testami automatycznymi i podejmujemy też decyzje takie strategiczne o wynoszeniu części systemu centralnego Skobola. Tak się stało o tym systemie autoryzacji kartowych, o której mówiłem, które działa 24 na 7365 dni w roku i które napisaliśmy w szarpie od Nowa. I będziemy dalej podążać tą drogą w obszarze dewelopentu, ale w sposób przemyślany, zaplanowany i tam, gdzie rzeczywiście widzimy z tego wartość. 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. I 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 MSSQL 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 rozproszone. I to była droga. Dzisiaj uważam, że teraz sukces zespoły, które łączą do śniadania z Mayframe, 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 co sięgnąć, no to nie byliby z nami w miejscu, w którym są, za co bardzo, bardzo jestem im wdzięczny.
SPEAKER_00:No właśnie, chciałem zapytać o te osoby, które wcześniej pracowały z rozwiązaniami opartymi na mainframe, bo częściej 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?
SPEAKER_01:No właśnie wiesz, co mną mówiłem o tym już sporo, ale to jest, dla mnie osobiście to był jeden z najważniejszych wunków tego projektu, ten aspekt ludzki. Ja sobie nie wyobrażałem, że możemy przeprowadzić tę transformację technologiczną, modernizację, replatforming, zostawiac ludzi z tyłu. Wiele z tych ludzi pracowało przy systemie przez dekady zdecydowej niż ja. Od pierwszego dnia banku znali każdy za kamarek, 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. I oni potrafili zrozumieć, dlaczego i potrafią zrozumieć, dlaczego coś działa tak, a nie inaczej i pomogli nam przełożyć to na nowy świat. Więcowaliśmy szkolenia, wspólne warsztaty, gdzie osoby z Mayframe i z DNT siedziały obok siebie i tłumaczyły swoje świat. 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 drugi. I patrząc na perspektywy czasu, ja myślę, że to dla niektórych była życiowa zmiana zawodowa. Taka przejście z Kobola z możliwością przejścia na dotnet jest pewna C i CD, ale z mojej perspektywy, to trzeba dać tylko szansę 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.
SPEAKER_00: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 motywacje, żeby właśnie się na jakieś inne technologie przesiadać. No w momencie, kiedy ten system, na którym działamy, przechodzi tego typu rewolucje, to uczymy się, można powiedzieć łącznie też w trakcie tej drogi, to jest wtedy pewnie znacznie prostsza sprawa. Byłapałem też, że podkreśliłeś znaczenie tej wiedzy domenowej, która często u tych osób pracujących z wcześniejszymi systemami 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ę?
SPEAKER_01:Zdecydowanie, tak jak mówiłem, to podkreślam, to jest, bym powiedział, to są inżynierowie, eksperci, ekspertki. Wicotna była z historią i doświadczeniem technicznym, więc ważniejsza jest wiedza, ja o tym, jak system działa, jakie są zależności, aby poziom nowego środowiska pracy można się nauczyć. To jest bułka z masłem. Więc jakby ta wiedza domenowa to jest fundament, na którym budowaliśmy i będziemy budować w przyszłości?
SPEAKER_00: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ó 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ść?
SPEAKER_01: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 odpieliśmy Mainframa i już żaden ruch kliencki do niego nie jest kierowane. 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ę, narzędzie automatyzacji, monitoringu, pełną kontrolę nad przepływem danych. 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, no nie to nie jest nasze ostatnie słowo. Wciąż trwa dalsza optymalizacja, refaktoryzacja niektórych procesów. Przygotowujemy się do całkowitego wyłączenia wtyczki z zasilania z Mayfraima, bo odpięliśmy go od produkcji. Logicznie system jest już odpięty od kilku dni, ale na pewno wyciągnięcie wtyczki z 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 poki i rozpoczenie nowej.
SPEAKER_00:Jasne, 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.
SPEAKER_01: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ść. I kilka tygodni temu miałem okazję być z moim szefem w Londynie, gdzie odbieraliśmy nagrodę Forestera za realizację całej strategii IT za lata poprzednie. No i jednym z filarów była tam modernizacja naszego systemu metalicznego, 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 bodarski opowiadał o tej modernizacji. A my w banku zrobiliśmy dwie modernizacje. No i wtedy w tym Londynie zaczepiali mnie ludzie i się pytali, jak to było? Jak przeszliście przez 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, tą wiedzę z doświadczeniem, stabilności i nowoczesnością. I jeśli to może być inspiracja dla innych, to świetnie. Bo ta modernizacja to nie jest tylko historia technologii. Tak jak powiedziałem, to historia 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.
SPEAKER_00:Ja oczywiście bardzo jeszcze raz tutaj gratuluję, bo niewątpliwie sukces z 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. 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ę.
SPEAKER_01:Dzięki, Krzysztof, za zabranie mnie w tróż. To wyjątkowa podróż i dla mnie, i dla mojego zespołu, i mam nadzieję, że ta rozmowa pokaże, że nawet w tak dużych organizacjach złożonych jak my 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.
SPEAKER_00:Dzięki jeszcze raz i powiedz proszę na koniec, gdzie cię możemy znaleźć w internecie.
SPEAKER_01:Możecie znaleźć mnie na moim profilu LinkedIn. Łatwo go znaleźć Michał Niedźki.mbank.pl Zapraszam. Jeśli ktoś jest zainteresowany, to proszę o kontakt.
SPEAKER_00:Do ułatwienia oczywiście link będzie w notatce do odcinka. Michał jeszcze raz bardzo dziękuję i do usłyszenia. Dzięki, 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 lub mailowo na kształto mapa porozmawiajmyit.pl. Nazywam się Krzysztof Kępiński, a to był odcinek podcastu porozmawiajmy o tym, jak przepisać system bankowy obsługujący 10 milionów klientów, czyli od kopola i mainframe do dotnet i rozproszczonej architektury. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć.
