Previously on this blog I have written about the conceptual architecture of an intelligent algorithmic trading system as well as the functional and non-functional requirements of a production algorithmic trading system. Since then I have designed a system architecture which I believe could satisfy those architectural requirements. In this post I will describe the architecture following the guidelines of the ISO/IEC/IEEE 42010 systems and software engineering architecture description standard. According to this standard an architecture description must:

1. Contain multiple standardized architectural views (e.g. in UML) and
2. Maintain traceability between design decisions and architectural requirements

Software architecture definition

There is still no consensus regarding what a system’s architecture is. In the context of this article, it is defined as the infrastructure within which application components which satisfy functional requirements can be specified, deployed, and executed. Functional requirements are the expected functions of the system and its components. Non-functional requirements are measures through which the quality of the system can be measured.

A system which fully satisfies its functional requirements may still fail to meet expectations if nonfunctional requirements are left unsatisfied. To illustrate this concept consider the following scenario: an algorithmic trading system which you have just bought / built makes excellent trading decisions, but is completely inoperable with the organizations risk management and accounting systems. Would this system meet your expectations?

Conceptual Architecture

A conceptual view describes high level concepts and mechanisms that exist in the system at the highest level of granularity. At this level, the algorithmic trading system follows an event driven architecture (EDA) broken up across four layers, and two architectural aspects. For each layer and aspect reference architectures and patterns are used. Architectural patterns are proven, generic structures for achieving specific requirements. Architectural aspects are cross-cutting concerns which span multiple components.

• Event driven architecture - an architecture which produces, detects, consumes, and reacts to events. Events include real time market movements, complex events or trends, and trading events e.g. submitting an order.

Reference Architectures

To use an analogy, a reference architecture is similar to the blueprints for a load-bearing wall. This blue-print can be re-used for multiple building designs irrespective of what building is being built as it satisfies a set of commonly occurring requirements. Similarly, a reference architecture defines a template containing generic structures and mechanisms which can be used to construct a concrete software architecture that satisfies specific requirements. The architecture for the algorithmic trading system uses a space based architecture (SBA) and a model view controller (MVC) as references. Good practices such as the operational data store (ODS), the extract transform and load (ETL) pattern, and a data warehouse (DW) are also used.

• Model view controller - a pattern which separates the representation of information from the user's interaction with it.
• Space based architecture - specifies an infrastructure where loosely coupled processing units interact with one another through a shared associative memory called space (shown below).

Structural View

The structural view of an architecture shows the components and sub-components of the algorithmic trading system. It also shows how these components are deployed onto physical infrastructure. The UML diagrams used in this view include component diagrams and deployment diagrams. Below is gallery of the deployment diagrams of the overall algorithmic trading system and the processing units in the SBA reference architecture, as well as related component diagrams for each one the layers.

Architectural Tactics

According to the software engineering institute an architectural tactic is a means of satisfying a quality requirement by manipulating some aspect of a quality attribute model through architectural design decisions. A simple example used in the algorithmic trading system architecture is 'manipulating' an operational data store (ODS) with a continuous querying component. This component would continuously analyse the ODS to identify and extract complex events. The following tactics are used in the architecture:

1. The disruptor pattern in the event and order queues
2. Shared memory for the event and order queues
3. Continuous querying language (CQL) on the ODS
4. Data filtering with the filter design pattern on incoming data
5. Congestion avoidance algorithms on all incoming and outbound connections
6. Active queue management (AQM) and explicit congestion notification
7. Commodity computing resources with capacity for upgrade (scalable)
8. Active redundancy for all single points of failure
9. Indexation and optimized persistence structures in the ODS
10. Schedule regular data backup and clean-up scripts for ODS
11. Transaction histories on all databases
12. Checksums for all orders to detect faults
13. Annotate events with timestamps to skip 'stale' events
14. Order validation rules e.g. maximum trade quantities
15. Automated trader components use an in-memory database for analysis
16. Two stage authentication for user interfaces connecting to the ATs
17. Encryption on user interfaces and connections to the ATs
18. Observer design pattern for the MVC to manage views

The above list are just a few design decisions I identified during the design of the architecture. It is not a complete list of tactics. As the system is being developed additional tactics should be employed across multiple levels of granularity to meet functional and non-functional requirements. Below are three diagrams describing the disruptor design pattern, filter design pattern, and the continuous querying component.

Behavioural View

This view of an architecture shows how the components and layers should interact with one another. This is useful when creating scenarios for testing architecture designs and for understanding the system from end-to-end. This view consists of sequence diagrams and activity diagrams. Activity diagrams showing the algorithmic trading system's internal process and how traders are supposed to interact with the algorithmic trading system are shown below.

Technologies and frameworks

The final step in designing a software architecture is to identify potential technologies and frameworks which could be used to realize the architecture. As a general principle it is better to leverage off of existing technologies, provided that they adequately satisfy both functional and nonfunctional requirements. A framework is a realized reference architecture e.g. JBoss is a framework which realizes the JEE reference architecture. The following technologies and frameworks are interesting and should be considered when implementing an algorithmic trading system:

1. CUDA - NVidia has a number of products which support high performance computational finance modelling. One can achieve up to 50x performance improvements in running Monte Carlo simulations on the GPU instead of the CPU.
2. Apache River - River is a tool-kit used to develop distributed systems. It has been used as a framework for building applications based on the SBA pattern
3. Apache Hadoop - in the event that pervasive logging is a requirement, then the use of Hadoop offers an interesting solution to the big-data problem. Hadoop can be deployed in a clustered environment supporting CUDA technologies.
4. AlgoTrader - an open source algorithmic trading platform. AlgoTrader could potentially be deployed in the place of the automated trader components.
5. FIX Engine - a standalone application which supports the Financial Information Exchange (FIX) protocols including FIX, FAST, and FIXatdl.

Whilst not a technology or a framework, components should be built with an application programming interface (API) to improve interoperability of the system and its components.

Conclusion

The proposed architecture has been designed to satisfy very generic requirements identified for algorithmic trading systems. Generally speaking algorithmic trading systems are complicated by three factors which vary with each implementation:

1. Dependencies on external enterprise and exchange systems
2. Challenging nonfunctional requirements and
3. Evolving architectural constraints

The proposed software architecture would therefore need to be adapted on a case-by-case basis in order to satisfy specific organizational and regulatory requirements, as well as to overcome regional constraints. The algorithmic trading system architecture should be seen as just a point of reference for individuals and organizations wanting to design their own algorithmic trading systems.

For a full copy and sources used please download a copy of my report. Thank you.