Defining DevOps and its value proposition for banking

"DevOps is what you make out of it!" you could claim with confidence. In this section, we will examine what incumbent banks can potentially make out of DevOps. But before we start discussing the DevOps value proposition for banking, let me ask you a question. Have you ever thought that DevOps literally and technically is not attributed to a single definition and interpretation?

Some define DevOps plainly as a combination of software development and operations. Others define it as a value-driven approach, combining software development and operations, in an agile context. Amazon Web Services defines it as the combination of cultural philosophies, practices, and technologies that increase an organization’s ability to deliver services at high velocity, while Google describes it as a set of practices, guidelines, and culture designed to break down silos in software development and operations, with the DevOps Handbook referring to DevOps as the concept that enables development and operations teams to work toward common goals, enabling a fast workflow while achieving reliability.

In my opinion, there are four main reasons for this variety of definitions. The first one is the broadness of the concept. It is very difficult to define it in only two sentences. The second is people’s various perceptions of DevOps based on their experiences, background, and convenience. The third one has to do with the term not being descriptive enough. See, DevOps stands for development and operations, but it is not only about development and operations, as we will also discuss later in the book. Last but not least, the essence of DevOps is that an organization should decide what it wants to make out of it and define it accordingly. We will get back to this point later in the book.

Despite the lack of one DevOps definition, we need to make sure that we understand it the same when we use the term in this book. Therefore, we will take advantage of this absence of a universal definition of DevOps and create our own definition.

The DevOps definition that will guide this book is as follows:

A set of practices, frameworks, and technologies that enable flows, continuity, and collaboration across the Software Development Life Cycle (SDLC), to materialize common objectives while achieving an equilibrium of time to market, reliability, and compliance of services.

Tip

Randomly select 10 people from different backgrounds and seniority within your organization and ask them about their individual definitions of DevOps. You will be surprised by the versatility and variety of the answers.

Having our definition outlined, let us cross-reference it with the value proposition of DevOps for incumbent banks, looking into some core aspects and using a mobile banking application as an example.

Time to market, reliability, and compliance

This is what I call the triptych of DevOps outcomes. Before you question why security is omitted, this is to inform you that it is covered under reliability, as security in my mind is a reliability aspect.

Utilizing DevOps, incumbent banks can firstly improve the time to market of services. With time to market, we define the length of time it takes for a product or service to go from the phase of ideation to the phase of being released to production and being made available to customers. In simple words, DevOps enables the fast delivery and release of software to the market. In our example, the value proposition is that DevOps practices such as automation across the SDLC can minimize the time required between the mobile banking product owner coming up with a new feature idea of a drag-and-drop account aggregation functionality and the feature being made available through an update and upgrade to the bank’s clients.

Secondly, DevOps practices can improve the reliability of services. With reliability, we define the ability of a service to fulfill its non-functional criteria, such as availability, performance, security, and so on. In our example, a mobile banking application is expected to be available 99.99% of the time and respond within 0.2 seconds when the customer wants to see their deposit account. DevOps practices such as performance, testing, and self-healing can support reliability.

The third aspect of our triptych that can be improved is compliance. With compliance, we define the practice of obeying the rules of a higher authority. The higher authority in our context is the banking regulatory and supervisory bodies. Back to our example, regulatory bodies require a mobile banking application to keep an audit trail of unauthorized login attempts as part of security logging. Compliance as code DevOps practices can support the utilization of security logging mechanisms.

Equilibrium

This is one of my favorite terms to be used in a DevOps context. The Oxford dictionary defines equilibrium as the state of balance between different forces or influencers. In our context, the main forces or influencers are the outcomes of the following:

• Time to market
• Reliability
• Compliance

We have all had experiences where one of the three objectives had to be compromised in favor of the others. Achieving a DevOps equilibrium in our example means that we can achieve time-to-market targets for the new account aggregation functionality without impacting the performance of the application, as well as having a security logging mechanism implemented. Site Reliability Engineering (SRE) practices such as production readiness reviews can support that objective.

