the problem domain
play

The Problem Domain Story: As a Investment Bank, we need meet all - PowerPoint PPT Presentation

The Problem Domain Story: As a Investment Bank, we need meet all BCBS239 and associated regulations, in order to avoid any financial, reputational or operational issues. Business Requirements: Bring data used in Risk under governance


  1. The Problem Domain Story: As a Investment Bank, we need meet all BCBS239 and associated regulations, in order to avoid any financial, reputational or operational issues. Business Requirements: • Bring data used in Risk under governance (ownership, quality, description) • Governance of technical, functional and semantic data layers • Framework for maintaining data under governance Solutions Considered: • On-the-fly database queries on existing data models (Very Bad) • Internal bespoke build of a “graph-lite” database (Bad) • Implementation of Neo4J Graph Database (Good) Evaluation Criteria : • Easy of use - query writing, feature adaptability • Performance - query performance and scalability • Extensibility - time to market to model additional levels / attributes • Infrastructure, Development and Maintenance and BAU Cost

  2. Example 1 – Which Files to Load? Story: As a Feed Manager, I need to a list of files that are used to load the positions for a given Risk Node, so I can feed this subset into the system. MATCH (n:RiskNode)<-[r*1..10]-(m) WHERE n.name='EXAMPLE' RETURN * This is the starting node (EXAMPLE) for our query, This represents the it produces 489 nodes “candidate” list of files with 634 edges for a very needed to load the small set of portfolios. node. How to get Cypher to “stop” at a terminus node? How to get all the endpoints, regardless of how many steps away?

  3. Example 2 – Work Minimisation Story: As a Developer, I need to get data out of the graph in the most usable form possible, so that the UI does the minimum amount of business logic. Enterprise Limitations: • Adding Java Applets to a centrally managed service – challenging • Need to partition data for security and temporality Scale: • When node populations get large, need to shift the workload to the server, e.g: • Auto aggregate relationships or nodes together automagically? • Dynamically create subsets of data and then join them (akin to temp tables?) Skills: • Need to “simplify” for a range of skills in a large organisation • Cypher stored procs or views (not compiled!) for reusable queries • More sophisticated UI for writing and testing queries

Recommend


More recommend