Operational Resilience In A Complex Legacy Technology Estate
Drafted by Ben Saunders
The typical enterprise financial services firm runs on a large and complex array of technology. If you look hard enough, you’ll find almost every vendor, programming language, and architectural pattern which have been deployed and layered on top of one another over many years.
Purely from an application perspective, there are usually thousands of vendor and bespoke applications deployed across the enterprise. These will of course be integrated with other systems through various point-to-point integrations and data exchanges. This big ball of spaghetti will be replicated within multiple development, test, disaster recovery, and production environments giving us an enormously complex application landscape.
Underlying these applications will be an equally complex set of middleware, supporting services such as databases and messaging technology. And below this, we will find physical infrastructure providing compute, network and storage. All of this can be equally complex, diverse, and heavily integrated.
All of this hardware and software will be aging with each passing day, and constantly approaching end of life or end of support. IT functions are therefore engaged in a constant effort which takes enormous manpower and cost simply to patch, upgrade and refresh this technology in order to stand still. In some instances, the battle is lost simply due to the amount of work required. In others, the software will have fallen out of support, or the original developers gone out of business or long been acquired. They have to be maintained on a best effort basis and will be adding risk to the firm, introducing new and complex challenges on a frequent basis.
There is also a supplier overlay to this, with a range of third and fourth parties being involved in providing this hardware and software. Almost everything will be sold by some vendor, who will have different contract terms, support agreements, and service level agreements (SLA’S).
As the leader of a financial services organisation, how should we look at this picture described above when we are trying to enhance operational resilience? To take one example, a banking executive we spoke with recently outlined that they have:
700 Business Services
Over 1000 systems in the bank
Over 2000 suppliers
This particular bank had a degree of knowledge about the relationship between business services, systems, suppliers, SLA’s etc. However, the data was spread across multiple siloed systems, was disconnected, and didn’t allow them to answer operational risk questions to the degree that regulators are increasingly demanding. For instance, some of the questions we would find it hard to answer include:
Which particular business services lines were dependent on which systems
Which systems were dependent on which suppliers
What are the SLAs required from business services
What are the SLAs offered by suppliers
The Operational Resilience agenda is about improving this. Firstly, improving the data, then making it more transparent so that decisions are constantly taken, then finally mitigating operational risks.
At OpRes, we focus exclusively on this problem. We begin by cataloguing the information required. We bring it into a centralised database and surface the views which allow leadership to consciously choose their accepted risk posture and have this information surfaced to them. Finally, we help with a mitigation strategy based on regulatory requirements.
