|
Welcome to the Trenches February 2006 This article was originally written for the Association of Shareware Professionals, for publication in ASPects. I've worked on Wall Street as a software developer for the whole of my career, and while working here has certain benefits, the typical set of available software leaves much to be desired. Wall Street software solutions in the vast majority of the firms are lacking at best and Id-rather-be-at-the-dentist painful at worst, and while the golden rule of idea generation for small software companies seems to be ˜find the need of the customer, the mapping from the golden rule to an actual available product seems to fail at some point. Since I know good tools are out there (some of you have written them), I propose two reasons why the developers here in the trenches are not using them; the small software shops are not targeting the right kind of Wall Street firm, and when they are, they are presenting the entirely wrong type of product. Who will buy my product on Wall Street? Don't target your software for major investment banks. Rather, I should say, don't bother. Not unless your business model centers on the exit strategy of being bought out. Even if that is the case, you'd probably have a better chance of being bought out by a software company, than by a large financial firm. Software is far from being of utmost importance for these types of businesses; people are the primary resource, and the bank would much rather keep paying a $100,000 salary to a mid-level developer, who will then grow with the company, than to invest in a piece of third party technology. That being said, there are certain product domains which are good candidates for big bank investment. The arena of smaller financial firms is far larger, and thus is a much better target for independent software developers. These firms typically work in a very tight niche, are far more focused on their specific business model to bother spending years developing in-house software, and unless you are providing a service, or your software requires constant support, they don't care that your company is just a single developer working out of a basement. Another distinction between the purchasing practices of large firms vs. small firms on Wall Street is the amount of work you have to do, as an owner of a small software shop, to get the sale. Large investment banks make firm-wide purchasing decisions only after months of initial communication with a vendor, a limited-scale trial period lasting several weeks, followed by very uncomfortable licensing negotiations possibly leading to a very lucrative sale; which itself leads to years of support headaches for the vendor. Small, intra-firm software sales are still made, but they are few in numbers stemming from the fact that very few employees have the required purchasing power, and tend to delegate software licensing to Big Brother. If an employee wants a single license for a favorite code editor, the big bank logistics require a request ticket to be submitted. If the editor is already in rotation within the bank, they will always find an extra license somewhere to hand to the employee. If the editor is not in rotation, the firm will not be inclined to introduce a new piece of software into their systems on a whim, and they will certainly not delegate resources to the investigation of this new piece of software to please a single employee. End result: you either already sold the software to them, or you probably never will, unless there is a strong following and numerous requests within the firm; and programmers are too particular about their favorite editors to ever reach such a consensus. The purchasing logistics of a smaller firm are less complicated. If the employee already has a license for his favorite editor, he can go ahead and use it. If the small financial firm needs something more substantial, they will typically download a trial version from the vendor's website to a few computers and run it for a while. If, after the trial expires the firm still has a need for the product, they will typically not hesitate to buy the required licenses, but only if the hassle of doing so is minimal. Time, not safety and administrative consistency, is of utmost importance to small financial firms. If they decide to purchase your product, and you put them through administrative torture in order to follow the logistics of your own licensing scheme, they will promptly dismiss you. Then they will go ahead and build the thing in-house, since the experience left them completely dismayed with third-party software. On a side-note, if you're selling components, rather than black-box products, you'd have a much better chance of selling to small financial firms if the license includes the full source-code. What is the right kind of product? Still, even for the smaller firms, the choice of available products is very limited, and a few choice standards show themselves again and again. What type of software do these smaller firms need? Every firm I've ever worked in on Wall Street 'both small and large' needed the following: Networking Layer: No one here uses TCP to any serious extent. The trading systems are all distributed modules, and they all speak UDP. Speed is everything. The distributed modules, which perform specific, independent tasks, cannot be made to sit and wait for other modules to complete their work. However, since UDP, as you might know, is an unreliable protocol, every firm invests in a technology which assures reliability for UDP. The standard product set here is Tibco and Rendezvous, which have more or less saturated the street. I assume it would be fairly difficult for a small software vendor to compete in this market. You will not sell a networking layer to a company that already has infrastructure in place. Database Needs: Sybase and Oracle. Smaller databases might still be used for non-critical information, but Sybase and Oracle are pretty much it. These vendors have done their due-diligence, and wooed Wall Street into submission very early on. You should see the swag during license renewal periods! These products also support certain database compliance protocols which many products used in the financial sector are required to comply to. This might be difficult for small vendors to address, since they don't typically employ an army of lawyers and compliance officers. GUI frameworks: Platform independence is not an issue here. We run Solaris, Linux, and Windows, pretty much in that order of importance. UNIX GUI work is done in X (ouch), or Java. Windows GUI work is done with Java, MFC, and more recently, C#. I've never seen smaller GUI libraries gain popularity within Wall Street firms, but traders like elegant software interfaces, and so third-party WIN32, MFC, and .NET components and GUI controls have potential. There are very few useful ones, but flexible grid controls are very popular. Even then, the company developers make heavy changes to the third-party code to customize the grid. If someone makes a truly flexible grid control, with almost every property and painting facility exposed through the API, it would not have a hard time finding customers on Wall Street. Hint: traders need to see hundreds of rows and several dozen columns at once. Most grids are inadequate, especially when the window is resized to fit across three or four monitors. While were on the topic, if you are targeting Wall Street firms with a desktop product, make sure it works well with a multiple monitor setup. No trader uses less than two monitors. Some use eight. Project maintenance: This are needs attention. Most firms roll their own SRS (Service Request System) solutions for bug ticket tracking. Some firms use Wiki pages. A few firms use Bugzilla. I've come across several products from small vendors that insist on an existing framework containing a web server and a database. The smaller financial firms might not have a dedicated database for such purposes, they might not even have a web server, and they certainly will not allocate the time to set such a system up. Every firm looking for existing solutions to this problem eventually gives up for one reason or another. Project maintenance tools are not firm-wide systems. They do not need to be as complex as some vendors believe. A standalone product with no dependencies will suffice. Simple overview, prioritization and searching functionality are the only things needed. Source code control: CVS (Concurrent Versioning System), SCCS (Suns Source Code Control System) and similar derivatives. This is without exception. Even Subversion failed to make it into the Wall Street domain. Like networking technologies, once a source code control product is in place, on day one, no one will even think about replacing it with another technology, no matter how good. Email: Outlook and Exchange Server. Outlook is ubiquitous on Wall Street, and the recent Blackberry integration has pretty much ensured its perpetual existence. Why are these products the standards? It isn't because there aren't better choices, its because the vendors making these products do not actively target the smaller financial firms, and the people at the firm are far too busy to do any kind of serious research or evaluation. And why should they? Software on Wall Street is just a means to an end, and since their already successful competitors have always used the standard products, why not just do the same? One area seriously lacking in product selection: intra-firm instant messaging clients. They are becoming more and more important. Certain things are so much more easily achieved through instant messaging than through email, but Wall Street firms cannot use the existing popular solutions like AIM, or Yahoo Messenger because these products are not targeted for use in such environment, and thus do not abide by compliance requirements. Certain SEC policies, such as Sarbanes-Oxley demand more from software applications which are to be used in financial firms. In a nutshell, all communication and data storage must be secure, verifiable, and completely traceable should a compliance officer ever request such information. At the moment, the only popular IM product in use on Wall Street is HubConnex, which is far from being an elegant (or aesthetically pleasing) product, but it does abide by all compliance standards, and we therefore have no choice but to use it. A single-person software shop could easily implement a better solution. Aside from designing a cool new IM client, all it takes is a bit of research into the compliance issues involved (and this, in itself, is not that much more involved than reading up on the guidelines of the Sarbanes-Oxley policies). So what are you waiting for? - Andrey Copyright © Andrey Butov |