Transcription
ETRM evolution and visionOslo, 24th October 20181
2The beginning; 1992- 2005Standard 3 tier, with extremely thick clients, little to no business logic in middleware, only persistence areTransaction DB2Price DBUpdatetoolMarket
3Problems;1992- 2005Standard 3 tier, with extremely thick clients, little to no business logic in middleware, only persistence layerScattered ewareTransaction DB3Price DBUpdatetoolMarket
4Problems;1992- 2005Standard 3 tier, with extremely thick clients, little to no business logic in middleware, only persistence layerScattered iC VB6Thin GuiThick duplicatedlogic layerDifferent languagesMiddlewareTransaction DB4Price DBUpdatetoolMarket
5Problems;1992- 2005Standard 3 tier, with extremely thick clients, little to no business logic in middleware, only persistence layerScattered iC VB6No central logicMiddlewareTransaction DB5Price DBThin GuiThick duplicatedlogic layerDifferent languagesUpdatetoolMarket
6Datawarehousing 2006-2007New report exporter to Central SQL DB ractmanagerDelphiC VB6No central logicMiddlewareTransaction DB6Price DBThin GuiThick duplicatedlogic layerDifferent languagesUpdatetoolMarket
7Curve server, pricing library 2008-2012DatawarehouseETRM front g LibraryCurve ServerC#.NetC#.NetMiddlewareTransaction DB7Thin GuiThick duplicatedlogic layerDifferent languagesPrice DBUpdatetoolMarket
8Migration and centralization 2013-2015DatawarehouseContractmanagerRisk reportsETRM front endC#.NetC#.NetRisk calculatorPricing LibraryCurve n DB8VB6Risk managerDatawarehouse is basedon decentralized clientcodeStill different languagesPrice DBUpdatetoolMarket
9Migration and centralization 2013-2015DatawarehouseDeal managerRisk reportsETRM front endC#.NetC#.NetC#.NetDelphiDeal managerRisk calculatorPricing LibraryCurve ServerC#.NetC#.NetC#.NetC#.NetTransaction DB9ContractmanagerRisk managerDatawarehouse is basedon decentralized clientcodeStill different languagesVB6MiddlewarePrice DBUpdatetoolMarket
10Reporting Database 2016-2018New DB based on centralized business logic in new tech stack.DatawarehouseStill different and soon tobe extinct languagesDeal managerRisk reportsETRM front endC#.NetC#.NetC#.Net10DelphiDeal managerRisk calculatorPricing LibraryCurve ServerC#.NetC#.NetC#.NetC#.NetReporting DBContractmanagerRisk managerTransaction DBVB6MiddlewarePrice DBUpdatetoolMarket
11Problem now.is that we need to get rid of Delphi and VB6 components and finish centralization.DatawarehouseStill different and soon tobe extinct languagesDeal managerRisk reportsETRM front endC#.NetC#.NetC#.Net11DelphiDeal managerRisk calculatorPricing LibraryCurve ServerC#.NetC#.NetC#.NetC#.NetReporting DBContractmanagerRisk managerTransaction DBVB6MiddlewarePrice DBUpdatetoolMarket
12VisionMoving the heavier Risk Calculations (VaR, PaR, SPAN) from client to server, and from Delphi to .NET will make it possible toexploit parallelization which is going to revolutionize performanceDatawarehouseStill different and soon tobe extinct languagesDeal managerRisk reportsETRM front endC#.NetC#.NetC#.NetDeal managerRisk calculatorC#.NetC#.NetReporting DB12ContractmanagerVB6VaR, PaR, SPANC#.NetPricing LibraryCurve ServerC#.NetC#.NetTransaction DBPrice DBMiddlewareUpdatetoolMarket
13VisionSystem configurations and position reporting and timeseries reportingMore intuitive UX, better configurabilityUniform centralized GUI. Web Based.Workflows engineSystem configDeal managerPositions reportsRisk reportsETRM front endC#.NetC#.NetC#.NetC#.NetC#.NetDeal managerTimeseries CalcRisk calculatorC#.NetC#.NetC#.NetReporting DB13VaR, PaR, SPANC#.NetPricing LibraryCurve ServerC#.NetC#.NetTransaction DBPrice DBMiddlewareUpdatetoolMarket
14VisionThin front end that can be deployed on multiple platforms ie web.Based on modern tech ready for the twentiesCloud native Parallelization will give a new level of performance for the complex Monte Carlo based risk analysis.Time to marketConfigurability that allows the user to set up their own markets and instrumentAll calculated values available in DB for custom reportingSystem configDeal managerPositions reportsRisk reportsETRM front endC#.NetC#.NetC#.NetC#.NetC#.NetDeal managerTimeseries CalcRisk calculatorC#.NetC#.NetC#.NetReporting DB14VaR, PaR, SPANC#.NetPricing LibraryCurve ServerC#.NetC#.NetTransaction DBPrice DBMiddlewareUpdatetoolMarket
15Microservice architecture?SOA with 1 giant service is clearly suboptimal. All users who are told to restart the service knows thisMicroservice would lead to hundreds of separate service doing only one thing, seems to be maximizing the cost.System configDeal managerPositions reportsRisk reportsETRM front endC#.NetC#.NetC#.NetC#.NetC#.NetDeal managerTimeseries CalcRisk calculatorC#.NetC#.NetC#.NetReporting DB15VaR, PaR, SPANC#.NetPricing LibraryCurve ServerC#.NetC#.NetTransaction DBPrice DBMiddlewareUpdatetoolMarket
16Miniservice ?I would expect that in the 8-12 range we will find the optimal number of independent services each being valuable.How to split up the service is one of the tasks for 2019.Good examples is the current RTR service, and Filewatcher ServiceSystem configDeal managerPositions reportsRisk reportsETRM front endC#.NetC#.NetC#.NetC#.NetC#.NetDeal managerTimeseries CalcRisk calculatorC#.NetC#.NetC#.NetReporting DB16VaR, PaR, SPANC#.NetPricing LibraryCurve ServerC#.NetC#.NetTransaction DBPrice DBUpdate toolMiddlewareMarket
Roadmap for 2019.117
Transaction DB Price DB ETRM front end C#.Net VaR, PaR, SPAN C#.Net Update tool Market Curve Server Middleware C#.Net Pricing Library C#.Net Risk calculator C#.Net Risk reports C#.Net Positions reports C#.Net Deal manager C#.Net Reporting DB I would expect that in the 8-12 range we will find the optimal number of independent services each being .
