I know posting has been slow the past few days, I hope to pick up the pace this week out of complete guilt.

Let’s start with a good one. The 2nd Annual American Financial Technology Awards will be taking place this coming December 4th in NY and hosted by several publications under the auspices of Incisive Media. The deadline for entries is September 29th.

Go here for more information on how to enter and details on the various categories of prizes…

Meanwhile if you’ll excuse me I have to go write an acceptance speech…

No Comments

An overworked programmer recounts the foibles of one of his co-workers, a younger, more fashion-forward gentlemen who is otherwise an excellent fellow. It seems, however, that when he goes to the bathroom, it’s pants down around his ankles for pretty much the entire time - standing at the urinal, moving over to the old sink, wiping his hands. The pants only come back up before he leaves, thereby ensuring that the ladies in HR don’t get a glimpse of his BVDs.

No Comments

Worldwide financial services spending is projected to total $472.6 billion in 2006, a 3.6 percent increase from 2005 spending of $456.3 billion, according to Gartner, Inc. In 2007, the market is expected to grow 4.5 percent to $493.7 billion.

The market is being driven by a combination of factors, including the economic climate. Industrialized countries are still benefiting from the tail end of the most recent economic expansion which drove higher trading activity, more mergers and acquisitions, and an increase in demand for corporate lending. Developing countries are benefiting from the democratization of wealth in their economies, which is spreading from the high-net-worth population to a much broader mass-affluent population as manufacturing and professional services jobs are generated by global trade.

It doesn’t seem like a lot, but it’s good to see that technology spending in the financial space is growing yet again.

No Comments

I found that it was more fun to be agreeable in my previous post (which responded to Peter Holditch’s rebuttal) than I did to be disagreeable, so I decided I’d saunter on over to Peter’s blog and see what else he had to say.

And lo and behold, the man makes one of the points most dearest to my heart. And what might that be? That pauseless garbage collection (or deterministic finalization as I like to call it) is The Goodness ™ !!

All the people I have been speaking to are responsible for applications that provide trading services - some foreign exchange, some stock trading, and so on. All of these, however, have one thing in common: the items being traded have some “market value” which is constantly fluctuating, with up to the second prices broadcast on some kind of ticker.

It warms my heart.. And gets even better:

So, who needs pauseless garbage collection? I would contend anybody that wants the gain of java development without the pain of fragile tuning gymnastics and has a latency sensitive application to take care of. Which is a lot of people.

Pauseless GC = increased customers + reduced cost

Yes! And let me add, this mean and evil non-deterministic finalization is also found in the .NET CLR. Having a background in both real-time and high performance financial systems as well as real-time 3D graphics and computer/video gaming, nothing gets my goat more than the fact that so far modern languages refuse to embrace deterministic finalization. Whether it’s Java, .NET, Ruby or even Lua, the scripting language practically developed specifically for embedding into commercial gaming engines, none of these have strong answers for this problem.

I have always felt that the answer is to provide a pluggable finalization policy and let the user of such platforms decide. If you want an example of a language that gets it right, take a look at Squirrel. Largely derived from Lua, but with many key differences, Squirrel uses a combination of a reference counted system (to ensure automatic cleanup) along with optional (and user defined) calls to a mark and compact algorithm, to take care of any circular references.

2 Comments

Peter Holditch, a Senior Systems Engineer over at Azul Systems, recently responded to a post I made which took issue with Java’s place within the financial technical landscape. Peter made some interesting points (which I’ll get to in a moment). However he also made some rebuttals to my post that I think are quite off the mark. Let’s tackle them first, and we’ll leave the parts about where we agree for last, so we can end on a shiney, happy note

Reading Benjamin’s article, I am guessing that he is rather attached to Microsoft technology (although he does mention C++ too) and thus is not overly keen on java, being from “the other side”. Never being particularly prone to bouts of technology religion (although, for full disclosure, I have been working on UNIX for 16 years, and java for 10) I read his assault on java with some degree of detachment.

