Shiney, congrats on the milestone.
Wow. I think one could write volumes on evolution and design, and most of it is independent of computer language. One sign of a good design is how it supports evolution. Bernd's point is that you should expect a trading platform to evolve, but how do you plan for evolution? Unfortunately, design is at least one part experience, one part engineering, and one part black art. There is magic in knowing what is "just enough" and not over-engineering a solution so that you can do almost anything but it takes a lot of work just to do something simple. I'll leave the discussion of software design and engineering to other forums. Some pertinent topics include: model-view-controller, patterns, re-factoring, and even agile methods. Google is your friend.
From a trading platform perspective, I think there are some basic "inflection points" where things can become challenging depending on the initial design. Here are some off the top of my head ...
1) Market price series data formats
- Addition or change of vendor (CSI, MetaStock, etc)
- New kinds of trading data (stocks, futures, forex, options)
- Easily composing arbitrary functions (e.g. MovingAverage(TrueRange, 10))
- Applying deeply nested or complex formulas (e.g. Elhers)
- Integrating or leveraging external formulas (e.g. R-Stat, Excel)
- Easily extensible reporting statistics (e.g. Profit factor, MAR, Shape, K-Ratio, Sortino, etc)
- Supporting different order types (GTC/DAY, market, limit, stop, MOC, OCO, etc)
- Using more than one market in a strategy (e.g. gold and bonds)
- Using other kind of data in a strategy (non price-series, call/put ratios, etc)
- Using multiple timeframes in one strategy (e.g. 5, 15, 30 minutes)
- Support for scale-in, scale-out (multiple units and trading decision points)
- Trading multiple markets in parallel (vs. assembled post-run results)
- Enabling decisions based on positions held in other markets
* Sizing a trade, sizing a position
* Taking or blocking signals (e.g. correlation rules)
- Cross currency portfolios (one portfolio traded in multiple currencies)
- Expressing arbitrary ranges for arbitrary inputs
- Iterating over arbitrary input ranges and types
- In-place optimization (i.e. recursive trading engine)
- Switching from end-of-day simulation to real-time
- Support for placing, routing and tracking orders (coordination between internal signal and external orders)
- Handling discrepancies between actual and planned outcomes
- Handling outages vs. mechanical signals vs. held positions
* Signal/Feed down (reconnect, resync system and decision points)
* Broker routing down (ditto)
* Internet down (ditto)
* Power failure (vs distributed systems)
Why do I call these "inflection points"? If they had not been considered as part of the initial platform design, there is often a design change to enable the functionality, implying a major headache or re-write associated with each topic. Not every trading engine needs to implement all the above (we'd never get anywhere!), but I put them out for consideration.
BTW: There are some nice libs for people wanting to using Excel from Java: I started with JIntegra
and recently switched to POI
. The latter is an open source library that reads and writes native Excel (*.xls) files. I know other people using SWIG
(simplified wrapper interface generator), which is a great tool for creating second-language bridges into existing C++ libraries. I've also used FormulaOne
on commercial projects (a tad pricy). I chose POI because it is an OSS library can be used on any platform, and does not require Excel to be installed (i.e. it even works on Linux or Solaris).
The POI folk were nice enough to advertise a comprehensive list
of Java/Excel options.