Why are you even suggesting a preferable architecture when you dont even know what the requirements are?
Very true. A sw architect who can visualize and design solutions to work around every obstacle. Any idiot with persistence can implement syntax. However, the SWA also needs to be a trader with extreme price action skills to understand the flaws within the op's chosen dynamics and thus be able to replace the weak components with more accurate variables which generate fewer false positives while simultaneously increasing recognition of true positives.
First of all, before hiring a programmer, you must select an autotrading or programmable trading platform: 1) Tradestation (Easy Language) 2) Ninja Trader (Dot Net-C#) 3) Multicharts (Power Language) 4) Sterling Pro (Dot Net-C#) 5) Interactive Brokers API (Java, C++, VBA, Dot Net) 6) Quantopian (Python) Once the platform selection is made, THEN you can hire a programmer who knows the in's and out's of that trading platform. Now, if you want to create your own trading platform, my advice to you is: Good luck....you are going to need it. Be prepared to go bankrupt.
Was under the impression that OP was looking something more advanced than the retail platforms as TS2000/NinjaTrader/MT4. But yes, you should start by looking at requirements. I would advice against lock-in to one single platform and put the code outside of the platform and use the platform only for order execution. One should be able to switch broker/platform without rewriting the code, only the small part interfacing with the platform application.
Totally agree...but the platform vendors have focused on "lock-in". (They're smart !) Someone would have to create a CROSS-TRADING-PLATFORM tool to be able to support multiple platforms with a single set of code. That's a MONUMENTAL effort and does not exist today for obvious reasons. As a corresponding example, Microsoft, after 5 years of work, has not been able to port their Office platform with programmability to the web. I would estimate that what you are asking for is about a 20 man-year effort.
I'm smack in the middle of extracting embedded API calls, due to stepping forward some versions of an API. I know better, so I can't believe I didn't structure my code with a clean interface from the start. I'll see how much of a performance hit I take with the extra layer, but it will make future API upgrades independent from my core code.
This is normal, first aim is normally to get something working as quick as possible. Then refactor when codebase becomes messy and when requirements become more clear.
Rather than a platform API, one can use the open-spec FIX Protocol and achieve almost total broker neutrality. FIX is likely to take a bit more time to understand initially, but once you're there it's vastly superior to any platform I've used in almost every way: fault tolerance, logging, consistency, lack of crashes (no need to keep a GUI-based "platform" running), etc.
I wish. When I looked at that some years ago, the testing requirement before a broker would let you run your FIX platform against their FIX interface was prohibitive. These days, any open source base FIX platforms available?
Omigosh....FIX ? I evaluated it about 4 years ago. Bottomline: the FIX protocol...simply...SUCKS. Why ? : It was not architected to be specific to trading....THAT'S IT'S BIG PROBLEM. On top of that, subscribing to the FIX protocol has NOTHING TO DO with the API and code requirements of a specific trading platform.