Buy or build? Getting the most from software vendors
Frank Maltais of State Street
May 13, 2014
Wealth and asset managers face a tough decision when weighing the benefits of building software solutions themselves or purchasing a product off-the-shelf. Frank Maltais, managing director of Princeton Financial Systems in Asia Pacific, explains when buying might be the best option.
Some financial services firms answer the buy or build question by distinguishing between less strategic applications, which they buy, and more strategic applications, which they build. For other firms, however, the opposite is true.
Consensus in the investment industry, meanwhile, is that mission-critical applications should be commoditised as far as possible. By mission critical, this means technology that is core to the investment manager’s business – an accounting and operations system requires, for example, a lot more technical expertise than a spread-sheet that sits in the front office holding trades and profit-and-loss.
“It is not by chance that most wealth and asset management firms which experience significant growth will start investing in technologies for the back-office first, and then make their way to the front office, rather than the other way around,” says Frank Maltais, managing director of Princeton Financial Services in Asia Pacific.
Buying at that point becomes a very reasonable decision, he explains, due to several factors.
Cost
The cost-factor includes not only the software license but also the implementation and ongoing costs.
“However, this is only where the real benefits start,” says Maltais. “The asset manager can from that point begin focusing on the core business of seeking alpha.”
It is at this stage when the development of the technology can be handed over to the vendor’s team of specialists along with the staff of the buyer, he explains.
“The support and consistent delivery of new requirements due to growth can then be leveraged both on the business and technical side,” he adds. “So all in all, and with all things being equal, a software package will always be less expensive than a comparable in-house developed system.”
Scale and complexity
According to Maltais, people who work in technology will always argue that everyone can build software. “What they can’t do, however, is factor in – within time constraints and budget – the large numbers of regulations, investment types, reporting preferences and other business driven-requirements that will satisfy an asset manager which uses the entire world as their territory for finding alpha,” he says.
As a result, it is the straightforward applications which can be brought into production that are usually built in-house.
By contrast, says Maltais, more complex systems and those which require specialised technologies and investment business know-how can benefit from the expertise and economies of scale embodied in software packages provided by vendors.
One consideration that buyers might sometimes overlook as part of their decision-making process is the velocity of their organisation’s growth; a software package that runs well on some architecture may suddenly become very slow as the business expands.
“It is not unheard of for clients to spend countless dollars internally to build a system, only then to go to the market a few years later because they need a complete re-write due to scalability issues,” says Maltais. “If they bought the system in the first place, their growth would still be unencumbered.”
Flexibility and product change
It is clear that the more unique a firm’s requirements are, the greater the drivers will be to build in-house.
Maltais says this is mainly due to the fact that customising software involves a lot of operational risk. Plus, given that vendors tend to provide one release at a time to clients which are all on the same platform, it is impractical for the vendor to customise its product to each client.
What the wealth or asset manager should look for is software that’s flexible enough to fulfil their requirements, he explains. At the same time, he adds that the vendor shouldn’t have to adapt its product with complicated scripts and other workarounds. Rather it should be all fully configurable within the software package with mouse clicks and standardised screens, built in already without any cheats on the software itself.
“This is another reason why a mature, stable, standardised software product that’s well tested in the market is the first thing to look at when building a shortlist of vendors to evaluate,” says Maltais.
An alternative to customising the software package, for example by building workarounds and scripts, is the technical workflow re-structuring to fit the underlying business needs. However, says Maltais, this often proves to be expensive and requires really good expertise on both sides.
“The reality is that throughout the years, several tweaks may have been added within the manager’s production environment,” he says, “including tweaks that might have been forgotten about and become the norm over time. The question is to find out whether or not the requirements are really core or simply legacy.
Time
Developing software in-house will always be perceived as being more time consuming and involving a lengthier process compared with buying it.
Maltais adds that it is also important to consider the implementation and consulting process – the project lifecycle around the software product.
“A key element for being able to deliver on time is to get the commitment of not only the vendor but also of the internal sponsors,” he explains.
Risk
Some of the risks that an organisation can avoid when using packaged software products include the risk of not being able to complete the in-house project, budget constraints, and staff turnover resulting in the loss of the expertise.
Yet buying a software package introduces vendor risk, also called “counterparty risk”, adds Maltais.
“The manager must make sure that the vendor is of a certain size, potentially bigger than the buyer’s own business,” he says. “That ensures the counterparty will still be in business despite changes in market conditions.”
Other risks to identify, he adds, include the capabilities of the vendor regarding documentation, support staff, maintenance time and responsiveness.
Client support
Effective and comprehensive client support from the vendor is a further fundamental factor in determining the viability of buying a software package.
According to Maltais, documentation, response times, level of expertise and language skills are all key factors to consider. “Whether the staff are located in the same country, walking distance away or a taxi ride from the client is also a simple and fun question for the buyer to ask,” he says.
Director, Sales & Business Development, Global Exchange, Software Solutions, Asia Pacific at State Street
More from Frank Maltais, State Street
Latest Articles