Architectures for Disparate Derivative Trading and Settlement

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

• Introductions
• Business drivers affecting derivative trading
• Challenges faced by IT
• Service orientated architecture
• Case studies
• Summary Questions

3
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

4
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

5
The business drivers
6
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

7
Business Drivers

• Derivative business lines
• FX and Money derivatives
• Credit Derivatives
• OTC Derivatives
• Spread betting
• Commodities
• Energy
• Weather.

8
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

9
Demands on systems

• Demands of IT
• Planning
• Budget
• Resourcing
• Shared knowledge
• Infrastructure
• Need for control
• Supportability
• Centralisation

• Demands of traders
• Time to market
• Profit window
• Uncertain Revenues
• Need for secrecy

10
Business Drivers The Problem

• The problem is either

• Or
• STATE CONTROLLED CENTRALISATION

Baronial Anarchy
11
Business Drivers The Problem

• The best of each world is

• Or
• STATE CONTROLLED CENTRALISATION

Baronial Anarchy

• 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

12
Service Orientated Architecture
13
The Balancing Act
Dynamic
Strategic
Predictable
Tactical
Standards
Large Scale
Flex
Small Scale
Delicate balancing. One size does not fit all.
14
Key Design Principles
Complex Trade Offs...
15
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...
16
Messaging and Services
Reporting
Exposure
Plain Text (XML) Message Bus
Pricing
Deal Entry
Leverage mature message based architectures...
17
Messaging Options

• Bus or Hub/Spoke.
• Federated.
• Point-to-point or Publish Subscribe.
• Asynchronous or Request/Response.
• Variable QoS.

... or combinations and variations of ...
18
Transaction Options
Process Database Update
Publish Message or Request
Process Database Update
Receive Message or Request
Publish Message or Response
19
Other Considerations

• Security
• Control Costs With Threat Model
• Authentication
• Integrity
• Privacy
• Business Continuity
• Availability
• Disaster Recovery

20
Ontologies
Define globally, adapt locally
21
Reference Architecture
Application Services
Deployment Services
Persistence
Security
Load Balancing
Clustering
Data Access
API
Administration
Deployment
Audit/History
Caching
Process Automation
Recovery
Fail Over
Workflow
Rules Engine
Reference Data
Integration
Meta Data
Master Data
Transformation
Translation
Monitoring
Messaging
Routing
Event Bus
Monitoring
The Enterprise Service Bus makes much of this
available
22
Case Study Energy Trading Scheduling System

• Paper Deals
• Options, Futures, ....
• Physical Deals
• Scheduling
• Contract Generation
• Many Legacy Systems

23
Case Study System Evolution
VMS ProIV
Back Office
24
Inextricably Entwined
Architecture Technology
Method Process
Process and Architecture entwined and generative
25
21st Century Development
XP
DSDM
RUP
FDD
Waterfall
SCRUM
Crystal
TSP
Iterative
JAD
Spiral

• There is no grand narrative.
• Right people, right process, right time.
• Method-per-project with agile philosophy.

Method to fit goals
26
Industrial Strength Agility
Tailor
Finding Best Fit
Execute

Measure
Deliver
Adapt
Completion
Commitment
Iterative, adaptive, embracing change.
27
Case Study BalanceAgility 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.

28
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.
29
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
30
Case Study Automate, automate...
Test Phase Tool Support Check-In Build Cruise Control Nightly End of iteration test. Responsible
Unit Tests xUnit Robot Dev
Link Tests xUnit Robot Dev
Tech Tests Load Runner Dev/Tech Test
System Tests Robot People Test Team
Integration tests xUnit Robot People Test Team
Continual integration and test build quality
31
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...
32
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
33
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
34
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
35
Summary Questions
36
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!

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