Architectures for Disparate Derivative Trading and Settlement Paul

Architectures for Disparate Derivative Trading and Settlement Paul Pickup Strategic IT Consultant Trading Technology www. tradingtechnology. com Andy Schneider BJSS www. bjss. co. uk

AGENDA • Introductions • Business drivers affecting derivative trading • Challenges faced by IT • Service orientated architecture • Case studies • Summary & Questions © Catalyst Development Ltd 2002

Trading Technology www. tradingtechnology. com • Note – Not Trading Technologies!!! • Specialists in Trading Systems • Consultancy, not development ° People are the challenge, not the technology • Business analysis • Program and Project Management • IT Marketing and Research © Catalyst Development Ltd 2002

BJSS Ltd. www. BJSS. com • The highest quality software engineers • Bespoke development only • Financial services – especially trading environments • Messaging and high-availability transactional environments • Significant clients including the London Stock Exchange, LIFFE, CREST, Reuters, BP © Catalyst Development Ltd 2002

The business drivers © Catalyst Development Ltd 2002

Business Drivers • Recent survey of Stock Exchange Technology • Through FOW • Conclusions ° “cash” trading high-volume low value ° “Traders Market” ° Expansion into derivative ° instruments ° IP-based technology enabler © Catalyst Development Ltd 2002

Business Drivers • Derivative business lines ° ° ° ° FX and Money derivatives Credit Derivatives OTC Derivatives Spread betting Commodities Energy Weather…. © Catalyst Development Ltd 2002

Demands on systems • Derivative traders are only as good as their IT! • Programmer/Mathematician/ Derivative trader hybrid • Many small-point systems • Developed by traders ° Excel ° Access ° Visual Basic © Catalyst Development Ltd 2002

Demands on systems • Demands of traders ° ° Time to market Profit window Uncertain Revenues Need for secrecy • Demands of IT o Planning o Budget o Resourcing o Shared knowledge o Infrastructure o Need for control o Supportability o Centralisation © Catalyst Development Ltd 2002

Business Drivers – The Problem The problem is either: Or: STATE CONTROLLED CENTRALISATION © Catalyst Development Ltd 2002

Business Drivers – The Problem The best of each world is: Or: STATE CONTROLLED CENTRALISATION ü Flexibility ü Speed of development ü Low cost ü RAD approach ü Disposable systems? ü Ability to plan ü Clear agreed requirements ü Budgets ü Maintainability ü Supportability ü Fits in with other systems ü Common development techniques © Catalyst Development Ltd 2002

Service Orientated Architecture © Catalyst Development Ltd 2002

The Balancing Act Dynamic Strategic Predictable Tactical Standards Flex Large Scale Small Scale Delicate balancing. One size does not fit all. © Catalyst Development Ltd 2002

Key Design Principles Enable Buy & Build Business Process Support Cost Of Entry Scaleable Incremental B 2 B Ready Zero Latency Availability Support Diversity Linear Cost Complex Trade Offs. . . © Catalyst Development Ltd 2002

Service Orientated Architecture. . . SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls. . . [Natis, Gartner 2003] • Abstract Interfaces to Business Processes. • Leverage Existing Systems. • Ease integration of large systems (e. g. SAP). • Heterogeneous environments. • XML, simple protocols. • SOA is not web services, SOA is a design philosophy. Services are not just Web Services. . . © Catalyst Development Ltd 2002

Messaging and Services Reference Data Repository Core Component API Exposure Reporting Reference Data Plain Text (XML) Message Bus Deal Entry Pricing Workflow Transformation Sequencing Human Intervention Leverage mature message based architectures. . . © Catalyst Development Ltd 2002

Messaging Options • Bus or Hub/Spoke. • Federated. • Point-to-point or Publish & Subscribe. • Asynchronous or Request/Response. • Variable Qo. S. . or combinations and variations of. . . © Catalyst Development Ltd 2002

Transaction Options Transaction Process & Database Update Publish Message or Request Transaction Receive Message or Request Process & Database Update Publish Message or Response Transaction © Catalyst Development Ltd 2002

Other Considerations • Security °Control Costs With Threat Model °Authentication °Integrity °Privacy • Business Continuity °Availability °Disaster Recovery © Catalyst Development Ltd 2002

Ontologies Top Level SAP Instance Communication Medium Business Unit Core Java Apps Define globally, adapt locally © Catalyst Development Ltd 2002

