In January 2009, with Halifax Bank of Scotland on the brink of collapse, it was acquired outright by Lloyds TSB. Reportedly the largest merger in European banking history, this instantly created the biggest retail bank in the UK, with more than 25 million customers.

The merger presented the combined bank’s IT organisation with an integration challenge of gargantuan proportions. Between them, HBOS and Lloyds – themselves the result of various mergers and acquisitions over the years – had around 2,800 business applications.

The job of deciding which of these applications should be kept and which should be retired was as urgent as it was enormous, recalls Mike Cox, lead architect at Lloyds’ architecture management division.

That meant making some unpopular decisions. “It was a war, and we have plenty of battle scars to show for it,” he says.

It fell to Cox to build an overview of the banks’ combined application landscape that would allow the organisation to decide what to cut and what to keep.

The process began with asking various departments within the organisations to outline in a spreadsheet the applications and data that they felt they needed to do their jobs.

This would allow Cox and his team to build an architecture that combined all the required information into “a single source of the truth”.

The exercise was fraught with “uncompromising” situations, Cox says, as there were numerous consultants within the organisation, all with their own idea of what their business area should look like.

The simple act of managing the spreadsheets was also a source of complexity. “There were spreadsheets flying everywhere,” Cox recalls. “There were lots of duplicates and data quality issues: software products mistakenly being called applications, that kind of thing.”

Holistic view

To compile a holistic view from these spreadsheets, Cox used enterprise portfolio management software from Troux. He had already been using Troux to manage Lloyds’ top 20 applications, but that was nothing compared with the scale of the integration challenge.

Troux’s software is built on a database of IT systems called a Metaverse, and Cox and team set about populating this Metaverse with the contents of the spreadsheets.

The Troux tools also include a number of pre-built reports and visualisations, to help users construct architecture plans quickly. Unfortunately, the gaps and blindspots left by the spreadsheet collection exercise meant that Cox was unable to use this functionality.

Instead, using their “bare hands and a bit of ingenuity”, Cox and his team was able to build a ‘workbench’ visualisation, which showed the interdependencies between the data and applications in both banks.

“The view I presented was known internally as the Application Landscape view,” he says. “It was completely bespoke, so recognised the way in which we had structured the data.” This visualisation, he adds, “was hung on all of the directors’ walls”.

Armed with that visualisation, the merged bank set about identifying which applications needed to stay – the ‘target’ systems – and which were to be eliminated.

‘Non-target’ applications were treated as data sources, and the data underlying them was integrated into other, pre-existing, sources. Those applications were then either actively decommissioned or marked for retirement at a later data.

If he was to carry out the integration again, Cox says he would start small, refrain from customising Troux and make use of its high-impact visualisations, which he says are three “golden rules” that his team broke when carrying out the integration.

That said, “while we broke the golden rules, we didn’t have a choice and we were successful at the end of it.”