Grad school was physics: computational theoretical and experimental. Started more than one software development consulting company and worked for a couple of successful IPO's. I have always worked in the financial markets in one form or another: either for the exchanges or for other financial or technical organizations - including my own.
Nothing was hidden from me - they had no reason to hide anything. I worked for a Director in IT, spent 8-10hrs a day doing various IT work at their old Columbus Ohio HQ for about 6 months or so. There are plenty of companies that code their messaging vs using out of the box.. why? who the h*ll know's, they all give different reasons that make sense to them (most of them often think niavely that it will be cheaper). Even when they have MQ or TIB, they often want to wrap it with their own home grown broker. I'm wrapping one right now for the US Air Force! Folks do the same with about all COTS middleware products out there - whether they're abstracting vendor dependenies, framework junkies, etc.. I've been doing IT contract work FT since I left the USAF in 97, and this has been my experience the vast majority of times. I don't agree with most of my clients ideas, but often they have already made up their minds and hired me to help implement their decisions. I've seen companies build their own web portals, workflow engines, business rules engines, scripting languages, web servers, records management, transaction monitors, ORB's, etc.. rarely did I think it was justified, but if they want me to provide them some developers as staff aug to make it happen, then I will be more then happy too.
That does not change the fact that: 1) I did just this in 2000 at Bankone 2) I did not ask how much money the bank had. I never said others have not done this before.. nor did I claim it was infinately scalable. As a matter fact, I agree with d*mn near everything you said here. But it has no relevance
Why would you ? The banks requirements were hopefully constructed with regards to the present and future volumes of transactions they need to support, and the points at which the design becomes invalid.
THAT WAS MY POINT FROM THE START. My original post said that the IT infrastructure requirements are not correlated to the financial size of the institution. Why are you busting my chops - did I just pee in your cheerios or something?
All too common in most IT organizations.... The federal government IT organizations are some of the worst offenders by the way .... I see a lot less of this in the larger financial organizations which are tending to standardize their designs and move away from building and more towards integrating We moved out of staff augmentation long ago for exactly the reasons you mention - often not in companies best interests.
High-performance trading architecture Waterloo, It would appear that you are in need of some nononsense help: High-performance in trading has very little to do with your computer silicon hardware. High-performance depends for 99% on the computer between your ears. If you get that one to run smoothly, you'll have little problem in picking the matching box architecture. nononsense
Again, I agree with your observations... and pimpin' aint fun, but it pays I'm just an incorporated independent that occasionaly brings others onto my contracts as well. 1 million gross is a good year for my little operation, but then there's only 1 W2 to pay after the 1099's
Thanks nononsense, what's funny is my first thread entry I was hoping for more middle of the road solutions. Like lets say I'm a solid trader at some firm. I then go off on my own, what type of architecture stuff do I need. Usually that's taken care for me, and I have little interest in it. So now, how do I go about the business of trading, rather than the act itself. Do I really only run TS and Quickbooks and a T1 line, are their other "complete office" platforms? Is there a COTS solution that says "so you want to run a HF, here's the software and the hardware you need to do business." I figure it's a template type of thing by now. We've sort of drifted into "really" high preformance solutions, which given my poorly choosen title, is appropriate.