Software archaeology and financial contact centres

There's an interesting (and brief) post on Grady Booch's IBM blog that got me thinking. Grady Booch, for those unfamiliar with him, is an IBM's Chief Scientist for Software Research but perhaps more importantly developed UML (Unified Modelling Language) and was very influential in the development of Object Orientated programming. I've seen him through my time at IBM and through the BCS (British Computer Society) and I find he always has something interesting to say on IT.

His particular post this week was on the first signs that 'software archaeology' is emerging as a discipline. I think this is long overdue as alongside Enterprise Architecture, management of legacy software is one of the biggest challenges in modern IT.

I've met this challenge regularly when working with financial services customers and it's been well documented (see Silicon.com on the subject last year). The financial services industry was (and is) a sector that understands how IT can bring efficiency and so adopted automation early on. The problem is that today this can mean an environment of very mixed and some quite elderly systems. What makes this challenging is that as business requirements change, an elderly system than ran quietly on its own in a corner might now need to make it's data available to other systems. Even more challengingly, in an SOA type of architecture it may not be easy to predict which combinations of systems they might be.

It's at this point that the project team usually discover that the documentation for the legacy system is incomplete and that most of those in the organisation who could have helped fill in the gaps have taken early retirement. This means that ripping it out and replacing it is not possible. One option is to bring back these retirees as consultants but this expensive and often not practical. The other emerging option is to do some software archaeology to understand what processes and dependencies are actually in the legacy code.

This has been one of the major challenges I've found in the financial services contact centre. The agents, often young or from a non-IT background, expect either a Microsoft Windows type desktop or a shiny, new Facebook style web 2.0 interface. Instead, they find themselves learning from scratch how to deal with OS2 or 3270 terminals and green screens. This has big impacts on agent productivity and training costs. It's also a long way from the type of technology I was blogging on in: "The future of contact centre - Google, Salesforce, Skype & Microsoft".

Unfortunately, though, if the business logic for something like a life insurance policy is embedded in legacy code, and there is no documentation, then that system has to be kept running. As long as there are customers who could make claims (and that's potentially a 30+ year horizon for life insurance), then the organisation has to be able to manage them under the Ts&Cs of the policy and that means keeping the system as it is as there is no other truly reliable source of the information.

It may not be an expected outcome of software archaeology, but one of the big benefits it could bring is for the call centre agent in financial services. A more easily integrated desktop and presentation layer would help agents find the information they need far more easily. I've seen agents in one bank running three monitors each (and having to type out each piece of information the customer gave them three times to get it into into each system) because they couldn't integrate the various system interfaces.

Software archaeology may initially be focused on the back-end and legacy, but could become very important for the contact centre.