As technology has evolved to meet the needs of digital banking, the software development process has likewise become more complicated. Buy vs. build has become buy, subscribe, build, and integrate, potentially all at once. In the 2020s, IT executives must make choices and tradeoffs, maximize benefits, and minimize risks as part of a complex web of decisions when embarking on the software development journey. My latest CIO/CTO Checklist report on banks’ software development choices, published on February 9, serves as the IT leader’s manual for navigating the multilayered decision-making process.
Consider the cloud type: public, private, or hybrid
When it comes to the cloud, there are public, private, or hybrid options. Almost all banks use the cloud today, and many use multiple types of clouds. Public clouds are open to all companies that pay for access; infrastructures are shared among consumers. Private clouds are restricted to a specific company and exist behind a firewall, so third parties must be permissioned to access them.
Because so many solutions on the market today are cloud-hosted, IT executives should take the cloud type into account during the software selection process. While private clouds can be expensive to build, the limitations of public clouds can result in cost implications down the line. On the other hand, hybrid clouds built using containers serve to safeguard longer-term flexibility.
Evaluate strengths and weaknesses of software types
Several types of software are available on the market today, including cloud-based, hosted, and managed service solutions. When weighing their options, banks should consider the long-term costs and talent needs as well as the security and scalability capabilities, which also vary. Caution is necessary with open-source solutions, as they appear to be free but can be susceptible to hidden licensing fees if they incorporate code from a vended product. In-house services can cause difficulty down the line if the employees operating the software leave, taking their knowledge with them.
Mitigate solution provider dependency risks
Package solutions or Infrastructure-as-a-Service, (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS) all risk solution provider dependency. IaaS, PaaS, and SaaS limit visibility into solutions’ workings, so package solutions could mean vendors control the security measures that banks are ultimately responsible for. Banks should request results from audits and other third-party security assessments before committing to working with a vendor. If a package solution is chosen, it’s also important to enact risk mitigation procedures to cover areas including source code escrow and security controls prior to implementation.
While useful information can be obtained from a solution provider or other third party, these parties’ interests may not align with those of the bank itself. IT executives within the bank must be involved in making the decisions that will affect the bank for years to come.
The foundational transformation of core systems and surrounding technologies during the early 2020s affect all CIOs, CTOs, and heads of architecture whose financial institutions have adopted digital banking processes or components. The decision-making process around any software selection has become more complex and trickier to navigate. My latest report equips executives with the concepts, considerations, and market knowledge that are key to successful development. Click here to view the report webpage and email me at [email protected] to find out how you can get access.
