Starting this book, it is important to introduce our main actor. Understanding who is the subject of focus at this early stage is important so you are in a better position to understand our actor’s nature and context, as well as how DevOps as a concept is related. This chapter introduces and outlines the characteristics of the main actor, but also makes reference to other actors that operate in the same industry and ecosystem and have a role to play in the book.

Our main actor is an incumbent bank, representing a sample of global and regional incumbent banks. The incumbent bank in focus is a large institution, well established in the financial services industry, which has the objective of advancing its DevOps adoption on an enterprise level, as part of implementing its new corporate and technology strategy.

Our incumbent is characterized by the following specifications:

• It runs global operations in multiple regions of the world.
• It offers a rich variety of products and services across the banking, payments, and capital markets, asset and wealth management, and the insurance and pension domains.
• It is of regional and global systemic importance.
• It is exposed to different macroeconomic conditions and customer behaviors in the different markets in which it operates.
• Its market share position varies per operating market.
• It has a long history in the industry and is a result of several mergers and acquisitions.
• It historically started to adopt DevOps in several of its units but has not attempted enterprise and at-scale adoption before.

The largest world banks you can think of are represented by our incumbent.

Bonus Information

As a global, systemically important financial services institution, we’ve defined a bank whose failure could result in triggering a global financial crisis. There were 30 such banks in total across the globe in 2021, which we also refer to as too big to fail. Being systemically important indicates that as an institution, you are subject to higher supervisory expectations by the Financial Stability Board.

The incumbent bank operates in the same ecosystem and markets as challenger banks, neobanks, as well as banking infrastructure providers. The challenger banks, neo banks, and banking infrastructure providers are relatively new entrants in the financial services industry, with the following characteristics:

• Challenger banks: New, fully digital, online and mobile banks, without a physical presence, that offer banking products and services under a banking license. Revolut, Monzo, N26, and Lunar belong to this category.
• Neobanks: New, fully digital, online and mobile banks, without a physical presence, that offer limited banking products and services compared to incumbents and challengers without a banking license. Yolt and Chime belong to this category.
• Banking infrastructure and platform providers: These are companies that offer financial infrastructure services through platform integration to both incumbents and challenger banks. Mambu, Banking Circle, Klarna, and Nets belong to this category.

Our incumbent bank’s has relationship to challenger banks and neo banks is characterized by competition, while its relationship with banking infrastructure and platform providers, in most scenarios, is that of a service consumer.

It is important to make reference to another category that is closely related to our incumbent bank – beta banks. These are subsidiaries of incumbents operating under the banking license of the parent bank, or by using licenses of partner banks in specific countries. The business case behind those banks is the fast launch, experimentation, and expansion of new services and products to either existing or new markets. Mettle by NatWest and BforBank by Crédit Agricole are two examples.

Speaking of terminology, it is important to clarify an approach taken in this book. We will refrain from using the term FinTech to identify new entrants in the industry, as we perceive the term FinTech as standing for Financial Technology, which is equally used both by incumbents and new entrants.

When understanding the conditions and circumstances under which the incumbent operates, it is important to examine the financial services industry’s external and internal environments, seen from the perspective of our main actor. Getting this contextual understanding will serve as a fundamental awareness element for the rest of the book, especially when relating the industry’s context with that of DevOps. Context is of vital importance in adopting DevOps, as we will also see later in the book, and the financial services context is indeed evolving at a very dynamic pace.

What does an incumbent bank’s external context look like?

The term external context is used to refer to the external environment within which the bank operates. As our bank operates in global markets, we are taking a global average and as representative as possible a snapshot, while of course, we remain conscious that factors such as specific regions, countries, market conditions, regulatory frameworks, and economic factors force our bank to be faced in its reality with more dynamic and versatile circumstances and conditions than our snapshot presents.

As this is not an economics book, we will refrain from discussing economic concepts such as interest rates, inflation, gross domestic product, and industrial production indexes when examining the external environment. We will exclusively focus on the external environmental factors that do have a direct and/or indirect relation to how our incumbent’s DevOps enterprise adoption will be designed and will evolve.

Regulatory focus due to the 2008 financial crisis

