What is the importance of adopting DevOps at relevance?

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.