CloudBees announced the integration of CloudBees’ continuous delivery and release orchestration solution, CloudBees CD/RO, with Argo Rollouts.
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.
amazee.io, a Mirantis company, announced that its fully-managed application delivery platform is available in AWS Marketplace.
env0 secured an additional $18.1 million of funding to conclude its Series A investment round with a total of $35.1 million.
Planview announced a new strategic collaboration with UiPath. The integration is designed to fuse the UiPath Business Automation Platform with the Planview Value Stream Management (VSM) solution Planview® Tasktop Hub.
Noname Security announced major enhancements to its API security platform to help organizations protect their API ecosystem, secure their applications, and increase cyber resilience.
Mirantis announced the latest version of Mirantis Container Cloud -- MCC 2.23 -- that simplifies operations with the ability to monitor applications performance with a new Grafana dashboard and to make updates to Kubernetes clusters with a one-click “upgrade” button from a web interface.
Pegasystems announced updates to Pega Cloud supported by an enhanced Global Operations Center to deliver a more scalable, reliable, and secure foundation for its suite of AI-powered decisioning and workflow automation solutions.
D2iQ announced the launch of DKP Gov, a new container-management solution optimized for deployment within the government sector.
StackHawk announced the availability of StackHawk Pro and StackHawk Enterprise for trial and purchase through the Amazon Web Services (AWS) Marketplace.
Octopus Deploy announced the results KinderSystems has seen working with Octopus. Through the use of Octopus, KinderSystems automates its software deployment processes to meet the complex needs of its customers and reduce the time to deploy software.
Elastic Path announced Integrations Hub, a library of instant-on, no-code integrations that are fully managed and hosted by Elastic Path.
Yugabyte announced key updates to YugabyteDB Managed, including the launch of the YugabyteDB Managed Command Line Interface (CLI).
Ambassador Labs released Telepresence for Docker, designed to make it easy for developer teams to build, test and deliver apps at scale across Kubernetes.
Fermyon Technologies introduced Spin 1.0, a major new release of the serverless functions framework based on WebAssembly.
Torc announced the acquisition of coding performance measurement application Codealike to empower software developers with even more data that increases skills, job opportunities and enterprise value.