Unlock Your Potential

One of the problems we in the financial services community face is the fact that we have the largest amount of bespoke software and systems of any vertical. While other verticals have the luxury of being able to apply an almost ‘vanilla’ application strategy – buying functionality out of the box, using new developments such as web services and utility computing – the banking, financing and stocks (BF&S) market is the last bastion of the large in-house development groups. If the business needs a new process or function, the technology groups build it for them.

This is a double-edged sword. Yes, it provides the capability for business differentiation in a cut-throat market, but it also constrains the capability of the business to update the homegrown code with the latest standards, to move to the newest technologies, and increasingly to adopt more effective infrastructural architectures.

For most BF&S companies, these homegrown systems are not something that they are ashamed of; the majority of these applications may be 5-10 years old, but they still do what they were designed to. They support discrete processes around offerings that the company made at the time, and while these offerings may no longer be offered to new customers, they still need managing for the existing customer base. Simply continuing to run such applications on the boxes they were built for, in the way that they were developed, is low cost. Attempting to change anything could bring in errors, and has a definite baseline cost that could make what is likely to be high margins on the product suffer or even disappear.

Identifying the problems

A compounding problem is that the large amount of merger and acquisition activity in the sector means companies gain new ‘heritage’ systems on a regular basis, at a time when they are under pressure to lower the combined cost basis of the merged companies.

It would seem there is little requirement for the BF&S community to move these ‘heritage’ applications into a more up-to-date environment. It is, however, possible to bring these applications to a position where they can interact with other applications – even to a level where the older application can act as a ‘peer’ in a service oriented architecture.

With the average number of customer databases in, for example, an insurance company being in the high 10s, it becomes difficult to maintain an overall view of what the customer is actually up to. If a customer view cannot be created across all the available product databases, then we may be mistreating high value customers or over-providing to low value customers. We don’t know what we can cross-sell, or with products that are approaching end-of-life, what we have available to up-sell the customer on to. We can’t easily carry out predictive analysis because if we don’t have a common architecture supporting our business processes, then we can’t compare like with like to look even a little way out to the future.

Human support no longer available

More worryingly, we have sets of applications that we can’t fully support if we do find that there is a problem. Many of these systems that have been grown in-house no longer have any of the human skills left in the company, and it’s only when we come against a problem that we find out how poor the original documentation is.

And finally, we have the problems not only of governance and audit that everyone else has come up against, but the continuing and changing need to report through to the FSA against mis-selling accusations, whether the customers are being adequately informed of the state their investments/insurances/mortgages are actually in, and the choices that are available to them. When this is combined with the existing and incoming issues of areas such as ISO17799, Solvency2 and others, it is important that we are able to easily, rapidly and effectively report across the whole of the existing datasets that we have at our disposal.

Does this mean that we should be looking at ‘rip and replace’ in order to gain the open standards and virtualised environment we need to facilitate reporting? If it did, would it be possible within the pressures and constraints of the BF&S markets and business pressures? No. Taking out all the old systems and replacing them with new just does not make sense, neither at a technical nor a business level.

So, what can be done? ‘Investment optimisation’ is the clarion call of the powers that be, and this is echoed by many in the vendor community who realise that it may take a little longer for the BF&S sector to move into fully modernised, standardised technical architectures than, say, hi-tech or fast-moving consumer goods/consumer packaged goods (FMCG/CPG).

Bringing old IT into the 21st century

First is the need for an asset evaluation. Is the application already there really doing the job that we want it to? If it is, we may want to look at how we maximise the return on investment from that application. If it is meeting requirements, but only just, then we need to air-lock the application while we look at how it can be migrated through to a newer environment. If it is failing to meet our requirements, then we must concentrate on replacing that system as a matter of urgency, as it is these under-performing (or non-performing) applications that are sapping our technical, financial and business resources. With around 70 percent of IT budgets spent on remedial and maintenance work, applications that are struggling to deliver are not only a distraction, but are also preventing us from investing in other necessary new technologies.