Let’s attempt a flashback and go back to the years after 2008 and the global financial crisis. The aftermath of the crisis for large incumbent banks was characterized by waves of heavy regulatory requirements (Basel, EMIR, MiFID, Dodd-Frank, PSD, SCI, and T2S, to mention a few), which were complemented by extremely rigorous audit assessments, especially for globally systemically important institutions. Those audit assessments, apart from traditionally assessing the compliance and maturity levels of business operations, activities, and resiliency, were complemented by a significant focus on IT infrastructure and the related service domain. Technology operations and IT risk management came into strong focus with the supervisory authorities somewhere around 2015. By coincidence, around that time was the period that DevOps started to be known as a concept in the industry.

Licenses to operate came at risk, and capital was set aside to cover potential fines due to foreseeable challenges in complying with legislation on time. Inevitably, that situation forced incumbent banks to deploy significant amounts of their capital and resources to regulatory work, while in parallel they were struggling with profitability due to the volatile macroeconomic conditions of that period. Digital innovation agendas were compromised or put on hold for some time.

Obviously, the circumstances did not totally hold incumbents back from innovating during those years. Some indeed took advantage of the regulatory demand and capital set aside for those purposes to promote their digital innovation agendas, which was an intelligent tactic indeed. To some extent, it was also inevitable to not invest in new technologies, in order to close old audit remarks, as new regulations could not be met with legacy applications, infrastructure, and tools. Therefore, deploying innovative technologies to effectively respond to the continuously evolving regulatory environment, in certain cases, was the only sustainable way. Nevertheless, despite the creative mindset and approaches of several incumbent banks, their digital innovation plans were jeopardized, or at least slowed down.

Technology industrialized rapidly in the meantime

That turbulent period for the industry was at the same time a period of rapid advancement for technological utilities and concepts globally. Technologies such as APIs, cloud services, machine learning, artificial intelligence, and data analytics were proliferating and maturing, while concepts such as enterprise agility, DevOps, and SRE created new means and enablers for digital innovation and new ways of working (WoW) in the industry. Digital services have become mainstream in recent years, hybrid cloud has become the dominant infrastructure model, cyber security is evolving on top of the risk factors agenda, regulators are becoming more tech-savvy, the challenger banks’ business model delivers, and investment in digital customer journeys and intelligence has become one of the top profitability sources. The adaptation of such technologies and concepts challenges the traditional technology operating models of incumbents, requiring a generous shift toward modern WoW and advanced engineering capabilities. Concepts that the industry used to call “another nice thing to have” have become “another necessary capability we need to build.”

In recent years, and after that decade of global economic volatility and high focus on responding to regulatory demand, incumbents have entered an era of financial growth, characterized by increased profitability, which, in combination with technological advancements, allows capital and resources to be strategically deployed on digital innovation, materializing what some in the industry call the long-awaited transformation. Technology has started not only to be considered a key business enabler but the business itself.

Which are the forces that shape the financial services industry?

On providing a more detailed and rounded picture of the incumbent’s external environment, Porter’s Five Forces model is used to identify and analyze the industry’s main five competitive forces and reveal its respective strengths and weaknesses. The results of this method can be used by companies to support the evolution of their corporate strategy, which influences their technology strategy and consequently their DevOps adoption, as we will discuss in the next chapter.

A representative Five Forces analysis of our incumbent bank is presented as follows:

