The document discusses the issue of "technical debt" that banks accumulate over time through mergers and acquisitions, outdated systems, and other factors. This technical debt results in high costs just to maintain existing systems, leaving little budget for innovation. Three options are proposed to address technical debt: 1) refactor platforms from the ground up, 2) liquidate or sell banks, 3) move information technology and operations functions out of banks by using cloud computing or outsourcing models. The panel will focus on these options for transforming banks' operational platforms to compete amid new industry threats.

1. Opening Address at The Asian Banker 2014 Panel on Banking
Infrastructure Management
Eric Tachibana
According to The Financial Times, most of us spend up to 70%
of our total technology budget supporting keep-the-lights-on
(KTLO), just maintaining what we already have. Add to that the
need for additional spend in support of the regulatory portfolio
however, and you get little or no budget left for any new
development.
And so, after lots of promises about CIOs becoming partners
with the business, in my experience, CIOs across the region
are not just looking like cost centers, but actually have become
business disablers.
So why does it cost so much to simply run our platforms?
Well, the answer is Technical Debt, a metaphor proposed by
Agile maven Ward Cunningham to express natural, systemic,
platform inefficiencies that corrupt technology platforms over
time.
WHAT IS TECHNICAL DEBT?
You’ll all be very familiar with all of these day-to-day examples:
 Redundant but un-retireable software systems – we have
2 or more systems that are 95% redundant in functionality,
but because of the 5% difference, we are not able to retire
them and we end up spending 200% of the cost.
 Highly complex and fragile production environments that
nobody wants to touch out of fear lead to incredibly slow
and expensive Change Governance processes

2.  High technical bench risk and reliance on specialized,
end-of-life technology and people skills means that we are
at the mercy of vendors and specialists.
To be fair though, it’s important to appreciate that it’s not really
the fault of CIOs. Technical Debt is a natural process and the
mess that results is probably unavoidable.
WHY DOES TECHNICAL DEBT OCCUR?
For example, in our industry growth through M&A is extremely
common. However, while potentially creating great business
synergies, almost all M&As create deep and complex
redundancies that undermine multi-year Enterprise Architecture
plans because.
In addition, because of all the casholah, our industry exhibits
significant internal political power of high growth business lines.
This means lots of good decisions for lines of business that are
bad decisions for the firm as a whole.
Further, coordinated Enterprise Architecture is freakin’ hard in
big firms. Lack of fidelity of Enterprise Architecture strategy up
and down the chain in a very large distributed organization has
chronic telephone operator problems. What’s agreed at the top
is rarely understood / executed 3 or 4 layers below.
Finally, the increasing pace of software and hardware
obsolescence and outsourcing adds significant complexity.
WHAT IS THE IMPACT OF TECHNICAL DEBT?
Unfortunately, as we’ve said, Technical Debt has severe impact
to the cost base and to the business:
 Extremely high and growing cost of KTLO
 Loss of productivity and staff morale
 High testing costs
 Release speed goes to zero

3. This effect was less obvious before 2008 because our
businesses were growing and the front office could simply stuff
the holes in the roof and floor with hundred dollar bills. But at
this stage, with the very core of the banking business model
under siege, no firm can afford to service this debt any longer.
And by the way, this idea that regulatory requirements are
making the banking cost model untenable is the great industry
whine. And I don’t mean wine, like in red or white. I mean
whine, like the tantrumy brat in the supermarket checkout line.
Regulatory requirements are not the problem with the industry
cost base. The problem is that we are all sitting on top of a
smelly heap of operational doggie doo doo. The Regulatory
stuff is thrown out to distract shareholders from eroding
margins that are systemic to, and permanent in, our industry.
WHAT DO WE DO?
Historically, the approach to solving this problem has been
multi-year strategic Enterprise Architecture Simplification
Projects where you slowly evolve the platform towards a target
state. However, I would argue that this “servicing the interest”
approach, which would normally be sound advice from a CTO,
is insufficient today because of the industry disruption that we
face.
We are in the midst of a profound shift in the FSI market with a
proliferation of new direct competitors (small emerging banks
starting from the ground-up), substitutes (like Alibaba, whose
deposit base already compares to any global retail bank) and
wild cards like Bitcoin, PayPal, P2P lending, Crowdfunding, etc.
What makes these players so frightening is not their technology
or their vision. Honestly, when we look at the new competitors,
we’re not really talking rocket science here. Bitcoin is probably
the most challenging technology and business model out there
today, and frankly, even Bitcoin does not compare to something
like high-frequency trading or trade finance workflows – really
hard things that we know how to do well. Rather, what makes

4. these competitors scary is the fact that they completely lack a
legacy platform and can spend 100% of their revenue on
innovation, growth, and marketing. That’s the big difference.
Anyone familiar with Clayton Christensen’s Innovator’s
Dilemma will recognize this moment as a classic industry
disruption event – and should appreciate that incrementalist
platform strategies on the part of the incumbents just lead to
extinction.
I would like to propose that as an industry, and more precisely
as a community of CTOs and CIOs, our only real, sustainable,
defensible options are as follows:
First, we could pay off the debt. That is, we could refactor the
platform from the ground up. This option is probably politically
unfeasible and would require incredibly charismatic and
powerful leadership.
Second, you could liquidate the business - close down or sell
out while shareholder value remains. In fact, I think we’ll see
another massive round of consolidation starting in 2016.
Finally, we can redefine our business models by moving KTLO
out of our operational view. That is, we take IT and Operations
and we literally move them out of the banks. Such a
transformation can be enabled by Cloud and/or a post-ITIL
forms of partner ecosystems that looks more like Toyota in the
80s and 90s.
I’m personally in favour of #3, however, I appreciate that I’m
being sensationalist in order to have a fun panel. So the
panelists are welcome to take me to task. Over the next hour,
I’d like to focus on this topic. What options do we have to deal
with Technical Debt? Given the severe competition we are
facing, how can banks transform their operational platforms to
be competitive?
Thank you!