(Original publication by Jorge Morlett on LinkedIn)
For DevOps teams at banking organizations, the process of integrating core solutions presents a Sisyphean challenge. Tasks can include assimilating a new entity following an acquisition, constantly managing and updating data systems related to customer deposits, general ledgers and compliance reporting, or supporting new services such as card-free ATM, hands-free banking and instant bill-pay.
What’s particularly painstaking is developing the middleware to access, consolidate and integrate legacy data from myriad legacy systems and new applications. This typically requires a team of programmers to write customized connections for each new point of communication in the system. In terms of absorbing a new entity, the process can take months, and involves complex and time-consuming coding and development work around messaging, mapping, orchestration, security and deployment. The inefficiency of the process results in a sub-optimal solution and loss of business value to the bank.
The alternative to this traditional approach is to deploy Application Programming Interface (API) tools based on open source standards. Because they are equipped with preconfigured code snippets that fully define how one application communicates with other applications, open source API tools bypass the tedious process of coding connections on a transaction-by-transaction, file-by-file basis. Rather, they enable system-to-system connectivity, thereby reducing the time and effort required to integrate core processing systems from a matter of weeks to a matter of days. As a result, banks, introduce new products and services to end users and improve internal operations more rapidly, creating better customer experiences and enhancing interoperability in a more reliable environment.
Given the effectiveness of open source API tools, particularly in terms of addressing the vexing integration challenges faced by the banking sector, one has to wonder why they remain such a well-kept secret. Perhaps the biggest obstacle is a traditional mindset within the industry. Despite perfunctory lip service paid to concepts such as operational transformation, digitization and disruption, significant portions of the banking sector remain highly resistant to change and are committed first and foremost to maintaining the status quo.
Consider the development team of a major bank. It may comprise 100 programmers, with perhaps half of them working full time on writing connections between applications – in other words, doing the painstaking in-the-weeds work that open source API tools circumvent. In an open source environment, the number of programmers writing connections would be about 10. So, from the perspective of the development team, adopting open source APIs represents a threat to programming jobs, and from the perspective of the development team’s director, a significant loss of organizational prestige.
In this context, resistance to open source APIs is certainly understandable. But while the prospect of people losing jobs is clearly a painful one, C-level executives involved in their organization’s operations must ask themselves if they can afford to ignore the opportunity to significantly improve productivity and operational quality. Put differently, if you’re serious about “disruption,” you have to consider the actual definition of the term, and recognize that it’s not just an abstract cliché.