• Bargaining power of customers – Pressure level: Moderate: This force is very much client segment dependent, as well as operating markets and business domain related. A small daily banking client holding a bank account with a deposit of 1,000 euros has close to zero purchasing power if they decide to move to another bank. In contrast, a wealthy private or corporate banking client with a diversified portfolio of assets with a value of 500 million euros has significant purchasing power, as they could cause financial and reputational loss. The former is the one who is most likely to leave our incumbent for a challenger or neobank and the latter to another incumbent.
• Bargaining power of suppliers – Pressure level: Moderate: The two major suppliers of an incumbent bank are capital and people. The ability of the bank to compete in its markets, generate strong revenue, and maintain a high credit score rating, as well as meeting its return of equity and cost/income ratio targets, can attract clients and investors. Nevertheless, even though incumbents have returned to strong profitability, presently corporate investors’ interest in expanding their investments beyond incumbents toward challengers through funding rounds is increasing. On the people side, technological advancements, people skill scarcity in the market, talent competition, as well as the new flexible working conditions brought about by the Covid pandemic increase the challenge of maintaining and hiring talented people, primarily in technological domains. In addition, challengers and neobanks look appealing in the eyes of young talent, due to better career prospects through the usage of the latest technologies.
• Competition from industry rivals – Pressure level: High: The industry is traditionally very competitive, driven by aggressive profitability targets and ratios, backed by a digitalization time-to-market race for new products and services. The relatively low cost of switching from one incumbent to another or from an incumbent to a challenger intensifies an already competitive landscape. This rivalry, though, apart from bringing competition, also generates opportunities for joint ventures. The motto if you can’t beat them, join them is becoming part of corporate strategies across the industry and domain-specific ecosystems, through increased merger and acquisition (M&A) activities, vertical integrations, and FinTech incubation hubs. Banco Santander is a great example of an incumbent that is very active in pursuing joint ventures.
• Threat of substitute products and services – Pressure level: High: The incumbent’s monopoly is undoubtedly in decline. The industry is threatened by substitutions arising from the proliferation of new players within its ecosystem (challengers, neobanks, and infrastructure providers), as well as technological giants such as Google and Apple (in association with incumbents such as Goldman Sachs) that have entered the financial services industry. Changing customer behaviors, which is driven by the high technological literacy of new generations on one hand and on the other hand by sharing economic factors, generate demand for new substitute services. As the COO of a bank, I used to work on the basis of the saying Most customers now have smartphones and many options. What they do not have is time and patience. However, a competitive advantage that incumbents still maintain is that they offer the most complete service and product offerings across financial services domains, including financial advice.
• New entrants – Pressure level: High: The new entrants, after an initial period of facing high obstacles to penetrate the market and compete with incumbents, due to certain entry barriers such as regulatory frameworks, capital and license requirements, legacy bonds of clients with traditional institutions, and reputation establishment, have eventually made a significant breakthrough in the industry. Many of these new entrants have managed to build trust in the industry’s clients and attract funds from investors, as well as talented people. Their advantage is not only fully digital services, with reduced costs, but also new business models, improved customer experience, and technology service reliability. The effect that new entrants have varies across operating markets, business domains, and ecosystems, primarily due to factors such as regulatory frameworks, the resiliency and robustness of incumbents, as well as their market position, along with customer relations and behaviors.

Figure 1.1 – Porter’s Five Forces (1979) adapted to the financial services industry

What does an incumbent’s internal context look like?

The internal context of our representative incumbent bank is subject to more differences per incumbent compared to the external context, one can argue. There are, though, certain commonalities characterizing the internal context of globally and regionally systemically important banks. As we did with the external context, we will not cover the complete spectrum of internal conditions and will focus only on internal forces that have a direct or indirect foreseeable impact on enterprise DevOps adoption.

Persistent pressure on cost/income ratio

Incumbent banks, to remain competitive, need to continuously improve their cost/income ratio. This can either be achieved by reducing operating costs while keeping revenue relatively flat, or by keeping operating costs relatively flat and increasing revenue, or the happy days scenario, which combines operating cost reduction and revenue increase in parallel. Obviously, there is a convenient solution available, which is to bravely reduce the operating costs of the bank, as revenue increase is an exercise that requires great effort, and it is also affected by several external factors. In addition, focusing primarily on operating cost reduction can have an immediate effect on the bank’s balance sheet, while revenue increase is more of a long-term impact. Therefore, incumbents are extremely cost-conscious.

Bonus Information

The cost/income ratio is a major metric that determines the profitability of a bank. Its measurement analyzes the operating costs of running the bank against its operating income. The lower the cost/income, the more efficient and profitable a bank is. The mathematical formula used is operating cost / operating income = cost/income ratio.

Operational efficiency focus

Incumbents strive to produce more with less in improving their operational efficiency through the utilization of resources. Aiming to maintain a competitive advantage and create a first-mover advantage through the delivery of more innovative services and products, incumbents continuously examine possibilities to extend their production possibilities frontier through resource utilization. Their production possibilities frontier can be increased either with extra people and capital deployed, which is not the ideal strategy due to cost constraints, as we explained earlier, or by deploying technological advancements as their means of delivering new products and services. The latter sounds optimal and is the only sustainable possibility. In distinguishing this internal context factor from the cost-income ratio factor, we need to clarify that producing more does not necessarily mean more revenue, and the deployment of new technologies will also not necessarily come with a cost reduction in technology operating expenses. Your new products might not sell, and the utilization of new technologies does not come for free.

Figure 1.2 – Production possibilities frontier, adapted to incumbent banks

New ways of working

