Technology Investment: Challenges and Guidelines
In the spirit of new year resolutions, there is no better time than January to plan and implement a review of processes and take bold steps to help make 2007 the best year yet for the securities and payments business. However, the perennial problems of targeted yet misguided investments into uneconomic areas and continued lack of realisation of automated solutions remain. There are certain key questions that need answering before you proceed with a technology strategy:
The time taken to reach consensus on these issues, and then implement the chosen solution can be delayed and therefore increase rather than reduce project costs. So what practical steps should companies take?
When it comes to buying technology, timing is critical. To get it right requires a subtle mix of personal commitment, being seen as a champion in an organisation, or working through a logical plan with accepted priorities. It may take a leap of faith to convince a reconciliation department that their rulers and highlighter pens may be replaced by an automated application.
Additionally, the benefits of multi-functional systems that not only compare items, but analyse, account and suggest actions using artificial intelligence, and produce full audit trail and electronic mail must become more commonplace.
Automation should be applied as quickly as possible, tackling the root problem of at least comparison checking before building a more functionally rich application. Understanding the problem is the most important factor.
In recent years, financial markets, such as pensions providers and insurance companies, were restricted to selling their own products. Now independent financial advisors are capable of representing a number of companies and have, as a consequence, mountains of compliance and due diligence documents and procedures to contend with that are ultimately designed to protect customers. The growth of the Internet has allowed customers to bypass the personal element where professional advice was considered, as the Internet and television promote online purchases of potentially inadequate types of insurance cover, pension or savings scheme, merely based on price.
In the financial applications markets, small independent suppliers are still very much in force, offering detailed functionality, experience and support and often a refreshing way to perform tasks with cost-effective, small footprint systems.
The last few years have seen a number of major applications companies becoming the hypermarkets of software, buying up rival companies and selling once competing wares side by side.
Certainly choice is a good thing, but does the product always deliver on its promises. Selection is a good thing, but too much can be overwhelming. This problem is found with software, where personal choice and relationship with the vendor become key issues. Look at trade shows and conferences where vendors line up to show their latest functions, in a dynamic market where speed, ease of use, and a growing set of external influences are driving software development. After all, how many ways are there to differentiate entry of key data into financial systems, when screens and rules are common?
Installing software may take minutes. Making it perform to an exact specification may take months or even years. Often this is more a result of the skill of the team implementing the solution, and the firm’s management of each part of the project, rather than a fault in the software itself.
I witnessed two projects first hand, where the same software was implemented in two highly competitive banks, at a similar time. Their experiences could not have been more different. The objective was the same, yet there had been little information or ideas exchange between the two institutions. The installation platforms were admittedly different, but the software was proven on both versions on transaction processing mainframes.
One institution insisted on weekly updates, performance reviews, enhancements meetings and co-ordinated testing, all documented within a shared co-ordination manual. Both the customer and the software house had guidelines and rules of engagement, which saw logical processes and, above all, executive management sponsorship. The importance of the project was never diminished, and everyone associated with it took pride in problem solving collectively, with structured contribution to enhancement requests.
The second institution started out with best intentions. After some management changes, direction was lost within the team. The executive sponsor left, and the project was downgraded to programmer and operator management levels. Tight control and quality procedures were not observed and timescales slipped as extra (untrained) resources were found to fill gaps in knowledge and testing. The collaborative initial project camaraderie descended into a culture of blame and recrimination.
Without an executive sponsor, no department took responsibility as costs spiralled with minimal results. Despite the frustrated efforts of the software house that proposed a return to orderly structure and process with guidelines, milestones and achievable end points, the project stalled to the point where it was not feasible, economic or sound to continue.
This type of project failure is more common than one may think. Project success is not about luck or the amount of money an organisation can throw at a problem, but more down to the skills of the team that install, implement and support any system.
We are constantly hearing about the need to remove and change legacy systems. Many of the worlds’ leading financial institutions still employ legacy applications and hardware solutions, handling large-volume highly integrated transaction processes, running on already amortised mainframe systems. These types of applications are not yet trusted to newer technologies, as the level of integration required to replace the systems can be vastly complex and span whole organisations.
A payments system where millions of transactions are processed per day has true enterprise-wide implications, acting as the heartbeat of an institution. And when regulatory organisations such as CHAPS impose penalties on banks defaulting in their responsibilities to clear transactions within a defined time period, projects to replace such processes must be managed purposefully and carefully.
But what is legacy? The best definition I have come across so far is ‘something that works’! Is legacy a bad thing? Sometimes not, as business does not have to always follow a culture of change for change sake. Perhaps even a two-year-old PC may be defined as legacy, when a new model has a faster processor to handle Internet transactions and the use of Excel for some simple spreadsheets? Is replacing legacy necessary for its own sake or something to be done only when there is a greater attainable prize or goal at stake?
Enhancements to older operating systems appear to be making a resurgence. After dragging reluctant (but financially grateful) Fortran programmers back from retirement for Y2K projects, the power and flexibility of the operating system have never been forgotten. Born at IBM over 50 years ago, Fortran remains in use today in high performance computing applications. Sun Microsystems, building on this legacy, has announced a new open source application to execute and enhance Fortran code. It will have very specialized usage and a new set of programmers adopting its quirks, but this again proves that there is nothing really new, just evolution and adaptation. With its rightful place in IT folklore assured, Fortran seems to defy critics and will continue to drive mission critical applications for some time to come.
For mid to large companies, with the luxury of larger budgets and resources available, development projects may appear to be more easily managed. But what about the significant numbers of smaller companies where Excel is their legacy system? How many times have we seen a collection of tabbed spreadsheets touted as a securities trading, accounting or settlement system. How many traders have versions, releases or a proprietary ‘system’ that compromises security, data integrity and flouts compliance rules?
For small startup hedge funds, there will be a shortage of the required mix of front office, operational, technology, compliance and project management skills as the basic costs of business swallow any thoughts of hefty bonuses and inflated personal incomes. This will inevitably lead to missed opportunities for investing at levels that can support the growth of the business and sustain the risks that beset the industry.
The opportunities can be summarised as building an infrastructure, process and structure into automated solutions that avoid duplication of tasks, replication of processes and disparate systems.
By identifying and managing each element of an IT project and its investment effectively will allow staff to concentrate on doing business effectively in the long term.