[Chicago-talk] New system architecture

[Jay Strauss]

Well, the users are really just me and my brother, so at least we can
probably get access to them :)

Yep there are a lot of trading apps out there, but most seem to do
more stuff like technical indicators that you can build some sort of
if-then-else on a bunch of indicators to give a trade signal. We are
doing something a bit different, and have our money management
routines.

Most of our problems come from having switched brokerages (and thus
our data gathering is now different), switching some of our accounting
(making it simpler), and just not maintaining some of our stuff.

Why fix when we can spend twice as much time re-writing :)



On Mon, Jun 1, 2009 at 12:37 PM, Joel Limardo
<joel.limardo at forwardphase.com> wrote:
> If this is an academic exercise please disregard the remainder of this
> e-mail.
>
> I don't suggest you write much more code unless you cannot get the prototype
> system that you currently have up and running. If you want to make money
> (which I suspect that you do) then your next set of requirements ought to
> come from the people who are going to pay you for use/access to your system.
> I suggest that you spend some time documenting the system you have now; fix
> its bugs; make some presentations and other materials and then take it out
> for a test drive with real or strongly representative users. Since there are
> many existing trading applications out there I suggest you focus on why
> yours shows promise and/or is different. From this collect usage data and
> complaints, classify them from High to Low (where "high" means "sure, I
> would pay for this damn software if only it did X") and then ask the
> question you just posed again armed with real metrics like the number of
> users your application will support; the amount of data it will need; how
> much data processing you expect it to perform; cost for operation; etc.
>
> There's an old Chinese proverb I go by which goes something like this --
> when all doors are open, all doors are closed. I translate that to mean when
> all requirements are open you are likely to start spinning your wheels.  I
> go to actual users and ask them what they want, which typically eliminates
> the problem entirely.
>
> That's my two cents.
>
> -----Original Message-----
> From: chicago-talk-bounces+joel.limardo=forwardphase.com at pm.org
> [mailto:chicago-talk-bounces+joel.limardo=forwardphase.com at pm.org] On Behalf
> Of Jay Strauss
> Sent: Monday, June 01, 2009 12:14 PM
> To: Chicago.pm chatter
> Subject: [Chicago-talk] New system architecture
>
> Hi all, need some advice.
>
> I want to build a new system.  My bro and I have a small
> equity/options trading application.  We cobbled it together in Perl
> and Oracle years ago.  Things have broken, some of the stuff we want
> to change.  Ultimately we want to start over.
>
> I'm just trying to decide on what architecture to use going forward.
> I know this is a pretty wide question.
>
> Most (all) of the processes will run on a single box.  I don't really
> have an idea of which presentation route we'll go (full rich client
> maybe using Java/Swing, maybe a Java Script client using GWT, maybe
> plain HTML).  The client will probably request functionality from the
> server.
>
> I was thinking we'd do the whole API for asking for quotes, requesting
> analytics, inserting transactins...  via HTTP (SOAP).
>
> Can anyone give me their thoughts on their lessons learned, maybe
> routes to try, stuff I should be thinking of...
>
> (again I know this is pretty open ended, but I'm interested in what
> others have done with success)
>
> Thanks
> Jay
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk
>
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk
>