New, in this case, does not mean newly invented in the industry, but new in the sense of enabling new ways of doing things in a banking context. Concepts such as Agile, DevOps, scaled Agile delivery, modern software delivery, and site reliability engineering have been around for many years but very few incumbents have found solid steps in adopting them in a harmonious and scaled way, characterized by continuous organic evolution and not back-to-back transformation programs. You will often hear stories such as Bank A just started its Agile Transformation v3 or that Bank B started its DevOps Industrialization v2. I always remember a saying from an ex-peer of mine: Banks get transformation programs done so they can start another transformation program to transform the results of the previous one. This is of course not representative of every incumbent, but it does hold lots of truth in it. Another present challenge is the difficulty for incumbents to fit all the new WoW concepts under one operating model that is characterized by harmony and reconciliation. Often, also, as we will see later in the book, the adoption of new WoW concepts is complemented by organization structure changes that in many cases defeat the new WoW method’s purpose. All of this results in a confused and misaligned modus operandi, characterized by internal variations, an ineffective blend of old and new ways of doing things, and resistance, under the mentality that if it is not invented here, it cannot be implemented here.

Organizational debt

In IT, we often use the term technical debt, referring to software solutions that have been deployed to production that are characterized by low quality and in the future will result in functional and non-function abnormalities. Looking at the broader context, incumbents are faced with what I prefer to call organizational debt, which spans horizontally and vertically across their organizations, from outdated people skills to coupled legacy platforms, and from bureaucratic policies to complex and cumbersome manual processes, backed by a deep-rooted old-school mentality on WoW, based on silos and fragmentation. All these elements have multidimensional and domino-effect consequences for an incumbent’s internal operations and its ability to transform and advance. Such conditions not only increase the cost and complexity of delivering and running technological solutions but also impose high operational and regulatory risk, slow down the adoption of new WoW and radical digitalization initiatives, as well as impose a great risk on an incumbent’s ability to attract and maintain talented people.

Digitalization and platformization

Banking as a service is becoming the new business model norm and a vehicle for staying relevant, enabled by significant investment in digitalization and platformization. The focus is not only narrowed on how clients interact with banks but also on how internal business units interact with IT, as well as IT-to-IT interaction. However, in many cases, banks face significant challenges on that digitalization and platformization journey, primarily due to heavy reliance on legacy technological platforms. The situation is characterized by old untenable platforms, with unknown technical debt, black-box business logic implementations, expiring maintenance contracts, poor documentation, monolithic architectures, lack of integration, high customization, difficulty upgrading, unreliability, and scarcity of people with deep knowledge. What is often called in the industry a legacy dilemma is still to be solved for most incumbents, with some bombs ticking as we speak (borrowing an expression of an ex-CIO of mine).

Corporate and technology strategy objective misalignment

Technology is there to enable the business and the other way around, you could rightly claim. That statement indicates that corporate and technology strategies need to therefore be in close alignment and evolve together. This condition of alignment is challenging to achieve, especially in very large incumbents. Organizational structures, siloed business domain thinking, a lack of collective strategic initiatives, conflicting performance indicators, ambiguous benefit realization procedures, a lack of technological literacy on the business side, as well as a lack of business literacy on the technological side, in combination with middle management being the transmitter of priorities and direction, creates a condition of misalignment and misunderstandings. On the technological side, this misalignment in many cases goes deeper between the business IT areas and the core infrastructure teams. One of the situation’s consequences is the occurrence of extreme variations in the adoption of different technologies and concepts. Another consequence is the inability of teams to understand how they are supposed to contribute to materializing the incumbent’s strategic objectives, the motivation behind those objectives, as well as what their position is and their role in the delivery value stream.

"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.

Different definitions and interpretations drive different approaches, solutions, and depth in enterprise DevOps adoption. Despite, though, those differences in approaches, there are certain principles that universally and in any context guide DevOps adoption collaboration, flows, automation, visibility, feedback loops, and so on. On top of them, in this book, we introduce a principle, which we name the guiding principle, that not much has been written about in the available literature, and when I use it as an expression in real business contexts, people in most cases ask me What do you mean? We've never heard of this concept.

Defining relevance

