DEVOPSdigest

The past decade has seen digital transformation change nearly every aspect of our lives, and banking has proven no exception. Indeed, as per proprietary data from Avoka, in mid-2017, mobile overtook desktop as the most popular channel for applying for new deposit accounts at a top 10 US bank. Banks have accordingly ramped up their IT departments and technology investments to adapt to this brave new world and digitize their offerings, with the aim of making their financial products just as accessible and convenient for application as products offered by tech customer service giants like Amazon.

The push to make banking products digitally ready (and very quickly) has spurred the old “buy vs. build” debate in bank IT departments: Should we build our own digital onboarding software from scratch in-house? Or do we buy off-the-shelf solutions from third-parties that may be generic and not customizable to our brand and product offerings? And while this dichotomy may have been a suitable mentality years ago at the start of the digital transformation revolution in banking, it simply no longer fits with the reality of today's more complex development landscape, and is starting to cause significant problems in bank IT departments.

It's no mystery that the majority of today's banking IT projects use elements of both “build” and “buy.” But banks tend to opt for the build option in the main, reasoning that in-house development drives better outcomes. But this is a serious misconception — recent research from Forrester shows that over half of all banking customer experience projects take longer than expected, leading to a blown project budget an overwhelming 88% of the time. Critically, projects using or re-using internally-built components are far more likely to suffer these issues.

This inevitably leads to a spiralling build up of technical debt — a concept that banks should familiarize themselves with and treat just as seriously as actual debt (after it, it ends up in the bottom line — total cost of ownership is higher for internal builds around 64% of the time, as per Forrester's research). A snowball effect takes hold: projects with problematic delivery are far more likely to require endless catch-up fixes and high maintenance costs, draining time and resources from the development team that could otherwise be put to use on the increasingly crucial work of updating the offering to meet the continually evolving needs of the market and customers. On average, one third of customer-facing software releases are updated only once a year or less, a number that rises closer to half for projects that are over-budget.

Forrester's research shows that this isn't a matter of under-resourcing — teams report being allocated the right amount of time and resources. Rather, stumbling blocks stem from architectural inflexibility and poor technology, as well as changing business priorities sapping stakeholder enthusiasm and project velocity.

Neither build nor buy, in the older sense of the two approaches, provide an adequate strategy for today's development environment. The aversion to buying mainly took hold during a period when third-party products were fairly self-contained black boxes — off-the-shelf offerings that provided none of the flexibility of in-house and came at a cost to branding. This is now, however, no longer true of the third-party vendor landscape.

The advent of platforms and APIs means that it is now far easier for banks to bring in multiple fintech integrations to fill the gaps in their offering in a modular, mix and match manner — all fully customizable, extendable, flexible, and capable of being brought together on an organized, neat platform.

Banks need to embrace this change and ditch the old buy vs. build debate that so often prioritizes internal builds as a knee-jerk reaction. The constraints of the old build or buy choice means that the tendency is still to think of digital transformation as a series of off-one projects — when the most successful efforts treat it as a holistic, continuous evolution. After all, customer needs and expectations are constantly evolving, and so should customer-facing software.

So, how should bank development teams and their stakeholders approach a new digital transformation project? The answer lies in BBEA: Buy, Build, Extend and Assemble. The rule of thumb here is that where services and capabilities are generic and not unique to the bank, they should be sourced from expert vendors with a proven ability to get the job done quickly and in an expert manner (why incur a longer development cycle and higher TCO by re-inventing the wheel and building internally?). This frees up the bank's own internal resources to work on building elements that are truly unique to the bank's value offering. While it used to be prohibitive to pursue both of these approaches simultaneously, this is precisely what the new world of APIs and platforms enables.

Sourcing and extending components in this way reduces technical debt significantly, and spreads the cost of R&D across external players. The platform approach makes it far easier for banks to tailor these external components to their own brand and specific circumstances, and makes adaption to changing future needs far less onerous, removing the tendency to revert to big and costly start-from-scratch projects on a regular basis.

Banks that want to get ahead in their digital transformation strategies must their ditch old development habits and embrace the new platform approach. Buy vs. build is dead, long live BBEA.