The Rock and the Hard Place

The refrains of tough times and shrinking budgets are common ones in discussions around financial services IT. Every time, honestly, every time I speak to any architect, developer or senior manager from a major bank, the story is the same. Pre-2008, the industry was awash with money, and IT was built along business lines, even sometimes by asset class.

Now, the money just isn't there to service this enormous real estate (and maintain it). Tech bosses are under tremendous pressure to find equivalencies and common usage between platforms, but it's not always as simple as that, there are psychological barriers to overcome, and the fiscal firepower at their fingertips is nowhere near what it used to be, relatively speaking.

Ill Suited
The first issues are always basic ones. Software designed for a specific task is designed for a specific task─longevity wasn't always in the minds of developers who were paid on delivery, or even the ones who coded a program to assist with day-to-day tasks and couldn't have anticipated that it would need to be extended. The architecture, therefore, is unsuited to adaptation. Likewise, if that particular person has left, their idiosyncratic method of coding may be impenetrable to others, all of which leads to cost in terms of dollars and hours.

Also, people are generally unwilling to work on things that they didn't make themselves, and if a highly-qualified specialist's time is being taken up with making things run rather than development, it can lead to attrition. We all talk in idealized ways about holistic, enterprise-wide systems, of breaking down silos and achieving efficiencies through mutualization, but in reality it's a hard process. It takes resources to save resources, which aren't always there. In another way, as well, building systems to bridge silos without completing the task can just lead to a more jumbled infrastructural landscape.

Future Proof
So what can be done about it? Sometime, the key is just to press ahead. But more, the question is being asked about how a system in development now will benefit the bank in five years' time. I had a conversation with a senior developer at one of the UK's largest banks this morning, who used the phrase ‘building a bank for the future', which seemed appropriate given the content of today's Editor's Letter. Likewise, allowing skilled technologists time away from the job to experiment with new concepts and work out whether a bank is going through a black hole in its development cycle is key, although understandably, the costs involved in letting technical staff have a Google moment and take 20 percent to essentially be mad scientists may not be possible for everyone.

We all talk in idealized ways about holistic, enterprise-wide systems, of breaking down silos and achieving efficiencies through mutualization, but in reality it's a hard process.

Ultimately, it's a hard landscape. Technologists are being asked to do the impossible, but with one hand tied behind their back and one eye on the end of the road. Now, more than ever, it seems essential to have a view of what lies ahead while dealing with what's in front of you.