A CIO once described his role to me as follows: he has a piece of rope that at one end is being braided together and at the other end is being undone. For every system that he ties into a central strategic architecture, others are being built on a tactical basis to cope with day-to-day problems. The problem never goes away, it just moves. To change this situation requires a change in the way that systems join together and this been the motivation for developing service-oriented architectures (SOAs).
Between 2000 and 2004 there was a change in appetites. Tough market conditions made cost reduction the mantra of the financial services industry. The relaxed attitude to technology spend was gone.
Cutting costs proved harder than expected, however, with various system implementations within business silos independently requiring maintenance. The haywire mass of cabling and middleware that tied all of the past five years’ purchases together was considered virtually untouchable. The need to simplify was realised – reuse components, test each component once, build new systems in a structured way that followed a strategic rather than tactical view, understand what exists and measure it. The result was the development of SOA.
The SOA approach has been developed for specific business needs in times of hardship and, like many things that come from hard times, it is likely to endure. Through componentising the parts of a given system, replacement of legacy technologies will no longer be an impossible feat.
Core banking systems could now be made practical and innovative, easily deployed, upgraded and adjusted. Channels can be genuinely integrated, allowing data to be shared between systems. You may be asking ‘Why don’t we have one?’ Well, as we point out throughout this special supplement, this has to be led by the chief information officers at the bank, not built up in yet more silos by lines of business. It is a major undertaking, requiring a long-term programme of architectural change.
In the near future, banks that have taken on cost to redevelop their architecture will find themselves ahead of the game; the banks that have not will be facing cost difficulties at the same time as they face the risks involved in re-engineering their systems.
Dan Barnes, Technology Editor