Common objectives

This indicates that all the stakeholders in the mobile banking application – product owners, developers, operations, DevOps engineers, and so on – share and understand the common goals of the service and their organization’s objectives and consequently work in alignment toward them. This goes from an understanding of the mobile banking business domain and customer behaviors and needs to why the service is of high business criticality, and from why feature A is prioritized over feature B to the importance of moving from weekly to on-demand release cycles.

The SDLC

DevOps, to deliver its ultimate potential, needs to be applied across all phases of the SDLC: from ideation and planning to development and testing, and from staging to production and deployment to its operations and maintenance, and eventually sunsetting. But by saying across the SDLC, we do not only refer to the phases themselves, but also to the people involved across the value stream. Those at the top of the core mobile banking business, development, and operations teams include the incumbent’s core infrastructure teams, enterprise architecture, and the command-and-control center. Yes, indeed, everything I just mentioned is also part of the SDLC.

Flows, continuity, and collaboration

We will bundle the definitions of flow and continuity, due to the strong interrelation of the two concepts, and define them as the steady and continuous movement of something, in one direction, without interruption. Flows and continuity are core principals enabling DevOps and are actually symbolized in the loop of infinity characterizing DevOps. Practices and methods such as value streams, engineering, and capabilities as a service can support the elimination of lead times and waste across the SDLC of our mobile banking application. For example, removing bottlenecks of manual approvals in the release management process, through value streaming techniques, speeding up the quality assurance process through test automation, and provisioning infrastructure as code within seconds will all contribute to a flawless and continuous mobile banking application delivery model. Inevitably, flows and continuity are empowered by strong collaboration across the actors of the SDLC; shared objectives, feedback loops, common benefit measurement realization, and collapsed silos are all factors supporting a better team and client experience in our mobile banking application.

Practices, frameworks, and technologies

This part of our DevOps definition indicates that the adoption of DevOps requires certain capabilities to be enabled and consumed in the organization, with multidimensional sources. They, as we will also see later in the book, are at the heart of adopting DevOps, as they provide the necessary materialization and enablement means. In our example, a shift left practice can support the reliability of the mobile banking application by focusing on the quality and operations of the services early in the SDLC. An observability framework can support the time to market via the assurance of production environment readiness, reliability through proactive service monitoring, as well as compliance through the implementation of a logging as a service capability, parts of which will be security logging. Last but not least, technology can, for example, be deployed through continuous integration and delivery pipelines, which can speed up the path to production for our account’s drag-and-drop aggregation functionality. Chaos engineering tools, embedded into cloud services, can support resiliency improvements of services, and a logging as a service telemetry tool can provide the compliance evidence our regulator requires on security logging. The DevOps practices, frameworks, and technologies that banking services can benefit from are countless.

The mobile banking example that we have used was intended to establish a relationship between DevOps as a concept and its practical value proposition in a banking context. From that specific example, it is quite intuitive to derive the broader DevOps proposition for the entire bank. Faster time to market increases the bank’s ability to deliver quickly on new customer needs, which can increase revenue. Service reliability means satisfied customers and lower operational costs. Compliant services mean the license to operate is not in threat and focus shifts to innovation. Increased collaboration toward common goals means aligned implementation of strategic objectives. Investment in technology means the attraction of talent and platform modernization.

But speaking about the broader incumbent bank’s perspective, is DevOps equally applicable in all business and technological domains within it? Is the mobile banking context similar or different to the contexts of digital customer engagement, customer resource management, and liquidity reporting, for example? Is the DevOps value proposition equally relevant across the bank? Should business applications and technological platforms be treated in the same way? The upcoming section will introduce us to a concept of vital importance when adopting DevOps in an enterprise and at scale. This concept will dominate the approach of this book in the chapters to come.