I guess before we go on I should also make a full disclosure. I am a proponent of .NET in many instances these days, but I am definitely not technically religious. I have used Java on and off for roughly eight years, and at one point had one of those nifty Sun Java Programmer certifications. Yet conversely I also worked for Microsoft for a number of years and had all such Java knowledge wiped clean from my memory (just kidding). If I have any attachments to technology, its probably to standard C++ (on any platform) than it is to any modern managed language platform, but even there I am ready to concede that its technical power is often outweighed by its cost.

But let’s continue:

I did, however, feel moved to put finger to keyboard to try and move the debate on…

It seems to me that Benjamin is confusing 2 concepts, namely the language an application is implemented in, and the frameworks used to implement it…

For example, talking about writing GUI front-end applications Benjamin says:

“[java is] at a great disadvantage when it comes to front-end performance (graphics, painting, look and feel) when compared to native Win32 based libraries (MFC, VB, and more appropriately Windows Forms)”

It seems to me that this is not a typesafe comparison. The java language on the left of the comparison needs to be silently promoted to be compared meaningfully with the libraries on the right. He then goes on to say that since .NET front-ends are so nice and easy to build, the back-ends should be built in .NET too, to match.

Looking back at Yakov’s article, he is talking about frameworks too, not the language per-se…

“A couple of years ago I was participating in the design and development of a multitier and multiplatform equities trading system that was built around Java Messaging and Enterprise JavaBeans (both session and entity beans). This real-time system has successfully replaced a legacy C++ application”

What part of the java language are Enterprise JavaBeans, or Java Messaging? well… None. They are part of the J2EE specification; a specification of a runtime framework, not a language. And here is the point: Microsoft style development has a very rich and useful set of frameworks for building front-ends. J2EE (as opposed to the java language) defines a rich set of frameworks for server-side implementations. Hence, .NET style technologies get used on the front end (as Benjamin points out) and J2EE style technologies get used on the server side (as Yakov discusses, and Benjamin laments)

Well I guess I should apologize for not being more clear, when I talk about Java I most definitely am talking about the language in addition to its VM and libraries. I think Peter might be getting caught up in semantics though, I mean one of the very few places Java can be embraced completely separate from the VM and the Sun libraries is… wait for it… as a CLS compliant language that emits MSIL for the Microsoft .NET Common Language Runtime.

But that’s neither here nor there at the moment, because Peter was right, both I and Yakov were talking about frameworks and libraries, or in the all encompassing sense what I like to refer to as managed language platforms.

I would argue that’s as a result of CICS (and the other TP environments that support the language) providing such an overwhelming volume of useful server-side infrastructure that people just used the language, because the framework maximizes their productivity. Looking at C++, as a language it’s not a million miles from java, but it lacked infrastructure; memory management was a nightmare, and CORBA was always a rag-bag of distribution services, not a useful consolidated platform, such as CICS and J2EE provide. So the language withered, due to lack of infrastructure (whatever the “performance” that could be achieved - which opens up a whole new debate in itself; how do you measure “performance”, microseconds per calculation, or days to bring the finished system to market?)

I can’t argue with that (this Peter guy is very reasonable, I like him already). There’s no doubt in my mind that the ease of building systems with a powerful and cohesive suite of libraries offers delicious economical benefits, and that is true of any managed language platform, whether its Java or .NET. I should have been more clear about that up front. The crux of my contention however is that in high performance arenas I believe that a well crafted C++ solution will outperform one implemented in either managed language platform. And yet if the lure of the economical aspects of the managed world has you enchanted, then I would chose .NET over Java, for the reasons I originally laid out. If you forgot those, I’ll briefly review them:

1) On the desktop, the .NET CLR will always outperform the JVM. The CLR has intimate knowledge of the Win32 subsystem, including very tight wrappings around graphics and window message processing. Given that Windows is de facto on the Wall Street desktop, Java as a platform never stood a chance.

2) If you’re writing high performance trading platforms, they tend to have tight data and event type couplings between the GUI and the servers, which usually communicate using sockets (databases are just too slow to provide most real-time information on a trading system). Given this tight coupling, it makes little sense to use Java implement the server processing of such a system.

With that in mind, I think it’s important to point out that Peter was technically correct when he wrote the following, but the point was really out of context for the type of high performance systems we usually are faced with building in the financial world:

