The document discusses designing a trading platform to be more extensible and evolve to support new asset classes. It recommends: 1) Representing data with XML to standardize structure and allow new attributes; 2) Implementing a service-oriented architecture with loose coupling between independently developed components; 3) Using a messaging system to facilitate communication instead of direct connections between components.

1. Reliable
Extensible
Engineering Maintainable
Solutions
Scalable
Raman Kannan
rk2153 AT gmail DOT com Design and Analysis 1

2. Design
• It is a creative process
• There is no best design – wicked science
• Important lessons learned
– Architecture is the key for operational stability
– Capturing the design intent is key – corporate
memory
– Building the right product is key for alignment
• Building “some product” right is irrelevant
– Simplicity always triumphs over complexity
rk2153 AT gmail DOT com Design and Analysis 2

3. Delay concrete decisions
• Abstract – Architecture
– Parts and their relationships
– Their interactions with the environment
(outside view)
• Refine, elaborate independent parts
• Design for abstract interaction
– Substitutionality principle -- Liskov
– Reduce rigid coupling between systems
rk2153 AT gmail DOT com Design and Analysis 3

4. Evolving an Equity Trading
Platform to other asset classes
rk2153 AT gmail DOT com Design and Analysis 4

5. Trading Platform
http://assetcorporation.net/existing/trading_platform.html
Implementing business functions independently and integrating
them fosters engineering efficiency and software reuse.
Allows component wise replacement and incremental
improvements.
rk2153 AT gmail DOT com Design and Analysis 5

6. Design for Change!
• 1996/1997 predates SOA or JBOSS or SOAP
• Should this system be migrated to newer
frameworks?
– The current solution is factored well but
– Lack of centralized approach results in duplication
» Stop/start, error/status monitor, logging, concurrency,
recovery, component administration, resource pooling
– Each component interacts with DB directly
» Structure of data is not standardized
» Duplication and multiple database connections
– Not easy to combine/replace existing
» introduce new (Position, Risk, Revenue,Breaks)
» or external services (EMS, ALGO service, etc)
SOA can offer relief.
rk2153 AT gmail DOT com Design and Analysis 6

7. New Platform
• Get rid of application specific data structures
– XML based Order, Trade, Position,Task, Confirms, Reports,
Permissions, SecurityTypes
– Platform NOW is a collection of
• XML generators(sources) and processors(sinks)
• Asset classes can be introduced
– Each with their own events, analytics and lifecycles
– Introducing SWAP novation need not and will not affect unrelated
• New attributes may be added (taker/provider rebate for trade)
• Persistent Store can be a special processor
– All other components are db independent
– DB can be replaced as needed
• Sources and Sink may transform using XSL
Platform is now data centric and SOAP/XML is ideal.
rk2153 AT gmail DOT com Design and Analysis 7

8. Implementation aka Observable
• Choose a bus architecture for IPC publishers
– avoid direct communication
– Pick a messaging toolkit (cots or pd)
• Implement service management
– Service definition language (WSDL)
postEvent
– Service Catalog – dynamic
– Discovery and routing services
• Processing Standard EventDistribution
– Choose Stateless protocol notifyEvent
– Data transformation services (DTS)
• Ship an Order DOM return OATS
DOM
• Receiver should make it right using
DTS
– Avoid data coupling Subscribers
Subscribers
aka Observers
rk2153 AT gmail DOT com Design and Analysis 8

9. Plausible State
Blotters Analytic MarketData
SvcCatalog Blotters Engines MiscSvc
XML XML XML XML
JBOSS/ESPER/JMS/XML ESB/Mule
XML XML XML XML
XML2SQL XML2FIX TrdSupport Portals
SQL
ExtSvcGwy Performance Compliance
ExtSvcGwy
Algo/Programs Customers
DB Farm
rk2153 AT gmail DOT com Design and Analysis 9

10. Steps
• Determine XML Schema
• Persistence Process
• Service Definition, Discovery, Routing
• Transformation Services
• Monitoring and Instrumentation
• Error Recovery
• Stress test for performance, throughput
The initial state was already factored to evolve the design.
rk2153 AT gmail DOT com Design and Analysis 10