For those applications that are still viable, we need to examine how we can adapt them to fit with our overall business needs. Luckily, there are many vendors and systems integrators out there who would be happy to take your money. Many are actually capable of doing a pretty good job in bringing the old solutions into a position where they can be accessed and utilised as if they were (almost) fully compliant, standardised new applications. These solutions vary, starting with the relatively simple means of screen scraping – in other words, taking the output from mainframe and midi-computer systems that would normally be front-ended by textually-based terminals (commonly known as ‘green screens’, even though many of them will have blue or amber screens) and grabbing the content of the defined fields so that they can be presented through more modern means at the front ends, generally through web-based interfaces at a PC.

This can provide a means of modernising the use of an application, but doesn’t do much for the provision of fully integrated data analysis against all the possible back-end systems. Neither does it provide much in the way of modernising many of the existing bespoke client/server applications within a company.

Two other approaches

Next is the use of direct connectors, which involves writing pieces of code that enable defined connections to be put in place between existing applications and new applications. This provides a means of accessing existing data sources, and if these connectors fully understand the data structures of the existing applications, we can start to bring the back end data stores into play through data transformation techniques.

Another option is ‘wrappering’ – taking an existing application and analysing it, and then creating bespoke connectors that enable the standardised infrastructure to talk to the less-standardised applications, with the connector dealing with translating information to and from the older application. Most wrappering these days is aimed at creating a set of web services that are then call-able directly from other environments. This enables far better integration at a business process level, and can not only enable investment maximisation of existing applications, but can enable new applications to utilise the existing services of these applications, thus minimising investment in new applications.

Finally, is an enterprise service bus approach, based around the use of application servers – in essence, bringing all the above together as a holistic solution. This provides the basis for a fully modernised base infrastructure, while enabling fully functional connectors to be utilised to provide bi-directional service-based interaction between the new architecture and the old applications. With this approach, it is possible to see where there is functional redundancy (i.e. where we have the same functionality being carried out by multiple existing applications), bring this functionality out of the older environment and recreate it as a callable service in the new environment. This then enables us to use the hardware in the older environments to support the workloads that we want – the transactional workloads – rather than the service workloads that are better served on newer, often commodity, hardware/software platforms.

By moving as far as possible to an integrated environment, we gain the advantages of virtualised data access, and therefore the ability to report against what is really happening within the company. We also gain better capabilities for governance and audit, as the majority of the environment is now connected, we can utilise common tools to track and measure events, and to trigger alerts when things aren’t going quite as the business would like.

The trend towards outsourcing

Of course, for many BF&S companies, this is a big step, and many of the skills required to move forwards are not available in-house. It has been no surprise for us at Quocirca to see the BF&S community move towards outsourcing, bringing in the skills from external companies that specialise in modernisation and flexible architectures, and using them to implement and then support the resulting environment. But a warning on this: it is critical that you keep the business, and therefore the overall technical strategy, in-house. Outsourcing the strategy can lead to the outsourcing company having you over a barrel, and a very expensive barrel at that.

As far as we are concerned, the key for any company in the BF&S sector that finds itself with a mixed environment of old and new technologies is to view it all as a necessary evolution. There is no need to panic and try to move everything through into brand new technological architectures, but to see what must be replaced as soon as possible, what you have is a degree of flexibility as to when it needs to be replaced, and to optimise the usage of those existing applications which continue to meet the business needs. Part of this optimisation is to see how the applications can be integrated into the overall technical architecture so that the business is supported flexibly as the market changes.

Overall, it’s the business that counts. BF&S expenditure on bespoke solutions has historically been high – and it would be a career limiting decision to advise wholesale replacement. Prioritise your needs, and utilise the tools that make the most sense to optimise the investments.

About the author

Clive Longbottom is Client Service Director at Quocirca, a business IT analyst and research organisation supporting clients in the UK, Europe and worldwide. Longbottom specialises in helping companies to understand the core processes in their value chains and the technologies that are needed to achieve real improvements. An analyst for over a decade, Longbottom has worked previously for Meta Group and Strategy Partners before founding Quocirca.