And here is the point: Microsoft style development has a very rich and useful set of frameworks for building front-ends. J2EE (as opposed to the java language) defines a rich set of frameworks for server-side implementations. Hence, .NET style technologies get used on the front end (as Benjamin points out) and J2EE style technologies get used on the server side (as Yakov discusses, and Benjamin laments)

J2EE really has never had a place in any system I’ve ever built for real-time trading. So I think I am on solid ground in lamenting the fact that Java is so popular for writing socket based server processes that talk to .NET based GUIs. Maybe Peter’s guilty of missing this point, or I may be guilty of not making this point clear enough, but now that it’s spelled out I would think this is a pretty difficult point to argue against.

Peter then makes a nice segue into his company’s own technology:

The fact that java is so prevalent, and has such a useful infrastructure underpinning it in the shape of J2EE, has driven adoption to the point where datacentres are groaning under the weight of servers needed to run the current production estate. The fact that the java virtual machine provides quite nicely for services like garbage collection and multithreading - capabilities harnessed in an orderly fashion by J2EE - means that the VM layer is ripe for technology optimisation [sic], to get better throughput - and better scale - for less power. Which is exactly the optimisation [sic] that Azul provides. Now, you don’t need one hundred parallel application servers, just a few extremely scalable instances side by side. Aren’t you glad your choice of java allows you to do that seamlessly!

I can’t argue with him here. I had a meeting with two very sharp engineers from Azul, it was about a year or so back. I was very impressed with the technology they have put together and I think you should quickly go to their site and investigate further if you are responsible for building high performance systems.

And lastly:

Oh… and Benjamin; Azul is designed to be able to support the CLR too… I’d hate for you to feel out in the cold

Hey, I told you this Peter guy was alright!

4 Comments

CIO-Weblog has a piece on measuring IT performance, including a citation of where Wall Street is going beyond the usual steps to track it’s IT quality. And oh, a comparison is made between IT and a certain fish.

Best-in-class IT organizations have gone beyond rote metrics such as system uptime and help desk problem resolution. Some IT shops on Wall Street, for example, are studying things like how many stock trades or customers they’re able to support for each IT dollar they spend, says Howard Rubin, an analyst at Gartner Inc.

But these kinds of metrics are much more difficult to use than the
traditional IT time and transaction measures. One of the big challenges that many IT leaders face in developing effective metrics, says Rubin, is determining which activities are under the auspices of the IT department. For instance, some user departments at financial services companies have their own LAN administrators who are outside the purview of the IT organization, says Rubin.

“There’s IT everywhere, not just in the IT department but in bank branches and on the plant floor,” he says. The business activity supported by IT “drifts back and forth like the eye on the head of a flounder,” he adds.

Read it all. Bon apetite.

No Comments

The International Herald Times has quite an interesting piece on the recent trend of Wall Street financial firms entering an “arms race” over technology and financial product patents.

An intellectual property arms race is escalating on Wall Street, where financial services firms like Goldman Sachs and Citigroup are building up stockpiles of patents on processes like software-based pricing, trading and risk analysis systems and products like credit cards, exchange-traded funds and exotic derivatives.

While there have been no big clashes yet, the question is, Which firm will be the first to try to enforce its growing portfolio of patents?

Do tell? But is there a silliness factor involved?

“Right now, people are figuring out they need some playing cards so that if someone comes to us and says ‘You’re infringing,’ well, we have some patents and we can do a cross-licensing deal and everyone goes away,” says Raymond Millien, a former patent lawyer for American Express who is now the general counsel with Ocean Tomo, a merchant bank specializing in intellectual property. “But there are going to be some companies on the Street who are going to start licensing their products and enforcing the patents to get a revenue stream from them.”

You know I’ve never been a fan of software patents ever since Amazon obtained one for one click checkouts. It left me nonplussed. I think the previously quoted paragraph underscores this fact. I am not a patent lawyer, nor do I play one on TV, but for an industry that prides itself on free markets, hedging on patents seems like an, uhm, wimpy departure from such ideals. Can we all look forward to this eventuality the next time there is a major market crash?

“Right now, because all of the Wall Street banks are showing record profits, there’s not much incentive to sue within the club,” Mr. Millien said. “But three years or so down the road, it’s hard to say.”