11. Extensible
Blotter Server/OMS Execution Venue Fix Customers
Risk Management
Customer Svc
Position Management
Reporting
Portfolio Trading Support System
Decision Smart Router
Support
Firm DB Matching Engine
MDF Algos
Tick db
Perf Trackers
Transaction db
Liquidity Detection
History/ SecMaster
rk2153 AT gmail DOT com Design and Analysis 11

12. What if?
• Applications are in use
– Factor reusable methods and abstractions
• Capture all the flows
• Compile Data Dictionary
• Define XML to capture all the data, given DD
– Select one application
• Recast using the SOA framework, DD and XML Schema
• Test and validate for performance
• Introduce other applications one by one
• When satisfactory – retire old system
• Requires an ops team and engineering team
rk2153 AT gmail DOT com Design and Analysis 12

13. Factoring Application Suite
• Select one assetclass
– Categorize all the required business functions
– Define generic application interface
• nav(runDate)
• var(runDate,varPolicy)
• update(old,current)
• evolve(from,to)
– Define a comprehensive application framework
– Define concrete implementing the application interface
– Register concrete with the application framework
– Test for all the business functions
• Implement other applications and repeat
– Architecture will evolve iteratively
rk2153 AT gmail DOT com Design and Analysis 13

14. Abstraction Levels
Highest ROI
Interaction between Services
Services Runtime management
Service level error recovery
Platform independent
Components Unlimited extent
Framework
Interaction between classes
Limited extent
Patterns
Classes
Compilation/Library Deployment
Programming Error Management
Data Structures + Libraries Restricted extent (colocated libraries)
Layering fosters engineering discipline and prevents hacking and kludges.
rk2153 AT gmail DOT com Design and Analysis 14

15. What follows
• Separation of concerns
– Illustration
• Solving Complex Problems
– Divide and conquer
– Reuse at the highest level
• Generalize to capture abstract patterns
– Usable in similar contexts
rk2153 AT gmail DOT com Design and Analysis 15

16. Innovation through Integration
http://bluehawk.monmouth.edu/monmouth/academic/dna/webnet97.htm
http://bluehawk.monmouth.edu/monmouth/academic/dna/fed97.htm
rk2153 AT gmail DOT com Design and Analysis 16

17. Higher levels of abstraction
See hidden patterns
Strip problem specific roles
See the parts at a higher level
A solution to a particular problem
Can now solve larger set of problems
Recipe:
Solve the problem
Study the solution
Refine by
making your design more abstract
Streamlining communication paths
Ordering and restricting (layering)
Any unsolvable problem can be solved at a different level of abstraction
Andrew Konig – Solve by indirection.
Einstein – A problem cannot be solved with the mindset that created the problem.
Different mindset, open mindset, higher level issues, defer details as much
rk2153 AT gmail DOT com Design and Analysis 17

18. Design Intent
• Capturing design intent in a durable medium is
important
• Engineered buildings have buckled, when
– Purchasing manager saved a few $$$ buying smaller
beams and soldering them to make a big beam
– While the engineer designed it with a single long
beam to distribute the load evenly across
– No short cuts – pay up and do it right
– When in doubt -- ask for the design rationale
• Make no assumptions
Don’t run on assumptions – review, check and confirm – frequently
learn from mistakes and experts – don’t repeat
rk2153 AT gmail DOT com Design and Analysis 18

19. Reduce Still Further
A General Purpose Problem Solving Method.
http://bluehawk.monmouth.edu/monmouth/academic/dna/weti96ff.htm
rk2153 AT gmail DOT com Design and Analysis 19

20. • Pondering the internals, an example
• classical design methods are relevant
– OOAD
– Data centric
rk2153 AT gmail DOT com Design and Analysis 20

