Banks run on IT. Yet as they transform themselves through technology, many remain awash in outdated code and system architecture that needs constant support. Think aging middleware and bespoke trading and lending systems.
The result is a growing load of technical debt — and no payoff in sight. But by reducing the debt through a combination of rigorous decision making, sunsetting and modernization, financial institutions can maximize the business impact of their IT spend.
The Business Value of Paying Down Technical Debt
Every banking CIO acknowledges technical debt is an issue. But many view it as an important topic rather than an urgent one, and its reduction is often seen as an exercise with no business value. The thinking goes that if few end users will experience a difference when outdated systems are refreshed or cleared away, why bother?
The answer is that while some amount of technical debt may be useful — for getting strategic projects to market faster, for example — incurring it on an ongoing basis isn’t. For one thing, the “interest” on technical debt is steep: Large financial services organizations spend approximately 20% of their IT budget to keep current on product changes in underlying applications, middleware and hardware, or nearly $90 billion per year worldwide.
For another, technical debt presents substantial risk. The programmers who know the systems are often long gone, and when only the compiled code and not the source code remains, maintenance and changes are difficult or impossible.
The First Cut is the Deepest
Reducing technical debt is a straightforward exercise with a tangible outcome: the liberation of budget dollars for the IT initiatives that are competitive differentiators.
Here’s a five-step plan that borrows (pun intended) from the financial concept of debt, which banks can use to immediately bring clarity and intention to the process.
Stop adding to the debt.
The first law of holes is to stop digging. In the case of technical debt, that means calling a halt to non-strategic, usually decentralized IT decisions. But putting the shovel down is harder than it sounds. Business pressures on a matrixed IT organization make it difficult to resist well-crafted marketing messages from IT vendors.
Establish enterprise-wide governance from the CIO’s office to make the right long-term decisions regarding technology policies and options. It’s not uncommon for banks to launch technical governance but watch the effort fade after an organizational change or two. The oversight of technical debt reduction is about being a responsible steward of the bank’s business. Play the long game.
Other best practices for decision making includeletting software drive business processes, rather than the other way around. Banks’ preference for customizing IT systems to meet business processes — and the resulting challenges of forward compatibility and upgrades — is a major cause of long-term technical debt. While there may be valid instances in which customization is needed, they’re rare given the wide range of standardized software available.
It’s also important to avoid vendor lock-in. To break down the walls that typically separate banking lines of business, make decisions at the enterprise level. Select and enforce the use of single tools for common enterprise functions, such as data extract, transformation and load (ETL); backup and recovery; and cloud containers. Standardize on common languages, operating systems and architectures, and develop the list of approved technologies with an eye on forward compatibility.
Evaluate what to keep.
Once you’ve stopped adding to your technical debt, you’ll need to determine which software and systems you want to replace. Objectivity is key. Remember that you’re not successful at ending technical debt unless the technology is switched off and put in the bin, metaphorically speaking.
Evaluation requires hard decisions. Large banks often view heavily customized or custom-built systems as a competitive advantage and are reluctant to part with them, even given the long-tail cost of servicing. One bank we worked with maintained several niche systems, including one that supported fewer than 100 end-customers.
Create a senior team to examine candidates for elimination, based on the criteria in Step 1. Add finance specialists to create a business case for each viable action. Then rank the list by priority, including which actions may be accomplished in groupings. This is your opportunity list.
Make a budget.
You don’t want to be paying interest forever, and that requires a realistic plan you can stick to.
Create a budget to act on the changes that present a positive business case. Develop a multi-year plan for spending — either in monetary terms or in percentage of IT budget — to reduce the technical debt “principle.” The plan will comprise projects from the opportunity list. One opportunity might be consolidation of physical storage onto a single type for each storage tier, for example, or standardization onto a single messaging middleware.
Consolidation of a core platform is another possible opportunity. Because large technical-only programs often fail due to being starved for funding, it’s important that the program budget be jointly managed by senior business and technical stakeholders.
Measuring success is relatively straightforward. The banking industry has good project metrics and is adept at measuring business cases. What’s more, by branding debt-reduction initiatives, banks can elevate the program’s profile within the organization. For example, after measuring the business case impact, one large financial firm created what it called the “Building Block Program” for a corporate-wide reduction in duplicative systems, processes and tools.
Key performance indicators for technical debt reduction include projects completed as well as dollars saved and realized against business cases. Because debt reduction is a long-term project, the establishment of quarterly reports is essential for tracking tactical success. It’s also important to include the status of debt-reduction metrics in periodic financial reports, at least internally.
Getting out of debt is an accomplishment. As with any multi-year project, you’ll want to take time to celebrate key milestones along the way. One banking client hosted a team recognition party after the completion of 10% of the project’s volume. The idea was that once a project is at the 10% mark, most of the complexity has been worked through; the rest of the program is simply execution, and that’s cause for celebration. Another team event featured a session to “walk in each other’s shoes.” Celebrations are as much about team building as they are recognizing milestones. A motivated and unified team is a powerful force.
It’s always the right time to get out of debt, and technical debt is no exception. It’s important to address this topic as a steward of the business. It’s the right thing to do for your customers and shareholders, and for those who come after you.
This article was written by Gordon Hoff, a Vice President within Cognizant’s Banking & Financial Services Practice.