Wyzwania informatyki bankowej 2016
wyzwania_informatyki_bankowej_0 wyzwania_informatyki_bankowej_0
też zostanie przeprowadzony jednorazowo, metodą „big-bang”. W pierwszym przypadku konieczne jest zaplanowanie koegzystencji rozwiązań i uwzględnienie kosztów z nią związanych, w drugiej zaplanowanie i przeprowadzenie szczegółowych testów tak, aby zmniejszyć ryzyko. W identyfikacji potencjalnych problemów i weryfikacji założeń może pomóc metoda prototypowania, pozwalająca na szybkie sprawdzenie zachowania komponentów systemu po przeniesieniu na nową platformę. W przypadku systemów bankowych szczególne istotne jest potwierdzenie na wczesnym etapie wydajności i skalowalności części transakcyjnej oraz zweryfikowanie złożoności przenoszenia przetwarzania wsadowego. Konieczne jest wczesne sprawdzenie wymaganej wydajności i skalowalności rozwiązania a także dostępności zamienników narzędzi wspomagających w środowisku mainframe (np. scheduler zadań wsadowych, monitor transakcyjny, etc.) W procesie tym pomagają dostępne na rynku pakiety, które pozwalają emulować środowisko mainframe na procesorach Intel albo wręcz wykorzystać kod oprogramowania z mainframe›a (najczęściej napisany w COBOLu) i skompilować go do kodu binarnego możliwego do uruchomienia w systemie Unix lub Windows Server. Przykłady takich rozwiązań to produkty firmy Microfocus – emulator mainframe’a na systemy Unix lub Windows, a także kompilator COBOLa. Ciekawym rozwiązaniem jest produkt firmy Raincode, pozwalający na kompilowanie kodu COBOLa do obiektów środowiska .Net w systemie Windows Server. Firma ta posiada w ofercie również produkt umożliwiający emulowanie środowiska przetwarzania wsadowego – uruchamianie zadań JCL w systemie Windows. Zastosowanie tych narzędzi pozwala na uniknięcie konieczności translacji kodu na inny język programowania, co znacząco zmniejsza wysiłek niezbędny do przeprowadzenia przedsięwzięcia. Oprócz tego na rynku dostępnych jest sporo rozwiązań odtwarzających w środowisku Windows i Unix funkcjonalność narzędzi mainframe wykorzystywanych w przetwarzaniu danych - np. SORT lub ICETOOL. Dzięki tym narzędziom możliwe jest istotne ograniczenie kosztów przedsięwzięcia. Zastosowanie sprawdzonej metodyki prowadzenia projektu pozwala na wczesną identyfikację najistotniejszych kwestii do rozstrzygnięcia oraz minimalizację ryzyka. Centralny system bankowy na nowej platformie 159
Co dalej? Pojawia się pytanie, czy wymiana platformy technologicznej wyczerpuje możliwości, które współczesne IT oferuje bankom. Czy migracja do nowocześniejszych komponentów sprzętowych, systemowych i aplikacyjnych to już koniec drogi. Nam wydaje się, że jest krokiem pośrednim, dającym znaczące oszczędności i zwiększającym elastyczność, jak wskazano w przykładach powyżej. Krokiem pośrednim, bo umożliwiającym przeprowadzenie dalszej zmiany – przede wszystkim otwierającym możliwość przejścia na przetwarzanie oparte na chmurze obliczeniowej. Obecnie w departamentach IT banków panuje dobre zrozumienie zalet przetwarzania w chmurze. Widoczna jest natomiast niepewność związana z bezpieczeństwem danych i dotycząca zgodności takiego modelu z wymogami regulacji. Wierzymy, że takie obawy zostaną rozwiane i banki będą miały możliwość korzystania z zalet chmury obliczeniowej w całym spektrum jest zastosowań – od środowisk rozwojowych i testowych przez przechowywanie danych aż po kompletne aplikacje działające w chmurze. Nic nie stoi na przeszkodzie aby w pierwszym kroku korzystać z chmury prywatnej. Takim wdrożeniem jest opisany wcześniej przykład SDC. Instytucja ta skupiła wokół siebie pewne środowisko banków, którym udostępniła usługi ze wspólnej platformy systemowej. Innymi słowy banki powiązane z SDC zbudowały wspólną infrastrukturę, z której dostarczane są usługi w modelu SaaS. Wydaje się, że również w Polsce taki alians miałby szansę zaistnieć - chociażby w środowisku banków spółdzielczych. Kolejny krok to użycie chmury publicznej. Na dzisiaj przeniesienie do niej systemu centralnego banku wydaje się perspektywa odległą. Nie ma przeszkód, aby różne systemy okalające system centralny i systemy wspierające już dzisiaj wynosić do chmury. Podróż do chmury mogą także przyspieszyć kolejne regulacje pojawiające się na rynku. Przykładem tej, która będzie wpływać na rozwój architektury głównych systemów bankowych jest dyrektywa PSD2 i koncepcja otwartych API bankowych. Jeśli zostanie podchwycona przez rynek, pozwoli ona na budowę kompletnych ekosystemów w oparciu o usługi bankowe udostępniane na zewnątrz poprzez API. Koncepcja ta będzie wymagała od banków dużej elastyczności rozwoju, a ta jest dużo łatwiejsza po przejściu na nowoczesne platformy technologiczne. Wizja otwartego API pozwoli na «oderwanie rachunku od banku». Będzie to kompletne odmiejscowienie rachunku, którego nikt nie wyobrażał sobie w latach 90., a które nawet dla dzisiejszych użytkowników bankowości na smartfonach będzie nowością. 160 Andrzej Gibas, Microsoft, Karol Mazurek, Accenture
- Page 109 and 110: i autoryzacji klienta na stronie ba
- Page 111 and 112: Firmy te nie są bankami, a płatno
- Page 113 and 114: Klienci indywidualni W kontekście
- Page 115 and 116: espondentów przyznało, że zdarzy
- Page 117 and 118: Cashless i paperless Poland, w obie
- Page 119 and 120: Pomysł islandzki jest jednak wyją
- Page 121: W takim układzie banki zostaną zm
- Page 124 and 125: Piotr Pinchinat-Miernik, Paweł Muc
- Page 126 and 127: Jeszcze na początku lat 90. równi
- Page 128 and 129: System ten pozwala klientom na wyda
- Page 130 and 131: Najnowsze rozwiązanie, czyli wszys
- Page 132 and 133: Korzyści dla wierzycieli • Łatw
- Page 134 and 135: Płatności G2C oraz G2B W przyszł
- Page 136 and 137: Andrzej Kawiński, Giesecke & Devri
- Page 138 and 139: nia jest ograniczona, co ogranicza
- Page 140 and 141: W Polsce Państwowa Wytwórnia Papi
- Page 142 and 143: Europejskie standardy przechowywani
- Page 144 and 145: gotówka (często liczona, paczkowa
- Page 146 and 147: urządzeń zainstalowanych w sortow
- Page 148 and 149: Zagraniczne doświadczenia pokazuj
- Page 150 and 151: Andrzej Gibas, Microsoft, Karol Maz
- Page 152 and 153: • duża zmienność rynków i wra
- Page 154 and 155: Dominujące dzisiaj podejście do a
- Page 156 and 157: procesorów budowanych w oparciu o
- Page 158 and 159: SDC uzyskało oszczędności na poz
- Page 163 and 164: Aleksander P. Czarnowski Prezes AVE
- Page 165 and 166: z co najmniej 2-, a jeszcze lepiej
- Page 167 and 168: Ransomware czyli różne oblicza sz
- Page 169 and 170: system nigdy nie dostarcza pełnego
- Page 171 and 172: Rys 2. Przykład fałszywej wiadomo
- Page 173 and 174: IoT Internet of Things z pewności
- Page 175 and 176: Podatności w SSL/TLS oraz algorytm
- Page 177 and 178: instalacja i konfiguracja serwera S
- Page 179 and 180: w krótkim czasie. Dla niektórych
- Page 181 and 182: Adam Marciniak Dyrektor Pionu Rozwo
- Page 183 and 184: 50 tys. komputerów w tym samym cza
- Page 185 and 186: które łącznie pozwoliły wyprowa
- Page 187 and 188: skutkując izolacją kraju od reszt
- Page 189 and 190: tacji branżowych narodziła się k
- Page 191 and 192: Ciekawym przykładem z ojczyzny Int
- Page 193 and 194: Z inicjatywy Rady Bankowości Elekt
- Page 195: • Opracowanie ogólnobankowej, sp
- Page 198 and 199: Maciej Gawroński, Sławomir Szepie
- Page 200 and 201: • Sprecyzowanie katalogu wyłącz
- Page 202 and 203: • Płatnik (posiadacz rachunku ba
- Page 204 and 205: Zagraniczne podmioty profesjonalnie
- Page 206 and 207: gulacje odnośnie opłat interchang
- Page 208 and 209: nikacji między poszczególnymi pod
też zostanie przeprowadzony jednorazowo, metodą „big-bang”. W pierwszym<br />
przypadku konieczne jest zaplanowanie koegzystencji rozwiązań<br />
i uwzględnienie kosztów z nią związanych, w drugiej zaplanowanie i przeprowadzenie<br />
szczegółowych testów tak, aby zmniejszyć ryzyko.<br />
W identyfikacji potencjalnych problemów i weryfikacji założeń może pomóc<br />
metoda prototypowania, pozwalająca na szybkie sprawdzenie zachowania<br />
komponentów systemu po przeniesieniu na nową platformę. W przypadku<br />
systemów bankowych szczególne istotne jest potwierdzenie na wczesnym<br />
etapie wydajności i skalowalności części transakcyjnej oraz zweryfikowanie<br />
złożoności przenoszenia przetwarzania wsadowego. Konieczne jest wczesne<br />
sprawdzenie wymaganej wydajności i skalowalności rozwiązania a także dostępności<br />
zamienników narzędzi wspomagających w środowisku mainframe<br />
(np. scheduler zadań wsadowych, monitor transakcyjny, etc.)<br />
W procesie tym pomagają dostępne na rynku pakiety, które pozwalają<br />
emulować środowisko mainframe na procesorach Intel albo wręcz wykorzystać<br />
kod oprogramowania z mainframe›a (najczęściej napisany w COBOLu)<br />
i skompilować go do kodu binarnego możliwego do uruchomienia w systemie<br />
Unix lub Windows Server. Przykłady takich rozwiązań to produkty firmy<br />
Microfocus – emulator mainframe’a na systemy Unix lub Windows, a także<br />
kompilator COBOLa. Ciekawym rozwiązaniem jest produkt firmy Raincode,<br />
pozwalający na kompilowanie kodu COBOLa do obiektów środowiska .Net<br />
w systemie Windows Server. Firma ta posiada w ofercie również produkt<br />
umożliwiający emulowanie środowiska przetwarzania wsadowego – uruchamianie<br />
zadań JCL w systemie Windows. Zastosowanie tych narzędzi pozwala<br />
na uniknięcie konieczności translacji kodu na inny język programowania, co<br />
znacząco zmniejsza wysiłek niezbędny do przeprowadzenia przedsięwzięcia.<br />
Oprócz tego na rynku dostępnych jest sporo rozwiązań odtwarzających<br />
w środowisku Windows i Unix funkcjonalność narzędzi mainframe wykorzystywanych<br />
w przetwarzaniu danych - np. SORT lub ICETOOL.<br />
Dzięki tym narzędziom możliwe jest istotne ograniczenie kosztów przedsięwzięcia.<br />
Zastosowanie sprawdzonej metodyki prowadzenia projektu pozwala<br />
na wczesną identyfikację najistotniejszych kwestii do rozstrzygnięcia<br />
oraz minimalizację ryzyka.<br />
Centralny system bankowy na nowej platformie<br />
159
Change language