Reference Architecture Application Services Persistence Security Data Access Caching Load Balancing Clustering Deployment Administration API Audit/History Deployment Services Process Automation Workflow Rules Engine Integration Transformation Translation Messaging Routing Recovery Fail Over Reference Data Meta Data Master Data Monitoring Event Bus Monitoring The Enterprise Service Bus makes much of this available… © Catalyst Development Ltd 2002

Case Study: Energy Trading & Scheduling System • Paper Deals °Options, Futures, . . • Physical Deals °Scheduling • Contract Generation • Many Legacy Systems © Catalyst Development Ltd 2002

Case Study: System Evolution Reference Data Repository Reference Data Mappings in Transformation Engine Core Component API Back Office Win 2 k COTS VMS Pro. IV SQL Server Solaris J 2 EE Contracts Reference Data XML on TIBCO Certified Messaging Solaris J 2 EE Deal Entry Scheduling Transaction Boundary ORACLE Workflow Transformation Sequencing Human Intervention Excel VBA Solaris TIBCO IM ORACLE © Catalyst Development Ltd 2002

Inextricably Entwined Architecture Technology Method Process and Architecture: entwined and generative © Catalyst Development Ltd 2002

21 st Century Development XP DSDM TSP FDD SCRUM Crystal Iterative JAD RUP Waterfall Spiral • There is no grand narrative. • Right people, right process, right time. • Method-per-project with agile philosophy. Method to fit goals © Catalyst Development Ltd 2002

Industrial Strength Agility Tailor Finding Best Fit Execute Measure Deliver } Project & Programme Governance Adapt Completion Commitment Iterative, adaptive, embracing change. © Catalyst Development Ltd 2002

Case Study: Balance Agility and Governance • Before: ° Large multi-national. ° Waterfall style governance. ° Chaotic, disconnected development. • After, process aimed at: ° Optimising test and quality. ° Improve transparency control. ° Improve fit with governance. © Catalyst Development Ltd 2002

Case Study: Multi-Disciplinary Teams Team A Analysis Best Practices Standards Quality Monitoring Development Functional Delivery Test • Smooth resource usage. • Optimise for information flow. • Small, efficient feedback loops. People are key, have first order effect. © Catalyst Development Ltd 2002

Case Study: Transparency • Daily Defects - component based. • Defect State of Nation. ° Graphs to programme team and on wall. ° Monitored trends to ensure closure. • Progress ° Planned, actuals EVA, variance and velocity. • Agreed iteration exit criteria. Transparency = Trust, Benchmarking, Clear Progress © Catalyst Development Ltd 2002

Case Study: Automate, automate. . . Test Phase Tool Support Check-In Build Cruise Control Unit Tests x. Unit Robot Dev Link Tests x. Unit Robot Dev Tech Tests Load Runner Dev/Tech Test System Tests Robot People Test Team Integration tests x. Unit Robot People Test Team Nightly End of iteration test. Responsible Continual integration and test build quality © Catalyst Development Ltd 2002

Case Study: Necessary & Sufficient • Design and Analysis is both an activity and communication. • Documentation is not an end in itself. • Focus on: °Necessary: Has a clear purpose. °Sufficient: Good enough for the purpose. Right level of detail. Necessary and sufficient - minimum needed. . . © Catalyst Development Ltd 2002

Case Study: Adapt • Iteration reviews. • Project Teams are Self Optimising. • Holistic Analysis Entire process chain. • Adapt to functional change. • Multi skilled teams maximise flexibility. Improved Throughput with Skilled Self Optimising Teams © Catalyst Development Ltd 2002

Case Study: Governance on top Appraise Select Define Execute Operate Business Modeling Requirements Analysis & Design Implementation Test Deployment Config & Change Management Project Management Environment Agile Underneath © Catalyst Development Ltd 2002

The Death Of Technology Led Solutions • SOA and Enterprise strength agile - Business Orientated. • No longer technology orientated. • Heterogenous methods and systems enabling each other. • Incremental, Scaleable, Manageable. • Team Orientated. Links and resources: http: //www. bjss. co. uk/fow © Catalyst Development Ltd 2002

Summary & Questions © Catalyst Development Ltd 2002

Summary • Derivatives increasingly important and profitable • Increasingly disparate • Business needs force flexibility • Balance between federal and centralized control • Requires common development methods • Needs strong accreditation throughout the organization • Part of your core competence • Not to be outsourced! © Catalyst Development Ltd 2002

Questions Paul Pickup Strategic IT Consultant Trading Technology www. tradingtechnology. com Andy Schneider BJSS www. bjss. co. uk