Migracja do chmury aplikacji z regulowanego sektora finansowego - wyzwania i praktyczne rozwiązania

Wywiad z Adamem Maślejem, Product Owner'em w FINGO Systems

Migracja systemu do chmury wiąże się z szeregiem wyzwań, szczególnie jeśli odbiorcą aplikacji są podmioty działające na silnie regulowanym rynku finansowym. Równocześnie jest to doskonała okazja do analizy i dokonania zmian technologicznych oraz funkcjonalnych w systemie, które zaowocują usprawnieniem pracy użytkowników końcowych.

Adam Maślej, Product Owner w FINGO jest odpowiedzialny za przebieg prac związanych z budową i rozwojem systemu eON, czyli chmurowego następcy aSISt używanego przez ponad 500 instytucji finansowych.
W tym artykule opowiada:

• Dlaczego FINGO Systems zdecydowało się przenieść aplikację desktopową do infrastruktury chmurowej?
• Przed jakimi wyzwaniami staną zespół projektowy tworzący nowy system do sprawozdawczości obligatoryjnej w chmurze?
• W jaki sposób zapewniono bezpieczeństwo nowej aplikacji działającej na zewnętrznej infrastrukturze chmurowej?
• Jakie są dalsze plany związane z rozwojem systemu eON SaaS.

Czy możesz nam krótko opowiedzieć, jak powstał desktopowy system do raportowania obligatoryjnego aSISt?

W przeszłości powszechną praktyką było wysyłanie do instytucji nadzorujących rynek finansowy (w Polsce - NBP oraz KNF, w Europie - EBA) raportów w formacie tekstowym lub xls. Z punktu widzenia nadzorcy nie jest to najlepszy format ze względu na ograniczoną siłę wyrazu definicji zbieranych danych oraz ograniczone możliwości weryfikacji spójności, integralności i poprawności danych.

Pojawienie się nowych możliwości technologicznych, przyczyniło się do powstania i ugruntowania pozycji standardu XBRL. W związku z tym nadzorcy zaczęli tworzyć zgodnie z nim taksonomie XBRL, które definiują zakres i format zbieranych danych. A także oczekiwać od instytucji raportujących dostarczania danych zgodnie z tym standardem i formatem wymiany danych. Dało to możliwości standaryzowania zbiorów danych, zasad ich zbierania, weryfikowania i gromadzenia.

W tamtym czasie na rynku nie było za bardzo systemów obsługujących taki format. Dlatego w odpowiedzi na te zmiany i realną potrzebę instytucji finansowych powstał aSISt - aplikacja obsługująca taksonomie XBRL. Narzędzie wspierało  przygotowanie raportu w poprawnym, oczekiwanym przez nadzorcę zakresie oraz usprawniało proces przetwarzania danych zgodnie z regułami weryfikującymi poprawność danych.

System sprzedawany jest jako aplikacja desktopowa, działająca na wewnętrznej infrastrukturze informatycznej instytucji finansowej. Do dziś wykorzystywany jest przez ponad 500 banków w Polsce oraz w krajach Unii Europejskiej.

Dlaczego zdecydowaliście się na przeniesienie systemu aSISt na infrastrukturę chmurową?

Technologia aplikacji typu desktop jest już pewnego rodzaju przeżytkiem. Trudno jest ją utrzymywać w zgodności ze zmieniającym się światem IT. Należy pamiętać, że aplikacja była projektowana na ówczesne potrzeby zarówno w zakresie liczby sprawozdań, jak i ich obszerności. Dziś nadzorcy zbierają znacznie więcej danych, niż robili to wiele lat temu, więc aplikacja powoli nie nadąża już za dzisiejszymi potrzebami klientów.

Ponadto docierały do nas głosy klientów związane z rosnącymi wyzwaniami związanymi z wydajnością i utrzymaniem systemu.  

Coraz popularniejsze na rynku IT są rozwiązania chmurowe. Dają one znacznie większe możliwości w zakresie dostępności usług, skalowalności zasobów informatycznych i optymalnego kosztowo ich wykorzystania. Dlatego zdecydowaliśmy o zbudowaniu aplikacji opartej na zewnętrznej infrastrukturze chmurowej i tym samym oferowaniu produktu w ramach usługi SaaS.

Jak podeszliście do projektowania systemu eON, czyli chmurowego następcy aSISta?

Z biegiem lat aplikacja bardzo się powiększyła. Nie tylko zyskała nowe rodzaje sprawozdań, ale także wiele nowych funkcji, często wdrażanych na indywidualne życzenie klienta.

