Vendors of IT systems for back, middle and front offices are guilty of “non-responsiveness” once they have made the sale, according to Charles Kennedy, managing director, IT, algorithmic & program trading group, Piper Jaffray. He also contends that there are software offerings in the equity space, such as FIX interfaces, that are now a commodity, and should be priced accordingly. These required little in the way of additional IT development.
Speaking at a recent FMW conference in New York on the subject of ‘Build or Buy? Balancing Internal Development & External Systems/Solutions for Trading, OMS & STP’, Mr Kennedy said: “We’ve bought numerous products. While there are many good software vendors, sometimes, as soon as they [the vendors] get a sale, from that point on any call you make can sometimes take hours - possibly days - to get a response.”
Standing firm
Indemnifications clauses were a sore point too. He argued that vendors should “stand as resolutely behind their technology” as he claimed his firm stood behind its trades. When things went wrong, vendors could hide behind these clauses.
And, in an environment where spreads are getting tighter, software vendors must remember that they have to remain as competitive in their pricing as their customers (the broker/dealer community) have had to do. Getting anything developed for a specific taste could cost somewhere between $10,000 (€8,200) to $30,000 (u24,600) and was usually “a random number.”
When buying software, a total cost ownership evaluation must be done. “We’ll know what the annual costs involved can be. But, if for example, a firm buys an order management system (OMS) and also needs customer FIX interfaces, you should understand the cost and timeframe involved so a that a thorough cost of ownership evaluation can be performed.” For a customer a FIX interface could run to $15,000.
While stating openly “a little bias” towards build versus buy, Mr Kennedy said there were some caveats, because one of the more difficult parts of the (equity IT) business he says is getting “all the pieces” in play together.
“In my experience it’s always more difficult to get a front office to play with an OMS, to play with the back office, integrate that with market data and someone else’s Smart Router,” he states. “Ensuring it works 100 per cent of the time almost becomes a monumental challenge.”
Mr Kennedy is well placed to comment given his 10 years in the US Defence electronics industry where in-depth buy/build scenarios and procurement were “part and parcel” of his work. He subsequently worked for three broker/dealers: one that built basically everything and did a million trades a day, another that bought almost everything (30,000-35,000 trades a day), and Piper Jaffray where his responsibility “straddles the fence”- building and buying.
While a number of staff mathematicians are on hand and all algorithmic development is internal to the firm, they do use a vendor provided OMS. He is continually absorbed with evaluating Piper APT’s systems and deciding about whether to “continue to support” existing systems, retiring, replacing or procuring something else.
With integration into the larger platform (integrating business processes between Piper Jaffray – Minnesota office – and the Algorithm and Program Trading group), the firm will no longer be maintaining the proprietary middle and back office, which he says reflects an “ongoing trade off”. There are a number of things Mr Kennedy looks at when Piper Jaffray makes a buy or build decision. He explained some of the factors in a decision process.
Value of building
“Is there a strategic benefit for Piper Jaffray in the first place to build the software?,” he said. “Is there any economic benefit to buying or building? And, what is impact on the platform if we choose one route over the other? If we end up building it is there any value to the platform long term?”
This needs a thorough evaluation and should start by documenting the requirements and articulating needs. He cites an occasion where he once wrote a five-page top-level business requirements document for a Smart Router project. Having asked for feedback to ensure the software would work in way users need, he was met with the response: “I don’t think we should be building any of this, we should be buying. And, for that reason I’m not reading the (requirements) document.”
Mr Kennedy said: “That response struck me as odd, because even if you were not going to build the software, I would think an informed decision – either way – would start with the requirements to enable you to make an informed survey of the industry and discriminate intelligently between whether to buy, build or do something else.”
Mr Kennedy added: “If you cannot come up with a thorough requirements document that articulates what it is you want you should not be doing it in the first place.”
It’s also bad news if the first time you start talking about this is when you sit down with an IT sales representative.
Steven Smith, co-founder and chief executive of 4th Story, a provider of software that identifies and manages trading opportunities for broker-dealers and institutional investors based in the San Francisco Bay Area, added that if you decide to build “allow sufficient time” for documentation.
While not exactly an easy job, organisations need to work out the trade-offs in using vendors as against retaining internal development people on projects to establish the ‘real cost’. There is also the issue of opportunity cost to evaluate in terms of time to market and the expertise of your internal resources, he said.
It’s all about determining where value can best be added. He contends that while making trade-offs is one thing - cutting corners is quite another.
A new mcsystem
In a hybrid situation where an institution both buys and builds, Mr Smith likened the approach to “buying the bun, building the burger…and using your own special sauce”.
Firms like 4th Story “build so that other organisations can build less”, he contended “If we do our job right you [the client] can also build significantly less. It is not that elementary to come down on one side or other in terms of buy and build either. While many argue that you should build when it’s a case of strategy, Mr Smith noted that: “Right now there are not a lot of people who are building their own customer relationship management (CRM) system(s) even though it is recognised as strategic to a business.”
Mr Smith, who formerly worked at Hambrecht & Quist, where he headed up application development, commenting on whether it is too expensive to buy in, believes “pushing the numbers” gives you a good feel for things.
In an example, he shows that a six-person team on a project employed internally for 1.5 years (with a fully loaded cost of $120,000 (€155,000) per person) - now down to
four people - would cost an average per annum over five years of $550,000 (c.€715,000). It’s not cheap. Even after reaching the project implementation goal line, there is still systems maintenance costs.
In relation to building IT solutions and systems to gain a competitive advantage, 4th Story’s co-founder “absolutely” endorsed building out great ideas in organisations, but “not to necessarily build out the infrastructures that lie behind them.”
If you have a great idea there is “absolutely every reason to ‘build it’ out.” For instance, when building an advanced strategy or trading system - you are looking for something unique and “can add your own special sauce into the system.”
While confirming a general feeling that many have had “vendor relationships that disappointed”, he added from the vendor perspective: “We often see clients over-estimating or over complicating their problem.”
On that issue, Alan Paris, director in the Data Management Group of PricewaterhouseCoopers (PwC), said the buy versus build decision should also be based upon how much time an organisation has and what the budget is. He highlighted the importance of around 85 per cent of the build/buy requirement being communicated such that the development remains flexible enough going forward to accommodate changes as the project moves to completion.
Given that the options range from building from scratch (internally or outsourcing), buying and bending, integrating, choosing ‘best of breed’, a one-size-fits-all and finding a niche solution, the build issues centre on systems functionality (the ‘85 per cent problem’); systems integration (front-, middle- and back-end, reporting and disparate systems); and, data management.
Mr Paris said the major steps of business requirements and product evaluation should include a plan of product evaluation, identifying product requirements, request for vendor proposals (RFP), assessing vendor responses and product recommendation.
On a system requirements analysis, the key steps might encompass confirming project scope, identifying user needs, establishing requirements, analysing solution alternatives - prior to recommending the solution.
Points mean prizes
To arrive at a final decision on which vendor(s) and systems to deploy, PwC utilises sophisticated scoring cards (points and percentage) that mark the functionality of front-, middle- and back-office products, and offer point totals with/without vendor backgrounds.
Sample deliverables are performed for single platform and ‘best of breed;’ analysis. In terms of a data management programme, Mr Paris said this should address data acquisition, maintenance and distribution - with the people, technology and governance model being considered.
Mr Kennedy noted that among some of the “unique” features in his industry is the fact that many people in leadership positions do not fully understand the technology behind the business.
“They figure we can buy the stuff and someone else will take care of it.” Now more than ever the integration of IT with the business strategies needs to be “innovative”, he believed.
Citing the ‘Dirty Harry’ movie character Harry Callaghan, Mr Smith concluded that when deciding whether to buy or build: “A man’s got to know his limitations.” For some it might be a case of “close encounters of the fourth kind” when realising what they are up against.
