200 CHAPTER ◆ 2 1 Design System Architecture
The team should also document unit tests and objects early in the software design pro-
cess so that junior-level programmers can start building the GUIs, databases, and reports.
Unfortunately, many programmers believe that documentation of objects should come after
the software is complete, and furthermore that someone else should do it. Programmers
enhance job security by avoiding documentation. If a system becomes profitable, the pro-
grammers that built it, but avoided documenting it, will want raises. After all, they are the
only ones who understand how it works. At such a point, the firm has two choices: either
make the programmers partners, or hire even pricier programmers to reverse engineer the
system.
We recommend the product team call weekly documentation review meetings until the
initial object documents are complete. Developers have less leverage early in the process.
Programmers who avoid documenting tasks should be removed from the development team.
The financial engineers should audit documentation to ensure that it is properly done.21.4. High Frequency Trading Systems
High frequency trading systems are event-driven software applications (EDAs) that require
message-oriented middleware. Unlike traditional applications, which follow their own pro-
gram flow, event-driven programs react to external events, in our case, to events that occur
on electronic exchanges—changes in bid and ask prices and ladder volumes and trades.
EDAs rely on event loops, to look repeatedly for new data. When new data arrives, the
kernel calls back the program which executes an event handler function. Programming the
business tier of a high frequency trading system is a matter of writing the event handlers
that gather the new information and make trading decisions. Real-time trading systems
must deliver the right answers in the right order and at the right time. To meet these objec-
tives the software must have deterministic behavior. It must perform correctly and on time.
As a quality attribute, performance represents the responsiveness of the system mea-
sured by either the time required to respond to an event or by the number of events that
can be processed in a fixed time. Typically a performance requirement is expressed as a
number of transactions per unit of time or the length of time required to complete a single
transaction. Some aspects of performance are architectural and many performance prob-
lems stem from the architectural design decisions. A performance bottleneck that can be
traced to a single, isolated code routine can be easily fixed.
Performance is the driving factor in architectural designs for high frequency systems
and is partially a function of how much communication and interaction occurs among sys-
tem components. Performance can be modeled at the architectural level in terms of arrival
rates and distributions of service requests, processing times, queue sizes, and latency. With
the price/performance ratio of hardware dropping and the cost of software development
rising, longer-term, less arbitrage-oriented strategies are moving to the forefront.21.5. LOOP 1: Design Business Rules Packages
The product team may have already converted some of the business logic prototyped in
Stage 1 into C , Java, or .NET code objects in Stage 2. This code can be used in the
production system. Where this has occurred, the development team need not spend extra
time and resources redesigning and reprogramming those features. This code may com-
prise most or all of the business layer. Regression testing in Stage 2 should have already