Architectures for Disparate Derivative Trading and Settlement Paul Pickup Strategic IT Consultant...

Architectures for Disparate Derivative Trading and Settlement

Paul PickupStrategic IT ConsultantTrading Technology

www.tradingtechnology.com

Andy SchneiderBJSS

www.bjss.co.uk

© Catalyst Development Ltd 2002

AGENDA

• Introductions• Business drivers affecting

derivative trading• Challenges faced by IT• Service orientated

architecture• Case studies• Summary & Questions


Trading Technology

• 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



BJSS Ltd.

• 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

www.BJSS.com


The business driversThe business drivers


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


Business Drivers

• Derivative business lines

FX and Money derivatives Credit Derivatives OTC Derivatives Spread betting Commodities Energy Weather….


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


Demands on systems

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

• Demands of ITo Planningo Budgeto Resourcingo Shared knowledgeo Infrastructureo Need for controlo Supportabilityo Centralisation


Business Drivers – The Problem

The problem is either: Or:

STATE CONTROLLED STATE CONTROLLED CENTRALISATIONCENTRALISATION


Business Drivers – The Problem

The best of each world is: Or:

STATE CONTROLLED STATE CONTROLLED CENTRALISATIONCENTRALISATION

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


Service Orientated Service Orientated ArchitectureArchitecture


Delicate balancing. One size does not fit all.

Predictable

Dynamic

Tactical

Strategic

Flex

Standards

Small Scale

Large Scale

The Balancing Act


Key Design Principles

Complex Trade Offs...

Cost Of Entry

Enable Buy& Build

Scaleable

SupportDiversity

Zero LatencyB2B Ready

LinearCost

Incremental

Availability

Business ProcessSupport


Service Orientated Architecture

•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...

...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]


Messaging and Services

DealEntry

Pricing

ReportingExposure

Plain Text (XML) Message Bus

Leverage mature message based architectures...

WorkflowTransformation

SequencingHuman

Intervention

Core Component APIReference Data Repository

ReferenceData


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

Messaging Options

... or combinations and variations of ...


Transaction

Transaction

Transaction Options

Transaction

Transaction Transaction

Transaction

Transaction

Transaction

Process & Database

Update

Publish Message or

Request

Process & Database

Update

Receive Message or

Request

PublishMessage orResponse


Other Considerations

•SecurityControl Costs With Threat ModelAuthenticationIntegrityPrivacy

•Business ContinuityAvailabilityDisaster Recovery


Ontologies

Top Level

Business UnitCore Java Apps

SAP Instance

Communication Medium

Communication Medium

Com

mu

nica

t ion

M

ed

ium

Com

mu

nic a

t ion

M

ed

ium

Define globally, adapt locally


Reference Architecture

Process Automation

Workflow Rules Engine

Application Services

Persistence Security

Data Access API

Deployment Services

Load Balancing Clustering

Deployment Administration

Integration

TransformationTranslation

Messaging Routing

Recovery Fail Over

Reference Data

Meta Data Master Data

Monitoring

Event Bus Monitoring

Audit/History Caching

The Enterprise Service Bus makes much of this available…


Case Study: Energy Trading & Scheduling System

•Paper DealsOptions, Futures, ....

•Physical DealsScheduling

•Contract Generation•Many Legacy Systems


XML on TIBCO Certified Messaging

Scheduling

SolarisJ2EE

ORACLE

VMSProIV

Back Office

Case Study: System Evolution

Win2kCOTS

SQLServer

Contracts

ExcelVBA

Reference Data Mappings in

Transformation Engine

Core Component API

Reference Data Repository

ReferenceData

SolarisJ2EE

WorkflowTransformation

SequencingHuman

Intervention SolarisTIBCO IM

ORACLE

DealEntry

SolarisJ2EE

TransactionBoundary


Inextricably Entwined

ArchitectureTechnology

MethodProcess

Process and Architecture: entwined and generative


21st Century Development

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

DSDM XP

SCRUM

RUPWaterfall

Iterative Spiral

Crystal

JAD

FDD

TSP

Method to fit goals


Industrial Strength Agility

Iterative, adaptive, embracing change.

Execute

Measure

Adapt

Deliver

TailorFinding Best Fit

CompletionCommitment

Project & ProgrammeGovernance}


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.


Case Study: Multi-Disciplinary Teams

•Smooth resource usage. •Optimise for information flow.•Small, efficient feedback loops.

FunctionalDelivery

People are key, have first order effect.

Analysis

Team A

Development

Test

Best PracticesStandards

QualityMonitoring


To Test - CST(Defects in state of 'Fixed' or 'RFT'

0

50

100

150

200

21Feb03

5Mar03

17Mar03

23Mar03

2Apr03

9Apr03

23Apr03

6May03

16May03

29May03

10Jun03

20Jun03

2Jul03

14Jul03

24Jul03

5Aug03

15Aug03

27Aug03

8Sep03

18Sep03

30Sep03

10Oct03

Date

Nu

mb

er o

f D

efec

ts

1.Critical

2.Severe

3.Important

4.Minor

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


Case Study: Automate, automate...

Test Phase

Tool Support

Check-In Build

Cruise Control

NightlyEnd of iteration

test.Responsible

Unit TestsxUnitRobot

Dev

Link TestsxUnitRobot

Dev

Tech Tests

Load Runner

Dev/Tech Test

System Tests

Robot People

Test Team

Integration tests

xUnitRobotPeople

Test Team

Continual integration and test build quality


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...


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


Case Study: Governance on top

Agile Underneath

Appraise Select Define Execute Operate

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Deployment

Config & Change Management

Project Management

Environment


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


Summary & QuestionsSummary & Questions


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!

QuestionsPaul Pickup

Strategic IT ConsultantTrading Technology


Andy SchneiderBJSS

www.bjss.co.uk

Date post:	29-Mar-2015
Category:	Documents
Upload:	devan-beals
View:	213 times
Download:	0 times

Architectures for Disparate Derivative Trading and Settlement Paul Pickup Strategic IT Consultant...

Documents