This guiding principle is one of relevance, which in my opinion adds the necessary elements of sophistication and intelligence to enterprise DevOps adoption. According to the Oxford English Dictionary, the definition of relevance is a close connection with the subject you are discussing or the situation you are in. In our case, we will slightly paraphrase that definition and we call relevance a close connection of the subject discussed with a situation we are in. In our case, the subject we are discussing is obviously DevOps and the situation we are in is the context of an incumbent financial services institution. In other words, with relevance, we examine the level of connection required between the situation and the subject.

The relevance of the situation level

The first level of relevance is the situation level. What is relevant from a DevOps perspective for an incumbent financial services institution might not be for an aerospace company and vice versa. Let us put that into context. A bank can live with an outage on its core banking application (business-critical system), while an aerospace company cannot on its aviation system (safety-critical system). This is simply because the potential consequences of the outages are of different severity. In a bank, clients might lose access to their deposits for 10 minutes, while on a plane, passengers might lose their lives. Equally, if Google’s services (mission-critical) are down for 30 minutes, the impact is great and reaches every part of the world, with millions unable to perform basic daily operations. Or, think about a scenario of a hospital processing daily end-of-day medical records (security-critical) and facing latency on its data transmission channels. Rolling back the data to day 1 is not acceptable as patients might need to take new medical prescriptions, while such a practice is a common data latency error handling mechanism in banking on end-of-day reporting activities.

The relevance of sub-situation levels

Normally, a situation consists of several sub- and sub-sub-situations. The deeper we go into the levels of a situation, the more subcontexts we discover. Let us examine sub-situations and sub-context layers, using an example from the context of our incumbent bank.

Part of the incumbent’s business model is the domain of capital markets (sub-situation). Through that domain, the incumbent offers investment services and products to its clients. Capital markets have several sub-domains (sub-sub-situations) that all support what is called the trade life cycle (see it as a value stream of business activities within capital markets), as in all the phases a trade has to go through, from the time that the client orders its execution till the time that the asset that has been traded has entered the client’s portfolio and the corresponding activity commission and investment amount has been settled. Two of the domains under capital markets are equity trading and equity settlement. Despite the fact that both domains belong to capital markets, and also the same value stream, they have some distinct differences. Equity trading is a real-time business where zero latency and service availability of 99.99% are crucial, while equity settlement is not a real-time business, where a little latency is tolerated and service availability of 97.5% is sufficient. In addition, equity trading is high up in the trading activity life cycle (also called front-office trade execution activity), while equity settlement is at the end of the trade life cycle (also called back-office post-trade execution activity). Issues originating in equity trading can generate more severe domino effects than issues occurring in equity settlement. Furthermore, equity trading is a profit-making mechanism for the bank, while equity settlement, as the name indicates, only formally settles the trades. Last but not least, I am certain that those who have worked for an investment bank can relate. Business users in equity trading, called equity traders, are far less tolerant of failures than business users in equity settlement, called settlement officers. Equity traders are also less accessible to people sitting in IT than equity officers.

Another factor that distinguishes the two cases of our example is what we will call in this book current circumstances. By circumstance, we mean one’s state, which subsequently defines what is currently most important from a DevOps adoption perspective. Suppose our equity trading application currently is facing severe stability issues, while its time-to-market numbers exceed expectations. Naturally, improvements in reliability engineering are more important than release velocity in its current situation. On the other hand, equity settlement has been meeting its availability targets back to back for months, but it cannot be released as fast as expected by its product owner. Naturally, equity settlement will focus on release velocity and not reliability engineering.

Figure 1.3 – Relevance example

Such combinations can be numerous and not only relevant in applications supporting business domains and processes, but also in internal banking infrastructure service providers, as we will discover later in the book.

The preceding example proves that there are several sub-situations within a situation within the incumbent. Those situations have distinct characteristics that make them vary in many aspects. This variation creates a DevOps constraint. One DevOps solution must not be applied equally to any context, situation, or circumstance. Referring to DevOps being applicable based on context, situation, and circumstance, the term at relevance will be used to indicate what is relevant to a situation and/or sub-situation and what is not. In other words, while adopting DevOps in an enterprise, only what is relevant in each situation and sub-situation should be adopted. Who are the ones making this decision on what is relevant, what is not, and to whom? We will discover this later in the book.

As we discovered through the book’s DevOps definition, there are several elements that contribute to what DevOps is about for an organization. From practices to people and from technology to shared objectives, all these elements need to come into harmony. In this chapter, we introduce the element of 360° in DevOps, explaining its value proposition and applicability.