21. Simple Exercise:Class Design
Assume you wish to build forms to collect information from users
and store them in a relational database.
One can decide to a build A form – one at a time
Or you can solve the form building in total – for a wide variety of forms.
There is a trade off here…if all we wanted to do is build ONE form..just do it.
However, if there are an unknown number forms and subject to frequent changes
then solving for a form is inefficient.
Ask what if questions:
what if I can build one form, such that it will aid in the creation of all other forms
-- resulted in widget libraries
But widget libraries do not become forms overnight…someone has to identify the
widget that most suitable for eliciting that piece of information and
Position those widgets in a logical manner to make up the form
rk2153 AT gmail DOT com Design and Analysis 21

22. Recast the problem statement
a FORM is an ordered collection of suitable display widget,
positioned on the form at particular location within the
form.(a model – description of )
Note there is no mention of Name, Age, Color – abstract
not particular
Given the chosen widgets and their positions on the form, a
FORM can be painted on the screen.(a generator)
Separation of concerns – description of the form separated
from rendering the form on a screen
rk2153 AT gmail DOT com Design and Analysis 22

23. Divide & Conquer
There are forms (container) and there are fields (contained).
Form Universe
Maker Application Maker Operations (CRUD) Window
Checker Application Checker operations (accept/reject) Window
Browser Application Browser Operations (view only) Window
Some forms allow users to create/read/update/delete data. (maker)
Some forms allow users to verify (and accept) captured data. (checker)
Some forms allow users to view data without the ability to modify. (Browser)
A form at runtime is rendered in its own window.
rk2153 AT gmail DOT com Design and Analysis 23

24. Analysis by refinement:Content Universe
• What is a form
– Labels, aka names
• constant values hint about the values to expected
– Values, aka entryfield
• User enters a value from an infinite set of values
– Free form
– Some may be numbers only, text, or combination
• User selects from a finite set of values
– One of two values – special case
– One of a dozen values
• User selects from a growing list of values
– Related to a value already entered in the same form or another
form
– Position and order of these labels/values
A form = one or more (labels, entryfields, position and order)
rk2153 AT gmail DOT com Design and Analysis 24

25. What all can the user enter?
Item Domain Description Comment
UserEntered TextEntry validate for alphabets, textField Name
UserEntered Numerals validate for numbers only, textField Age, Salary
UserEntered Masked private not visible, textField password
UserEntered AnyEntry Any alphabet or any number, textField Freeform
Prose TextBox Text with option to enter a file Freeform or a FileBrowser
Boolean one of two values Close Domain RadioButton Gender
Images,videos DialogBox To enter URL or select a file FileBrowser
Shape,FamilyRelationship (mother/father, son,
StaticList categories Closed Domain PopupMenu daughter)
Customer Name (Open grows with time), Departments
DynamicList categories Closed or Open Domain PopupMenu closed
Closed – Cannot make up a new country
Referential RestrictedCategories like in the case of customer name Countries, Currencies
The original solution in 1992 did not include Prose/Image or videos.
There were no URLS then.
By adding new renderers and allowing more Item types, entire framework could
be used without much effort. Solutions can evolve if engineered.
rk2153 AT gmail DOT com Design and Analysis 25

26. Analysis to Design
• So far in the analysis we have identified
only the what not how…
• In the design phase how will these come
together (collaborate and coordinate)
• In the design phase ideas foreign to the
domain have to be introduced ( interpretor,
repository, libraries)
Object Oriented approach maintains the continuity from requirement to solution.
rk2153 AT gmail DOT com Design and Analysis 26

27. It aint easy!
Design for change, think long,
think hard.
We need:
A repository
An interpretor
A widget class library
A database library (two tier) or
gateway (three tier)
System Services –
authentication, process etc
http://bluehawk.monmouth.edu/monmouth/academic/dna/tigadbj4.htm
rk2153 AT gmail DOT com Design and Analysis 27

28. Summary
• Be Abstract initially Architecture
– Understand the flow, minimize coupling, streamline flow
– Design for change and diagnostics
• Then, study what you are trying to solve -- analysis
• Then, on how to do it -- design
– Keep analysis separate from design
• Object Oriented can help maintaining a simple language for the
entire life cycle.
– Eliminate translating between what was needed to how it was
realized in the program – OO allows you to speak the same
language for the SDLC duration.
Internal Structure (OOAD), external Structure(SOA)
rk2153 AT gmail DOT com Design and Analysis 28