Murex IT-platformen

Dit artikel is geschreven voor infra delivery managers, beheerders en project managers die te maken krijgen met de IT Infrastructuur voor een Murex implementatie. Murex is marktleider van financiële software in de handel van aandelen, obligaties, grondstoffen, valuta’s en overige producten. Het pakket Murex is in feite een groot financieel datawarehouse waarmee tijdens beursuren handel wordt gedreven en na sluiting van de beurs rapportages en analyses worden gegenereerd. Murex is bij veel financiële instellingen een geïntegreerd ‘front-to-back-to-risk’ platform. In Nederland wordt het onder andere gebruikt door ABNAMRO en de ING-bank.

Functioneel gezien is Murex een bouwpakket van verschillende modules met verschillende functionaliteiten. Om Murex te implementeren binnen een financiële organisatie moet er veel gebeuren. Daarom werkt Murex met grote, gespecialiseerde en gecertificeerde partners, die de betreffende klant moet inhuren om het pakket op maat te maken en te laten interfacen met de omgeving. Zij focussen zich vaak volledig op de applicatie en de integratie met andere systemen en missen vaak de noodzakelijke kennis van de onderliggende infrastructuur. Een korte inleiding in deze boeiende materie.

Technisch gezien is Murex een client-server applicatie die gebruikt maakt van een aantal relationele databases om informatie in op te slaan. Je mag Murex zien als een legacy systeem (daar kom ik op terug) met een paar opvallende kenmerken en eigenschappen. Een paar opvallende kenmerken van MX.3, de huidige versie van Murex:  

  • De Murex MX.3 binary is geschreven in C++, tegenwoordig 64-bits, oudere versies (tot 2016) 32-bits 

  • De Murex MX.3 binary is gecompileerd op Solaris en RedHat Linux. Murex is geschikt voor Microsoft Azure en Amazone Web Services vanaf Murex MX.3.1.35+ en RedHat Linux RHEL 7.2+

  • Murex MX.3 gebruikt 64-bits Java voor de client-servers sessies

  • Murex MX.3 ondersteunt uitsluitend Sybase of Oracle als database engine. De in 2016 aangekondigde ondersteuning van Microsoft SQL Server 2016 op Azure is nog steeds niet beschikbaar

  • Murex MX.3 maakt geen gebruik van slimme database specifieke functionaliteit. Daardoor moeten alle berekeningen uitgevoerd worden door de applicatie zelf of door middel van een extern rekengrid

  • Tools voor archiving, purging, onderhoud en monitoring moet de klant zelf laten ontwikkelen en implementeren 

Een Murex implementatie kan een zwaar wissel trekken op de infrastructuur. Zo worden er iedere nacht, tijdens de End Of Day run, miljoenen cellen ‘kladpapier’ in een van de databases aangemaakt. Murex pompt vervolgens tussenresultaten van berekeningen op en neer tussen de applicatie en de Oracle database met een piek-load op de SAN-storage van meer dan 900.000 IOPS. Aan het eind van de EOD wordt dit ‘kladpapier’ gewist. Hierdoor is het bijvoorbeeld voor Oracle onmogelijk een optimale index op die data los te laten. In die zin is Murex een old-school applicatie, de applicatie maakt geen gebruik van slimme features in moderne databases.

Zonder goede archiving en purging procedures en tools wordt een Murex database al snel erg groot. Meerdere terabytes. Dit stelt hoge eisen aan de capaciteit en de performance maar ook aan de back-up voorzieningen. En voor de Murex consultants: een ‘logical’ purge blijft de database fysiek groot houden omdat alleen dat vinkje voor een veld niet bijdraagt tot het kleiner worden van de database. 

Een vak apart is het inrichten van de Murex DTAP-straat. Een afslag maken van productiedatabases van enkele terabytes elk, kost nu eenmaal tijd en ruimte. Het refreshen van de DTAP omgevingen daardoor ook. En aan al die afslag-momenten hangen eisen en voorwaarden qua tijd en beschikbaarheid. De Risk afdeling wil bij aanvang werktijd een afslag hebben om checks en verificaties te kunnen doen, het run-team wil zo mogelijk eerder een afslag hebben om kleine delen opnieuw te draaien, te controleren of om er patches op los te laten.

Kortom, het opzetten en runnen van een Front-To-Back-To-Risk Murex systeem vraagt het een en ander van de organisatie en de infrastructuur. Sinds 2009 heeft Reforge gewerkt aan de opzet en implementatie van aantal Murex systemen en binary implementaties en in 2014-2015 hebben wij de Green Field ontworpen en gebouwd bij en voor ABNAMRO (Xerum-programma). Daarnaast waren wij wereldwijd de eerste die Proof of Concepts hebben gedaan met Murex op Linux en op Oracle Exadata systemen. 

Reforge is beschikbaar voor de volgende rollen: Subject Matter Expert / Infra Consultant / IT Delivery Manager bij Murex implementaties en transities. Ook voor Second Opinions.