Right now, banks and Financial Institutions are under great pressure to deliver more change at a faster pace, but with more stability. The increased volume and speed of change creates more risk, and meeting demands quickly is becoming both more difficult and important as technology moves faster and customer expectations increase.
Highly-agile technology companies such as Amazon, Google, Netflix, Facebook, and Twitter use Continuous Integration and Continuous Delivery/Deployment (CI/CD) to respond to demands quickly (Amazon supposedly deploys 23,000 times a day).
Red Hat describes CI/CD as “a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment...Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment.”
However, for large enterprises with legacy systems that have not been built to operate this way, it can be a challenge to implement. CI/CD is not a quick fix and could actually create more complexity and abstraction if not done properly.
CI/CD can lead to huge improvements for the organization and its customers, though. For the organization, the biggest gain is agility, as it gives teams the ability to quickly release changes to customers, observe the impact, and then iterate. CI/CD creates a feedback loop on bigger, real-world data sets, making it easier, faster, and cheaper to configure a CI system to parallelize automated tests, compliance checks, and static analysis, work with large test data sets, and test on representative infrastructure and data.
On the other hand, the technical challenges of implementing CI/CD take time, especially with older platforms and frameworks that perhaps don’t automate easily; for example needing to retrofit systems and technologies after the fact when the knowledge of how they work might have left the function. Probably the biggest barrier is cultural, since CI/CD and Agile go together and this is a big shift from Waterfall development, where the feedback came with strong sign-offs rather than an iterative but timely approach based on data rather than opinion.
One of a bank’s strongest muscles is that of relationships and their maintenance. Therefore, by Conway’s law (the idea that organizations design systems that mirror their own communication structure), this creeps into the software development lifecycle, whereby a release can be as much about having great relationships with the unix and database teams involved at each step as it can be about technical know-how. Navigating 35 manual change tickets is a relationship exercise that comes easier to a bank than accepting imperfection and being driven by data.
Plus, when engineers are moving quickly and are expecting issues to be picked up automatically, the impact of erroneous code making it into production can be fast and widespread. When the integration, delivery, and deployment processes are manual it’s unlikely you will repeat an erroneous cycle that accidentally shuts down servers 10,000 times. With CI/CD it might have happened before you even notice. It’s also fairly common to see true CD processes for lower-level environments such as dev/uat and test, but different processes when it comes to production and getting it into the hands of customers - especially for organizations like banks where the impacts of an error are severe (we’ve all seen in the headlines what happens when major changes in banks go wrong, and the price tags that these carry - the FCA has already issued £91,097,200 in fines this year).
Key to the success of CI/CD is understanding the different roles of automated processes and people. CI/CD and automation go hand in hand - to do anything continuously you need to have automated ways to spot errors. Machines are great at doing rote repeatable tasks reliably and regularly without error. Humans are better at interpreting data and providing judgement. For example, it might be that a machine would reject a deployment because of something not passing, when the reality when judgement is applied allows for course correction and software to mesh with the real world. The key is the integration of both, and having the visibility and structure to manage that interplay between teams and technology.
Cutover brings teams and technology together to automate and orchestrate critical, timebound work across the enterprise, delivering complex technology releases and operational resilience and attaining constant availability of applications. Companies are using Cutover to release software, enact operational resilience, perform cloud migrations, and implement crucial platforms. With each use case, these customers are generating efficiency, visibility, and control together with a comprehensive audit trail. Find out more about the Cutover platform or contact us to find out how it can benefit your organization.