No Comments

FinanceTech has a piece questioning the overall value of broker algorithm offerings. It asks some great questions I’ve been asking myself for some time:

Countless reams of paper and miles of type have been expended on the profound effects of algorithms on market structure and trading styles. The focus predominantly has been on broker market share of algorithmic flow and trying to make sense of the seemingly endless array of new bells and whistles (primarily aimed at the buy side) that brokers and vendors constantly are churning out.

But how profitable has the algorithmic adventure been for brokers? Has investment in hiring quantitative mathematicians and building out distribution and sales networks been worth it? Or have algorithms become such a common feature in the trading landscape that it simply is unthinkable for any broker worth its salt not to offer them (and eat the cost) because that’s what clients want? And what effects has the rise of algorithms had on brokers’ internal organization?

…

What seems certain is that no broker can be taken seriously today unless it at least offers the basic algorithms - volume weighted average price (VWAP), time weighted average price (TWAP), implementation shortfall and arrival price. It’s also clear that algorithms are more cost-effective for low-maintenance trades, and that has meant head-count shifts and reductions on sales desks. But the decision to offer a more complex and comprehensive suite of strategies is a much bigger dilemma.

Read it all, I think the jury is still out on algorithms from the sell side. It wouldn’t surprise me if they were ho-hum in 3 years time.

No Comments

I’m noticing an interesting trend in the changing landscape of Wall St. Last time we discussed the realities of globalising the financial markets and the emmergence of downtown as a residential hub. Now this past weekend’s NYT (registration required) has a great piece on the new trend of streeters going to work for firms in Greenwich (and Stamford), CT. Being that I work at a fund in Greenwich (name of which is not important) I found the article interesting:

Thousands of young financial workers stream into Grand Central Terminal every weekday morning. But many are not on their way to offices on Wall Street or in Midtown. Instead, they are crowded into trains for Greenwich, Conn., which has emerged as the home of the ballooning hedge fund industry. The center of power in finance has shifted in recent years, and in one sense that shift is geographical. Some of the most powerful traders in the market can be found miles away from Wall Street, in Greenwich, Stamford, and Westport, Conn. ‘If you look up and down the train line in Connecticut you will see all the hedge funds concentrated right along the line,’ said Thomas Torelli, a corporate real estate agent in Greenwich. Those funds are there because their founders and top managers live nearby. But thousands of their employees do not and as result do what to the rest of Wall Street is a reverse commute.

Luckily I gave up the hustle and bustle of the city several years ago. As a native of Manhattan and a long time resident of Brooklyn, I guess you can say I’ve had my fill of the city for the time being, and as a result my commute is very easy from Westchester, NY.

‘Greenwich is quiet, peaceful and clean,’ said a young hedge fund employee on the train who lives in Manhattan. ‘But I am 24 and single - I couldn’t imagine living in Greenwich.’

I used to think the same thing when I was 24, but now that I’m almost 30 and married, I can’t imagine living in the city anymore. I wonder, does this mean that in 5 years time there will be an influx of migration from NY into the Westchester and Fairfield communities?

No Comments

This article from Yakov Fain over at java.sys-con.com would surely have you believe so, although it’s hard for me to tell when it was written (2005?).

I am not so convinced, nor have I ever been, about Java in general, and especially in the financial world. I have seen it make huge inroads, but I have always felt it could be outperformed by a well designed and implemented application using C++ or even C#/.NET. To this day I manage to ruffle many feathers with such prognostications, but I stand by them not on principal, but on what I believe is the merit of the argument.

For instance:

If, back in the ’90s, you’d suggested using Java for processing split-second stock market orders, most of the New York programmers would just simply say: “faggedaboudid.” If you want to have some fun, read old articles on using Java for Wall Street applications. Here are some statements made a long time ago in 1997:

• Java is strong on the front end, but we do not foresee it being used for very large number-crunching applications.
• Java is fine only for very thin clients.

Well I will concede that Java has made its way into large number-crunching applications, but I believe that has more to do with advances in processor and memory architectures than it does with Java, or any supposed inanate ability for it to handle numerical problems.
(more…)

28 Comments