Przystępując do projektowania nowego rozwiązania, nie mieliśmy żadnych twardych danych analitycznych uzyskiwanych np. z bieżącego monitorowania systemu. Nie tylko z powodu instalacji systemu na wewnętrznych serwerach banków, ale również ze względu na ograniczenia formalne gromadzenia takich danych.

Bazowaliśmy zatem na własnej wiedzy domenowej, na rozmowach z użytkownikami, czyli klientami, oraz na analizie historycznych zgłoszeń serwisowych. Na tej podstawie określiliśmy najważniejsze funkcje systemu, pozwalające na sporządzenie poprawnego i spójnego sprawozdania.  

Równie ważne było dla nas uwzględnienie nowego modelu sprzedaży, ponieważ oferowanie usług w modelu SaaS i sprzedaż produktów on-premise różnią się diametralnie.

Dodatkowym, niepomijalnym aspektem w przypadku rozwiązań chmurowych oferowanych instytucjom finansowym podlegającym regulacjom, są wymogi compliance stawiane przed takimi systemami. Wymogi te nałożyły szereg ograniczeń na system oraz wymusiły projektowanie, wdrażanie i dokumentowanie specyficznych rozwiązań. Głównie chodzi tu o obszar lokalizacji geograficznej danych oraz separacji i bezpieczeństwa danych, a także systemów wykorzystywanych przez poszczególnych klientów.

Co wyniknęło z Waszej analizy, jeśli chodzi o funkcje chmurowego systemu do sprawozdawczości obligatoryjnej eON?

W wyniku analizy dostępnych nam materiałów wyłoniła się nam różnorodna charakterystyka pracy z systemem. Część funkcji aSISt była na tyle dobrze odbierana przez użytkowników i na tyle mocno osadziła się w ich codziennych przyzwyczajeniach, że postanowiliśmy przenieść ją wprost, jeden do jednego. Przykładem jest bieżąca walidacja poprawności danych w sprawozdaniu w miarę edytowania danych, tzw. walidacja online.

Były też takie funkcje, które przeprojektowaliśmy, tak aby najlepiej wykorzystać aspekty nowych technologii i możliwości dawanych przez środowisko chmurowe. W ten sposób zrodziła się w eON sesja pracy ze sprawozdaniem. Jest to powszechnie stosowana funkcja np. bankowości internetowej, gdzie aplikacja monitoruje aktywność użytkownika, a w przypadku odnotowania jej braku - wylogowuje użytkownika z systemu.

W trakcie rozwoju eON pojawiły się też obszary funkcjonalne dostępne w aSISt, które istotne były na czas ich powstania, ale w toku użytkowania systemu okazały się być zaimplementowane na wyrost. Takim przykładem jest jednoczesna praca wielu osób nad jednym raportem. W aplikacji aSISt sprawozdania składają się z tabel, które jednocześnie może edytować więcej niż jeden użytkownik, współdzieląc swoją pracę. Wiemy już, że zespoły sporządzające sprawozdanie dzielą się obszarami merytorycznie, nie krzyżując swojej pracy na pojedynczej tabeli.

Dlatego uznaliśmy, że w systemie eON wystarczającym będzie możliwość edycji danej tabeli wyłącznie przez jednego użytkownika. Natomiast wprowadzane lub modyfikowane przez niego dane są na bieżąco prezentowane innym użytkownikom pracującym z tym sprawozdaniem. Co więcej, pomiędzy tabelami istnieją reguły kontrolne sprawdzające poprawność i spójność danych. W przypadku konfliktów, w tym miejscu dane muszą zostać uzgodnione.

Czyli system eON to ulepszony odpowiednik aSISta tyle tylko, że oparty o zewnętrzną infrastrukturę chmurową?

Są takie funkcje, które dostępne były w aSISt i docelowo zamierzamy je umieścić w eON, ale są też takie, co do których mamy pełne przekonanie, że w eON nigdy się nie znajdą. Na ten moment funkcje systemu w zupełności wystarczają instytucjom, dla których oferujemy ten produkt.

Nie ukrywam, że wdrażając system u pierwszego klienta, czyli w Banku Spółdzielczym z Brodnicy okazało się, że kilka pominiętych na tamtym etapie funkcji było jednak istotnych dla klienta. Dlatego też zbadaliśmy poziom satysfakcji klientów z oferowanej usługi już po jej uruchomieniu. W ramach tych prac zidentyfikowaliśmy takie obszary, które wymagały dodatkowych implementacji i wdrożenia w eON.