In mathematics, the term 360° indicates a complete trip around the edge of a circle. Take as an example the rotation of the Earth around the Sun, or the rotation of a clock’s hands in order to complete 12 hours, or to relate even more to our context, take a look at the symbol of DevOps, the loop of infinity. In all these examples, there is a starting point and after a 360° rotation around different phases, we end up again at the starting point. Ending up at the same point where we started does not indicate that we achieved nothing, and we are back at square one. It indicates that we managed to achieve a complete and flawless rotation across DevOps capabilities: complete in terms of we have engaged all necessary capabilities that comprise our DevOps model and flawless in terms of those capabilities were so harmoniously interlinked that it did not interrupt our 360° journey.

In this book, 360° indicates the need to cater to four qualities when adopting DevOps at the enterprise scale (please note that the definitions of the following terms are taken from the Oxford English Dictionary):

• Completeness: We define completeness as the fact of including all the parts that are necessary; the fact of being whole. In our DevOps context, these parts are all the tools, stakeholders, processes, policies, mechanisms, frameworks, metrics, funding, and so on that are necessary in order to perform successful enterprise adoption at scale. The fact of being the whole indicates on the one hand the necessity of involvement of the whole organization, or at least the required parts that directly or indirectly have a role to play in DevOps adoption. And on the other hand, the DevOps capabilities that are to be enabled and adopted need to complement each other, as in being the interconnected and interrelated pieces of the broader DevOps adoption puzzle.
• Continuity: We define continuity as the fact of not stopping. In DevOps, this means going on and on (infinitely) around DevOps phases and the capabilities that enable them, without interruption, but also ensuring that the DevOps adoption is not a one-off activity, and it organically becomes part of the organization’s DNA, characterized by continuous evolution.
• Reconcilability: We define reconcilability as the ability of a concept to coexist with another. In our context, this defines the ability of DevOps to coexist in harmony, on the one hand within its sums, meaning harmony and balance across the concepts that are at its core – for instance, compliance controls being in harmony with release velocity. And on the other hand, it means to be in harmony and balance with other concepts that are also adopted in the organizational context, such as Agile and ITIL.
• Interoperability: We define interoperability as the ability of entities in a network to connect with each other and carry out their functions. In our context, we refer to the ability of the DevOps technological ecosystem and corresponding enabled capabilities being perceived as the backbone of DevOps adoption, to achieve a high level of interconnectedness through full stack engineering. In addition, we refer to the ability to collect data across the technological ecosystem that can be mapped to the end-to-end SDLC, across the DevOps continuity phases, and be utilized as a source for feedback loops, visibility, and continuous improvements.

The four qualities mentioned do have a relation of interdependence among them, and it is necessary to evolve them in parallel as one cannot deliver its full potential without the others. As an example, if in your DevOps adoption, you do not engage the complete set of your infrastructure team’s stakeholders, you will never be able to achieve continuity in the developers’ journey of consuming infrastructure capabilities, which will consequently result in technological solutions’ interoperability gaps and, moreover, fragmentation in your technological DevOps enablers’ reconciliation.

Your enterprise 360° DevOps adoption should be characterized by these four qualities, which should eventually be recalled readily by each participant in your organization and guide ideas, discussions, disagreements, decisions, and solutions. Your adherence to them can be checked by asking the following four simple questions:

• Does approach A fulfill the quality of completeness?
• Does solution B fit in the continuity cycle or does it break it?
• Is solution E reconcilable with concept D?
• Is solution C interoperable with the core technological ecosystem?

As we have seen in this chapter, incumbent banks have certain characteristics and are surrounded by several counterparts operating within the same ecosystem. Those counterparts create an external environment that, along with other factors, puts certain levels of pressure on an incumbent bank and influences its corporate strategy. Incumbent banks, on top of similarities in their external contexts, also have certain similarities in their internal contexts, especially in domains that are relevant to DevOps. The absence of a universal DevOps definition, as we discussed, created the need to establish our own definition for this book, which we have applied to the mobile banking example of outlining the DevOps value proposition for the incumbent. Closing the chapter, we discussed the importance of two elements, relevance and the 360° nature of enterprise DevOps adoptions, through examples. By now, you have built a good understanding of the book’s main actor and its context, having defined DevOps and introduced two new core DevOps adoption elements.

In the next chapter, we will discuss the early-stage phases that the incumbent needs to follow in defining and establishing the fundamental direction of its DevOps enterprise adoption.