Czy w Polsce buduje się innowacyjne oprogramowanie dla instytucji finansowych?

Rozpoczęte w połowie 2019r. badania, prowadzone przez Giełdę Papierów Wartościowych w Warszawie (GPW),
współfinansowane przez Narodowe Centrum Badań i Rozwoju (NCBR), zmierzają do zbadania tezy, że w warunkach polskich uda się zaprojektować i wytworzyć oryginalnie polską aplikację, stanowiącą  prototyp nowej platformy transakcyjnej dla giełd  w dowolnym miejscu globu. Uznano, że okaże się ona skutecznym narzędziem do weryfikacji tezy, o ile będzie posiadać poniższe cechy:

• będzie użytkowana na rynkach prowadzonych przez Spółki z Grupy Kapitałowej GPW,
• będzie oferowana innym podmiotom funkcjonującym na rynku kapitałowym (głównie działającym na mniej rozwiniętych rynkach regionu Europy Środkowo-Wschodniej (CEE),
• oferując nowe funkcjonalności w stosunku do obecnie używanej platformy transakcyjnej będzie równocześnie możliwa do dalszego rozwoju siłami GPW,
• skróci czas odpowiedzi systemu (ang. latency) w porównaniu z konkurencyjnymi rozwiązaniami, 
• umożliwi jednoczesne prowadzenie obrotu szerokim zakresem aktywów, od instrumentów finansowych po, potencjalnie, paczki energii (ang. multi-trading, multi-asset),
• będzie skalowalna zarówno pod względem:

- jakościowym, czyli możliwości dodania obsługi nowych rynków czy zwiększenia zakresu informacji wysyłanych do uczestników giełdy czy dodania dowolnej innej nowej funkcjonalności, 

- ilościowym, czyli możliwości zwiększenia ilości przetwarzanych zleceń przy jednoczesnym utrzymaniu niskiego poziomu opóźnień. 

Prototyp o wyżej wymienionych cechach został wytworzony i jest cały czas poddawany intensywnym testom, które określą, czy w założonym reżimie wydajnościowym, w sposób stabilny dostarcza określoną funkcjonalność. Kolejne kroki zmierzające do pozytywnej weryfikacji powyższej tezy, tj.  wdrożenie w jakimś rzeczywistym środowisku giełdowym, dopiero nastąpią. 

Wziąwszy pod uwagę fakt, że technologia to w istocie dobrze opisana, metoda wykorzystywania osiągnięć techniki, , takich jak (w tym przypadku): serwery, rutery komunikacyjne, silniki baz danych, języki programowania, specjalistyczne oprogramowanie do szyfrowania, zarządzania procesami itp., to wytworzenie prototypu jest równoznaczne z wytworzeniem nowoczesnej, polskiej technologii.

Czy w Polsce buduje się innowacyjne oprogramowanie dla instytucji finansowych?

Pod koniec lat 90-tych ubiegłego stulecia w Polsce rozpoczęły się na szeroką skalę prace polegające na wsparciu narzędziami informatycznymi podmiotów publicznych, które toczyły się równolegle do wdrażania narzędzi informatycznych w bankach czy firmach ubezpieczeniowych. Wdrożenia nowoczesnych narzędzi informatycznych w instytucjach finansowych zakończyły się sukcesem już w początkowych latach XXI w. W instytucjach publicznych, zarówno na szczeblu centralnym, jak i samorządowym, trwało to trochę dłużej, w wielu przypadkach (na przykład telemedycyna) dopiero pandemia pozwoliła zakończyć prace ciągnące się przez dekady. Tymczasem polskie banki w stosowaniu narzędzi informatycznych do wspierania zarządzania procesami, takimi jak obsługa wniosków kredytowych, kontakty z klientami, nowe mechanizmy płatności, wybiły się na jedno z pierwszych miejsc na świecie. Problemem występującym w projektach prowadzonych w bankach była konieczność stosowania procedur dopasowanych do krajów, w których funkcjonowały centrale banków. Na przykład procedury stosowane przy tworzeniu oprogramowania wspierającego udzielanie kredytów, powodowały zmniejszenie puli udzielanych kredytów, gdyż uwzględniały one typy zachowania społeczeństwa  Niemiec czy Włoch, więc były nieadekwatne dla warunków polskich. Zwiększenie puli kredytów, a więc przychodów, wymagało zatem rezygnacji z pełnej automatyzacji i włączania w proces operatora, co de facto było cofaniem się w cyfrowej dojrzałości.  Z czasem zaczęto wprowadzać specyficzne polskie procedury, co pozwoliło wrócić do pełnej automatyzacji. Jednak należy podkreślić, że w odróżnieniu do aplikacji obsługujących sferę publiczną (z nielicznymi wyjątkami), rozwiązania funkcjonujące w instytucjach finansowych były importowane z zagranicy, bądź - choć wytworzone w Polsce - odwoływały się do koncepcji i pomysłów wypracowanych za granicą.  Opisywane tutaj badania wpisują się w prace zmierzające do uczynienia z Polski kraju, w którym tworzy się nowe technologie. Zainicjowała je debata, toczona przez lata w środowiskach informatycznych: czy można w Polsce wypracowywać nowe informatyczne koncepcje architektoniczne oraz wytworzyć polskie rozwiązanie informatycznie dla takiej instytucji, której charakter z definicji stawia wysokie wymagania każdemu rozwiązaniu i które w sprzyjających okolicznościach stanie się produktem sprzedawalnym na światowych rynkach? Wybór środowiska giełdowego do prowadzenia prac był - z badawczego punktu widzenia - w dużej mierze arbitralny. Choć ze względu na niszowy charakter informatycznych rozwiązań giełdowych, jednocześnie charakteryzujących się wysokimi wymaganiami wydajnościowymi (niezwykle krótkie czasy odpowiedzi, duże obciążenia komunikatami) dodatkowo potencjalnie uwiarygadniający weryfikację tezy, że w warunkach polskich uda się zaprojektować i wytworzyć oryginalnie polską aplikację przeznaczoną dla instytucji finansowej w dowolnym miejscu globu, w szczególnie trudnym środowisku. Zrobienie oryginalnej aplikacji dla giełdy wymaga bowiem rozwiązania problemów niespotykanych w środowiskach stricte bankowych czy ubezpieczeniowych. Należy wziąć pod uwagę fakt, że w przypadku transakcji giełdowych czasy dokonywania transakcji muszą być liczone w milisekundach. Dzieje się tak dlatego, że makler z Londynu dokonując transakcji na giełdzie w Warszawie, konkuruje (składając zlecenie) np. z maklerem z Pragi. Zlecenia składane są zdalnie. Okazuje się więc, że prędkość światła, pojęcie dość abstrakcyjne na co dzień, tutaj nabiera praktycznego znaczenia. Mianowicie, biorąc pod uwagę prędkość światła w powietrzu (około 291 tysięcy km/h) oraz odległości mierzone w kilometrach (na przykład Londyn – Warszawa to około 1500 km) wychodzi, że czas potrzebny na przebycie zlecenia z Londynu do Warszawy, a mówiąc ściśle do portu wejściowego platformy transakcyjnej, to 5 milisekund. Zatem czasy dokonywania transakcji winny być również mierzone w milisekundach. Milisekunda stanowi bowiem podstawową miarę czasu w świecie transakcji na instrumentach finansowych i takich jak rynki mocy czy energii. Liczby zleceń na przeciętnym rynku idą w miliony w ciągu sesji, co z kolei narzuca na platformy transakcyjne wymaganie zapewnienia krótkich czasów odpowiedzi (niskiej latencji) przy dużej intensywności przetwarzania, wyrażanej liczbą komunikatów, przechodzących przez system na minutę. Wziąwszy to wszystko pod uwagę, wydaje się, że to właśnie giełdowa platforma transakcyjna może być najlepszym weryfikatorem wyżej wymienionej tezy.

Jakie cechy winno posiadać oprogramowanie wytworzone w Polsce, żeby można je sprzedawać na światowych rynkach?

Polska jest rozpoznawalna w świecie jako niewysychające źródło programistów czy matematyków tworzących nowe algorytmy dla licznych światowych korporacji. Niestety nie jest postrzegana jako kraj, w którym stworzono oryginalne oprogramowanie, które w jakiejś dziedzinie zdobyło światowe uznanie. Dla pełnego obrazu dodać należy, że zagraniczne firmy sięgają coraz częściej do polskich startupów, żeby ich produkty włączyć do swej sieci sprzedaży bądź  zintegrować ze swoimi produktami w taki sposób, żeby rozmyć oryginalne pochodzenie danego modułu. Przyczyn tego stanu rzeczy jest wiele. Wydaje się, że główny problem polega na braku środków potrzebnych do wprowadzenia nowego produktu z obszaru nowoczesnych technologii na globalny rynek. Niektóre spółki skarbu państwa mają potrzebne środki, ale raczej nie produkują nowoczesnych technologii (zajmują się eksploatacją starszych bądź nowszych licencji na jakieś rozwiązanie). Spółki prywatne często nie mają wystarczających środków, za to mając wytworzony własny, dobry produkt, stają się łatwym łupem dla firm zagranicznych. 

GPW tym projektem przełamuje tą sytuację.  

Podejmując prace należało określić wymiary, na których rozpięta zostanie nowa platforma transakcyjna, względem których produkt będzie oceniany na światowym rynku rozwiązań informatycznych. Zidentyfikowano następujące wymiary:

• Funkcjonalność – produkt musi umożliwiać co najmniej wspieranie działań w danej dziedzinie, które to działania wspierają potencjalnie konkurencyjne produkty; w przypadku rozwiązań giełdowych produkt musi umożliwiać składanie jak najszerszej gamy typów zleceń, jednocześnie umożliwiając obsługę wielu różnych rynków (na przykład instrumentów finansowych, mocy, energii itp.);
• Rzadko spotykane cechy operacyjne – na ogół to taki zestaw cech wydajnościowych (czasy odpowiedzi, stabilność pracy przy dużych obciążeniach) oraz cech zapewniających wysoką dostępność (high availability), który czyni dane oprogramowanie co najmniej porównywalnym do konkurencyjnych;
• Możliwość szybkiego wdrożenia w nowym środowisku – wytworzone rozwiązanie powinno być relatywnie łatwe do wdrożenia w środowisku informatycznym nowego klienta; nigdy bowiem nie jest tak, że nowe oprogramowanie zastępuje w całości oprogramowanie u danego klienta, raczej zastępuje jakiś, większy czy mniejszy, fragment działającego środowiska; w tym miejscu podkreślić należy konieczną zdolność stosowania ogólnie wykorzystywanych w danej dziedzinie protokołów komunikacyjnych; 
• Niski koszt utrzymania oraz łatwość wprowadzania modyfikacji – niski koszt utrzymania wraz z ceną rozwiązania stanowiące całkowity koszt wdrożenia  (total cost of ownership) są najważniejszym (prócz spełnienia oczekiwań funkcjonalnych i operacyjnych danego klienta) kryterium stosowanym przy wyborze danego narzędzia. Koszt jego utrzymania jest pochodną takich kwestii jak, jakość mierzona jego wydajnością, stabilnością działania i małą liczbą błędów ujawniających się podczas eksploatacji, łatwość z jaką rozszerzyć można funkcjonalność czy z jaką można poprawiać już istniejące funkcjonalności, dobra dokumentacja ułatwiająca jego eksploatację i modyfikację przez osoby, które nie uczestniczyły w jego tworzeniu.

Podstawą  optymalnego, z punktu widzenia potencjału sprzedażowego, rozłożenia rozwiązania na wyżej wskazanych wymiarach jest jego architektura. Optymalna architektura oprogramowania, które wprowadzamy na rynki światowe, winna zawierać obok pewnych standardowych elementów również takie, które  zakładają zupełnie nowy sposób wykorzystania istniejących technologii czy koncepcji. Architektura to nie tylko statyczny zbiór dobrze opisanych elementów,  ale także opis sposobu współpracy tych wszystkich elementów w taki sposób, żeby oferować potrzebną funkcjonalność w reżimie rzadko spotykanych cech operacyjnych, jednocześnie zapewniając możliwość szybkiego wdrożenie w nowym środowisku. Dodatkowo, co często jest zaniedbywane przez polskie firmy produkujące oprogramowanie, architektura winna być udokumentowana przy zastosowaniu powszechnie stosowanych standardów m.in. w celu umożliwienia wprowadzania modyfikacji czy rozszerzeń przez inżynierów innych niż tworzący oprogramowanie.

Nowa platforma transakcyjna 

Wziąwszy powyższe pod uwagę została zaprojektowana i wytworzona nowa platforma transakcyjna. Nie tylko architektura, ale również cały kontekst biznesowy oraz techniczny, zostały udokumentowane w standardzie opengroup enterprise architecture przy użyciu pakietu oprogramowania Sparx Enterprise Architect. Procesy operacyjne czy biznesowe zostały wymodelowane przy użyciu języków modelowania procesów, ArchiMate oraz Unified Modelling Language (UML). W celu zwiększenia waloru sprzedażowego platformy na rynkach światowych wszystkie informacje na odpowiednich diagramach, zapisano w języku angielskim. 

Funkcjonalność nowej platformy transakcyjnej

W sensie funkcjonalnym platforma transakcyjna (trading platform) dla giełd musi zapewnić uczestnikom danego rynku (trading participants) możliwość składania zleceń i zawierania transakcji po skojarzeniu (matching) zleceń zakupu z zleceniami sprzedaży, przy braniu pod uwagę, wszelkich dostępnych indeksów, charakterystycznych dla danego rynku oraz informacji publicznej, rynkowej (market data), na którą składa się m.in. historia już zawartych transakcji. Diagram nr 1 pokazuje ten podstawowy sens funkcjonalny.

Diagram 1 Wykonano przy pomocy Sparx Enterprise Architect.

Na diagramie 1, po prawej stronie mamy platformę, która przetwarza zlecenia (order processing), czyli przyjmuje zlecenia, układa je w katalogu zleceń (order book), następnie kojarzy zlecenia zakupu ze zleceniami sprzedaży, a w końcu przygotowuje pakiety informacji rynkowej i przesyła je do uczestników giełdy. Po lewej stronie diagramu pokazana jest aplikacja, którą stosują uczestnicy giełdy, w tym domy maklerskie, w celu handlu instrumentami na danym rynku. Zasadniczo ta ostatnia aplikacja, stanowiąca element dostępowy, nie jest częścią platformy transakcyjnej. Jednak żeby poszerzyć możliwości dokładnego testowania nowej platformy transakcyjnej jako takiej, jak i umożliwić uczestniczenie w procesach przetargowych, w których często oczekiwane jest wykonanie pilotowego rozwiązania obejmującego zarówno część dostępową, jak i samą platformę transakcyjną, wykonano również taką platformę dostępową. Zlecenia są różnych typów, niektóre związane są z rodzajem rynku (papierów wartościowych, mocy, energii itp.). Wytworzono taką architekturę nowej platformy transakcyjnej, żeby wszystkie standardowe typy zleceń na różnych rynkach mogły być realizowane – multi-asset.  Jednocześnie mogą być przetwarzane na różnych rynkach: multi-trading.  Stworzenie odpowiednej architektury wymaga, poza schematem opisującym de facto statykę zagadnienia  (patrz diagram 1) –, opisania jak wydarzenia „dzieją się” w systemie względem osi czas. Musi powstać opis kinematyki dziejącej się w platformie transakcyjnej.

Kinematyka platformy transakcyjnej

Na diagramie 1 zaznaczono podstawowe obszary funkcjonalne wewnątrz, jak i na zewnątrz platformy transakcyjnej. W ramach obszaru można zidentyfikować moduły i konstytuujące je komponenty. Zaznaczono kierunki wymiany informacji pomiędzy poszczególnym obszarami, ale ten statyczny obraz nie wystarcza, żeby zaprojektować architekturę. Potrzebny jest szczegółowy obraz kinematyki, czyli w jaki sposób komunikaty będące nosicielami informacji krążą pomiędzy modułami i komponentami (które składają się na moduły). Do opisu wprowadzono czas i kolejność zdarzeń względem czasu. Warto zwrócić uwagę, że opis zyskuje w jakiejś mierze charakter dynamiczny, gdyż wskazuje również które moduły czy komponenty powodują uruchomienie innych (invoke), oddziałując  zawartością  przesyłanych między sobą komunikatów. Zatem opis ten precyzyjnie przedstawia już ruch i dynamikę wewnętrzną, zachodzącą w platformie transakcyjnej, choć na tym etapie prac dokładne podziały na moduły i komponenty nie są jeszcze możliwe. Dopiero opisy - statyczny i kinematyczny - razem pozwalają na rozpoczęcie tworzenia architektury platformy transakcyjnej. Poniżej – diagramy 2 oraz 3 – pokazują przykłady kinematyki w dwóch kluczowych obszarach, Order Service oraz Order Processing pokazanych na diagramie 1.

Diagram 2 Wykonano przy pomocy Sparx Enterprise Architect.

Diagram 2 pokazuje kinematyką związaną przyjęcia przez port wejściowy zlecenia i jego dalszą obsługę w platformie. Kluczowym elementem jest przesłanie odpowiednich komunikatów do obszaru Order Processing, gdzie najważniejszą rolę pełni moduł do kojarzenia zleceń sprzedaży z zleceniami zakupu (roboczo nazywany na tym etapie matcher) oraz moduł odpowiedzialny za wysyłanie do uczestników giełdy informacji publicznej (roboczo nazywany na tym etapie on-line market data) w czasie rzeczywistym. Już na tym etapie prac założono, że moduły realizujące grupy funkcji nie wchodzą w interakcje między sobą, ale komunikują się za pośrednictwem jednego medium tzw. szyny komunikacyjnej (roboczo nazywany na tym etapie core busI).  Na kolejnym diagramie - diagram 3 - pokazany jest sposób współpracy matcher’a (CM) z  szyną komunikacyjną. 

Diagram 3 Wykonano przy pomocy Sparx Enterprise Architect.

Należy zwrócić uwagę, że na etapie tworzenia kinematyki rozwiązania żadne decyzje co do cech szyny komunikacyjnej nie muszą być podjęte. Do stworzenia opisu kinematycznego platformy wystarcza poczynienie założenia, że szyna zostanie stworzona i posłuży jako medium komunikacyjne między modułami czy komponentami. Założenie o stosowaniu szyny komunikacyjnej jako medium do przesyłania komunikatów między modułami czy komponentami jest bowiem od dwóch dekad dość oczywiste – więcej o tej kwestii znajduje się w kolejnym rozdziale.

Architektura nowej platformy transakcyjnej

Opracowana architektura wychodzi od ogólnego kontekstu biznesowego (diagram 1), uwzględniając oczekiwaną  kinematykę – opisaną na  diagramach 2 oraz 3 – oraz innymi oczekiwaniami, jak na przykład tymi optymalnymi z punktu widzenia potencjału sprzedażowego. 

Pierwszą kwestią, którą należało rozstrzygnąć, był sposób współpracy modułów, grupujących określony rodzaj funkcjonalności, między sobą. Od końca lat 90. XX w. zaczęto stosować architekturę zorientowaną na usłudze, SOA (service oriented architecture). Wiele dotychczasowych programów komputerowych działających w inny sposób niż ten wskazywany w modelu SOA przebudowano do SOA. Na diagramie 4 wskazano podstawą cechę tej koncepcji, czyli stosowanie szyny jako medium komunikacji i współpracy między przyłączonymi do szyny modułami realizującymi grupy usług.

Diagram 4

Od początku lat 60. XX w., gdy zaczęła się era komputerów klasy IBM mainframe, zdolnych, do wykonywania dużej liczby różnych obliczeń jednocześnie, zaczęto konstruować programy komputerowe o dość ściśle wyspecjalizowanej funkcjonalności, które z czasem łączone w grona (patrz lewa strona diagramu 4) dotychczas samodzielne stawały się modułami, a ich grono programem komputerowym, aplikacją. Rozrost grona następował organicznie. W takim gronie moduły współpracowały w trybie „każdy z każdym”, często ze względu na ten organiczny, rozłożony w czasie rozrost, moduł X inaczej współpracuje z modułem Y, a inaczej z modułem Z. Gdy pod koniec lat 90. XX w. liczba modułów, ich zróżnicowanie w przeciętnym programie komputerowym, zwłaszcza takim działającym w banku  były już znaczące, to w wymiarze „Niski koszt utrzymania oraz łatwość wprowadzania modyfikacji” sytuacja nie wyglądała dobrze. Dodatkowo wydajności przetwarzania spadały i to po mimo, że wydajność procesorów, obsługi pamięci operacyjnej rosły w tym samym czasie szybko. Rozpoczęto poszukiwania takiej architektury aplikacji komputerowych, które rozwiązałyby ten problem. Inspiracji dostarczyły architektura stosowana w układach scalonych oraz teoria przestrzeni metrycznych z metryką „rzeka”, w rezultacie powstała SOA, którą widać po prawej stronie diagramu 4. Moduły nie współpracują przez komunikację „każdy z każdym”, ale za pośrednictwem szyny, którą na ogół nazywa się enterprise service bus (ESB). Przez dwie dekady, w rozlicznych aplikacjach szynę coraz bardziej obciążano różnymi funkcjami, poza samym transportem komunikatów pomiędzy modułami, kazano szynie wytyczać trasy dla komunikatów (routing) w zależności od tego, który moduł wysyła, a który odbiera, w zależności od treści komunikatu itp. Badania, które były prowadzone na GPW podczas trwania projektu wskazały, że należy cofnąć się w czasie t.j przez „odchudzenie” szyny z tych wszystkich funkcjonalności którymi „obrosła”, wrócić do klasycznej architektury the Core stosowanej cały czas w architekturze układów scalonych, w których szyna służy wyłącznie do przesyłania komunikatów pomiędzy procesorem, a pamięcią operacyjną. Ostatecznie szyna zastosowana w platformie transakcyjnej, którą udało się wytworzyć, jest pozbawiona wszelkich innych funkcji poza przesyłaniem komunikatów. Nawiązując do oryginalnej koncepcji the Core w opisach w języku angielskim stosowana jest więc nazwa core bus, w skrócie CBS.

Ostatecznie architektura wytworzonej platformy transakcyjnej jest przedstawiona na diagramie 5.

Diagram 5 Wykonano przy pomocy Sparx Enterprise Architect.

Gdzie core bus stanowiący fundament wydajnego działania platformy transakcyjnej jest obramowany na zielono. Należy zwrócić uwagę, że zastosowano w rozwiązaniu drugą szynę, już nie taką jak core bus, opartą o dostępne na rynku rozwiązanie, służącą do integracji platformy z elementami środowiska informatycznego, w którym każdorazowo będzie wdrażana, tym samym spełniając wymaganie względem wymiaru „Możliwość szybkiego wdrożenia w nowym środowisku”. Pamiętając o podstawowej funkcjonalności platformy transakcyjnej, tj. kojarzenia zleceń kupna ze zleceniami sprzedaży w celu dokonania transakcji w ramach sesji giełdowej, której parametry są ustalone w trybie dobowym bądź w ramach aukcji przedstawione są poniżej główne moduły

• OrderEntry Gateway OEG, stanowiący miejsce w platformie do którego „wpadają” zlecenia składane przez uczestników giełdy korzystających z jakiejś aplikacji dostępowej obsługującej jeden z dwóch protokołów– binarnego oraz standardowego protokołu wykorzystywanego przez instytucje giełdowe w świecie o nazwie FIX w wersji 5.0 SP2.
• Core Matching Engine, CME  którego rolą jest tzw. kojarzenie zleceń (matching). Moduł stanowi jądro całego systemu. Kojarzenie zleceń polega na skojarzeniu w zbiorze zleceń tych pozycji,  w których zlecenie kupna/sprzedaży będzie właściwą realizacją zlecenia, na określonych w zleceniu warunkach (czyli z ceną określoną warunkami takimi jak limity dla obu stron, brak limitu z jednej strony itp., realizując algorytm Price-Time-Priority/FIFO).
• Data Distribution System, DDS, którego rolą jest wysyłanie do uczestników giełdy informacji (market data) zwierającej dane o historii dokonanych w trakcie sesji transakcji połączonej z informacjami o indeksach, kursach itp. Informacja wysyłana z tego modułu jest szyfrowana realizując algorytm ChaCha 2 przy zastosowaniu ogólnie dostępnych bibliotek kodów źródłowych, dzięki czemu jest zapewnione elementarne bezpieczeństwo, ale możliwe jest również różnicowanie praw dostępu do tej informacji, w zależności od poziomu wniesionych przez uczestnika opłat.
• Parametrization, PRM, którego rolą jest ustawienie odpowiednich parametrów środowiska sesji podczas rozpoczęcia dnia.
• Supervision and Business Operations, SBO, służący do nadzorowania sesji.
• ITG, którego rolą jest, przy wykorzystaniu zewnętrznej szyny, integracja platformy ze środowiskiem informatycznym giełdy, w której platforma będzie wdrażana.
• AUX, odpowiedzialny za zarządzanie poszczególnym usługami (ang. services) platformy transakcyjnej oparty o oprogramowanie TRIGLAV.
• Risk Management , RMA , choć w istocie nie jest to moduł w rozumieniu wyżej wymienionych, a raczej zbiór funkcjonalności pod zbiorczą nazwą RMA realizowanych przez komponenty wykonane w ramach innych modułów, to jego rolą jest odbieranie za pośrednictwem szyny zewnętrznej informacji o poziomach ryzyka związanego z handlem poszczególnymi kategoriami instrumentów oraz zastosowanie ich przy kojarzeniu (matching).

Jak wskazano wyżej, architektura to nie tylko statyczny obraz modułów oraz komponentów połączonych szyną. Architektura musi również odzwierciedlać kinematykę, czyli jak wygląda współpraca odpowiednich modułów względem osi czasu, w celu realizacji jakiegoś podstawowego scenariusza funkcjonalnego na przykład handlu (trading), parametryzacji sesji i kilku innych zdefiniowanych dla platformy transakcyjnej. Na diagramie 6 pokazany jest głębszy (w porównaniu z tym na diagramie 5), poziom architektury wskazujący jak realizowany jest w czasie i przy pomocy jakich modułów czy komponentów scenariusz handlowania instrumentami.

Diagram 6 Wykonano przy pomocy Sparx Enterprise Architect.

Na diagramie 6 zielonymi kropkami wskazane są czynności (prostokąty żółte) scenariusza Trading, które realizują zadania składające się na proces dokonywania transakcji, w oparciu o działające konkretne komponenty platformy (prostokąty zielone).  Wszystkie zaznaczone zielonym kolorem komponenty pozwalają na dokonywanie transakcji. 

Rzadko spotykane cechy operacyjne nowej platformy

Rzadko spotykany zestaw cech platformy, który istotnie zwiększy jej potencjał sprzedażowy na światowych rynkach wydajnościowych składa się, jak wskazano wyżej: 

• z cech wydajnościowych, takich jak czas odpowiedzi (latency) platformy przy dużych obciążeniach (duża liczba komunikatów w systemie związana ze złożonymi zleceniami) – dla platformy transakcyjnej ustalono latencję na poziomie mniejszym niż 10 mikrosekund przy obciążeniu 100 tysiącami zleceń na sekundę,
• cech zapewniających wysoką dostępność (high availability).

Platforma transakcyjna jest tak zaprojektowana  i zrealizowana żeby umożliwiać handel instrumentami przy zapewnieniu wyżej wskazanych cech w sposób stabilny. Stabilność pracy platformy została zweryfikowana poprzez policzenie parametrów statystycznych takich jak mediana, wariancja, odchylenia standardowe, rozkłady statystyczne wyników testów, dla takich wielkości jak czas odpowiedzi (latency), w oparciu o wyniki testów prowadzonych na komunikatach krążących przez platformę transakcyjną (od modułu OEG, który przyjął zlecenie poprzez szynę do modułu CME i z powrotem poprzez szynę do modułu OEG a dodatkowo do modułu DDS, który wyrzuca informację publiczną do uczestników) . 

Warto podkreślić, że zgodnie z dobrymi praktykami międzynarodowych firm produkujących oprogramowanie, platforma nie działa jednolicie dobrze dla każdego scenariusza biznesowego. Koszt wytworzenia takiego rozwiązania, o ile w ogóle wytworzenie byłoby możliwe, byłby niewspółmiernie do potencjalnych zysków wysoki.  

W istocie zdefiniowano pewną przestrzeń składającą się z trzech wymiarów – patrz diagram 7. We wnętrzu tej przestrzeni zidentyfikowano obszary ograniczone hiperpowierzchniami, w których platforma działa stabilnie:

• w założonym reżimie wydajnościowym (10/100 tysięcy);
• poza założonym reżimem, ale nie gorzej niż w pasmie 10 %;
• poza założonym reżimem  poza pasmem wyznaczonym przez 10%.

.

Diagram 7 

Na Diagramie 7 wskazano trzy wymiary, które w wyniku przeprowadzonych prac badawczych uznano za konieczne i wystarczające do prezentacji trybów działania platformy transakcyjnej.  O ile wartości kluczowe dla dwóch wymiarów z diagramu 7 są jednoznacznie zaznaczone, o tyle w przypadku wymiaru „funkcjonalno-operacyjnego” tej jednoznaczności brakuje. Wyznaczające wartości tego wymiaru (duże litery) nawiązują do kombinacji 4 scenariuszy biznesowych i 2 scenariuszy operacyjnych zidentyfikowanych, jako zbiór pełny dla wytworzonej platformy transakcyjnej.

Wysoka dostępność została zapewniona przez odpowiednie rozwiązania architektoniczne pokazane na diagramie 8, gdzie zaznaczono dwie lokacje (site) kompleksu sprzętowego, sprzęgnięte szybkim łączem telekomunikacyjnym, na których działają odpowiednie moduły platformy transakcyjnej. Jedna lokacja jest główną, podczas gdy druga jest zapasową. Łącze pozwala z niewielkim opóźnieniem odtwarzać stan platformy z lokacji głównej na lokacji zapasowej. Możliwe są zatem dwa scenariusze pracy platformy transakcyjnej. Lepszy scenariusz polega na tym, że kompleksy sprzętowe na obu lokacjach przetwarzają de facto jednocześnie (active-active), a więc pad jednego z nich nie zmienia sytuacji, gdyż kompleks sprzętowy na drugiej lokacji działa dalej. Inny możliwy scenariusz polega na tym, że przetwarzania odbywają się na lokacji głównej, przetworzone dane są na bieżąco zapisywane w bazie danych na lokacji zapasowej. W chwili padu kompleksu na lokacji głównej, kompleks na lokacji zapasowej podejmie przetwarzanie. Oba scenariusze zapewniają wysoką dostępność platformy transakcyjnej.

Diagram 8 Wykonano przy pomocy Sparx Enterprise Architect.

Podsumowanie

Zaprojektowana w oparciu o twórcze rozwinięcia koncepcji architektonicznych, wytworzona zgodnie z terminem i budżetem platforma transakcyjna, w trybie stabilnej pracy i w reżimie niezwykle „wyśrubowanych” wymagań wydajnościowych, oferująca pożądane na światowych rynkach funkcjonalności (mulit-asset, multi-trading) pozytywnie zweryfikowała tezę, że możliwe jest zaprojektowanie i wytworzenie złożonego oprogramowania dla instytucji finansowej.

dr Piotr Kociński jest autorem artykułu pt.: „Platforma transakcyjna dla giełd”:

• pełni rolę Kierownika B+R w projekcie tworzenia nowej platformy transakcyjnej, jednocześnie pełniąc funkcję Digital & Emerging Technologies Chief Technology Officer for EY EMEIA (Europe, Middle East, India and Africa) w firmie E&Y,
• pracował dla Grupy LOTOS, pełniąc rolę członka zarządu spółki LOTOS Lab odpowiedzialnego za rozwój technologiczny i innowacje (w całej Grupie) oraz doradcy zarządu Grupy LOTOS ds. nowych zielonych technologii energetycznych,
• ma 20 lat doświadczenia w pracy dla takich firm jak IBM, Accenture, Teradata. W IBM pełnił kierownicze funkcje w dziale świadczenia usług wdrożeniowych i rozwojowych,
• pełnił rolę prezesa spółki spec znaczenia, Aplikacje Krytyczne (był jej współzałożycielem), stworzonej w celu zautomatyzowanej identyfikacji przestępstw związanych z podatkiem VAT,
• posiada doktorat z fizyki, uzyskany w Instytucie Fizyki PAN w Warszawie, jest autorem bądź współautorem kilku publikacji w renomowanych czasopismach naukowych, krajowych i zagranicznych,
• jest autorem kilku publikacji popularyzujących kwestie informatyczne i te związane z energetyką jądrową,
• zasiada w kilku radach m.in. w Radzie ds. Bezpieczeństwa Jądrowego i Ochrony Radiologicznej przy Polskiej Agencji Atomistyki.