Przykładem takiej opcji jest zamiana widoku, a dokładnie obracanie tabeli, czyli zmiana miejscami kolumn z wierszami, ze względu na kształt tej tabeli i przyzwyczajenia pracy użytkowników systemu. Selekcjonując zakres funkcjonalny systemu, w ogóle nie braliśmy jej pod uwagę. Ale rzeczywiście przy niektórych raportach taka możliwość ułatwia wypełnianie danych w tabeli. Dzięki partnerskiemu podejściu i dużej wyrozumiałości tego klienta szybko wdrożyliśmy brakujące elementy.

Co jeszcze różni eON od aSISta?

Na pierwszy rzut oka nie da się nie zauważyć, że zmianie uległo GUI, czyli graficzny interfejs użytkownika. Zmieniła się też technologia – teraz frontend piszemy w React. Widok ekranu jest bardziej nowoczesny, choć nie ukrywajmy, w dalszym ciągu jest to zbiór tabel.

Mimo to położyliśmy duży nacisk, aby lepiej zaprojektować pracę w systemie i wykorzystać możliwości, jakie daje nam nowoczesna technologia oraz przeniesienie ciężaru obliczeniowego na serwer w miejsce wykorzystania lokalnych zasobów stacji roboczej. Tym samym do pracy w systemie potrzebny jest wyłącznie komputer z dostępem do sieci Internet i przeglądarka internetowa.

Wdrożyliśmy optymalne wykorzystanie zasobów informatycznych serwera oraz współdzielenie wyników operacji wykonanych już wcześniej w systemie przez innego użytkownika.

Zoptymalizowaliśmy też działania użytkownika w aplikacji poprawiając UI, czyli interfejs użytkownika oraz wprowadzając zapamiętywanie jego indywidualnych ustawień. To wszystko po to, aby skrócić czas tworzenia raportów.

Klienci, którzy przeszli z aSISt-a na eON-a są naprawdę zadowoleni z tych zmian. Porównują to do zmiany starego samochodu na dużo lepszy model.

Co sprawiło Wam trudność w przeniesieniu aplikacji na środowisko chmurowe?

Największym wyzwaniem z mojej perspektywy była organizacja pracy kilku specjalistycznych zespołów developerskich. Zachowanie płynności bieżącej pracy przy jednoczesnym ciągłym dążeniu do obranego celu to nie lada wyzwanie.

Innym, ale równie ważnym aspektem był przeskok technologiczny, jakim była nie tylko zmiana aplikacji desktopowej w webową, ale jednoczesne uruchomienie jej w środowisku chmurowym z wykorzystaniem natywnych usług oferowanych przez dostawcę chmury publicznej.

Taki system powinien być dobrze zabezpieczony. Wiem, że  pracowaliście z zewnętrznymi specjalistami, czy możesz powiedzieć coś o tej współpracy?

Owszem. Przy projektowaniu i realizacji rozwiązań odpowiadających za bezpieczeństwo systemu na wszystkich jego warstwach współpracowaliśmy z partnerem OChK (Operator Chmury Krajowej), korzystając z jego wiedzy i doświadczeń. Następnie wdrożone rozwiązania zostały poddane wewnętrznemu audytowi, w wyniku którego ujawnione zostały wymagane oraz potencjalne usprawnienia podnoszące bezpieczeństwo systemu.

Kolejnym krokiem było dostosowanie systemu do wskazań z audytu. Dzięki tym działaniom oferowana przez nas usługa jest w pełni zgodna z wymaganiami formalnymi oraz najlepszymi praktykami w zakresie zabezpieczenia systemów instytucji finansowych.

Czy zdradzisz, jakie są plany rozwoju aplikacji chmurowej eON?

Nie mogę powiedzieć za wiele, ponieważ konkurencja nie śpi, a praca wre. Myślę jednak, że nie jest tajemnicą, że planujemy rozwijanie aplikacji eON. Szczególnie w obszarze dostarczania danych do sprawozdań oraz robotyzacji procesów biznesowych. Na bieżąco dodajemy też nowe sprawozdania, np. ostatnio dodaliśmy zarządzanie ryzykiem stopy procentowej księgi bankowej, czyli sprawozdawczość IRRBB, a w planach są jeszcze transakcje oszukańcze, czyli Fraudulent Payments.