Are you really going to build this thing?
And, no this question has nothing to do with the current subprime crisis or the housing problem. Nor does it require wearing a hard hat to work, although it could perhaps protect one’s head from the bumps and bruises we experience in our industry.
What I would really like to understand is what makes a firm become a software builder vs. a software buyer? We get faced with the eternal “Buy vs. Build” decision in the financial technology industry on a daily basis, and while we are a biased party in this conundrum, there is still a sensible resolution to this dilemma, one in which, all parties can be happy with their choices.
Building proprietary systems that are commoditized makes no business sense. Buy-side institutions are in the business of making money for their investors by any legal means possible, but that should not mean getting into the core software development business in the process. Such software development in the financial industry is a cost center and like any other overhead has to be reduced. It of course makes sense to invest in building software that actually lies within the core investment competency of a firm, but it is plainly futile to build technology that merely reinvents the wheel. Many times an investment firm embarks on building (or should I say reinventing) a technology platform with the intention of being selective and prudent, but gets carried away, thinking that it won’t incrementally cost much more to build the rest of the standard parts of the infrastructure. This thinking is very shortsighted, and while, initially it may indeed cost less, in the long run the cost of maintenance will dwarf all the initial development outlays. In many ways, as this system matures and becomes more mission critical, it begins to act like a living organism consuming more and more resources.
It is perfectly acceptable to build trading algorithms, valuation models, analytical projections, but why build a portfolio management, accounting or risk system? Why spend money on data reference or data warehouse platforms?
Sometimes when going down the build path an IT department is out to prove that it can do it better than a vendor but such bravado should not drive the business. Instead a cooler “ROI” based approach should prevail. It is not about whether a better mousetrap can be built but rather how much will it cost to build and maintain over its lifetime? There are obviously many temptations in favor of building and owning your own software including: if you build it you can always modify it at a moment’s notice; you will be intimately familiar with its inner workings to change its behavior; you can quickly build another piece that sits on top of the existing data; you can do all this while being completely in control without depending on someone else to do it for you. All of these seemingly positive arguments, however, can be turned into disadvantages if we take a more business like approach.
The first question in discussing new software application development should not be “Can you build this thing?” but rather “How much of this thing can you buy?” Only if the answer is no to buying should an organization consider embarking on the path to building its own software. I have been in the same situation as the CTO of a large hedge fund. Back then we were forced to build because there was no solution that could be bought (luckily we were fortunate enough to be able to commercialize our investment – our solution later became the basis for Paladyne). Thankfully, times are now different and most of the standard applications are widely available. These new breed of products are not only built and maintained with the latest technology but are also highly customizable to suit the ever-changing needs of the business. It is also possible to build minor components around them to fill very specific proprietary needs. But best of all, there is someone on the other end of the equation, whose sole job and business function, it is to maintain and design new functionality for these products.
So next time your organization ponders the buy versus build question, first begin by ensuring that your firm has in place the correct architecture. Ideally it should be a flexible service-oriented architecture (SOA). This plug and play infrastructure will allow you to complete the puzzle of your infrastructure by selecting which pieces to build and which to buy. Once this is in place you then need to do a thorough evaluation of what applications are out there. What has already been built that fits the need exactly or likely gets you 80% there? Can this, remaining 20% of functionality be either overcome, or built around? Finally, remember that a buy-side organization can always build technology but your investors would rather have you concentrate on making money for them. There may be occasions that building software is directly tied to these money-making activities but for most firms this is rarely the case….
Sol Zlotchenko joined Paladyne in July 2005 as the CTO. He is responsible for all aspects of technology operations including development and product management for the complete suite of Paladyne products. He manages both local and overseas development teams and has played a key role in building Paladyne’s ASP service offering. Prior to Paladyne Mr. Zlotchenko was the Head of Development at Alexandra Investment Management, a multi-billion dollar, multi-strategy hedge fund. During his tenure at Alexandra Investment Management, Mr. Zlotchenko guided the company through tremendous growth, investment strategy diversification, and explosive technology infrastructure development. Moreover, he led development of numerous proprietary applications and third-party integration products covering trading, risk management, operations, accounting, and investor relations. Mr. Zlotchenko has extensive experience in financial services industry including a position at Goldman Sachs where he worked in various roles across multiple technology divisions. He received his BS and MS degrees in electrical engineering from Columbia University.
Filed under: Uncategorized | Leave a Comment
No Responses Yet to “Are you really going to build this thing?”