2

The DevOps Multi-Speed Context, Vision, Objectives, and Change Nature

This chapter starts by introducing the concept of multi-speed and discussing its relevance in the DevOps adoption of an incumbent bank. Continuing, we will examine the importance of understanding the state-of-art DevOps context of an organization and outline the top 10 DevOps context parameters that represent an average sample of incumbent banks, along with how they are generated and their corresponding implications. After that, we’ll set the desired DevOps vision and objectives for this book’s main actor, reconciling them with its corporate and technology strategies, both of which are influenced by its external and internal context. Then, we’ll outline the possible DevOps approaches to types of change an incumbent can take. We’ll do so by proposing the one that we will use throughout this book, along with citing the reasons for doing so. Finally, we will discuss the importance of building an understanding of the forces that are predicted to act in favor of or against your DevOps adoption.

In this chapter, we’re going to cover the following main topics:

• Understanding multi-speed banking
• Understanding your state-of-art DevOps context
• Enterprise DevOps vision and objectives
• The potential types of the DevOps change
• A method of capturing the DevOps forces

Understanding multi-speed banking

The term multi-speed refers to the capability of a subject to operate at more than one level of speed simultaneously. Multi-speed occurs all around us in real life. We often refer to multi-speed organizations, economies, and sports. Our incumbent is also characterized by the condition of multi-speed. This condition is important to understand in terms of its originating factors and influence on the enterprise’s DevOps adoption. It is crucial to take it into consideration when defining your vision, objectives, and implementation approach.

Why multiple speed levels arise out of different situations and ambitions

A multi-speed incumbent bank can be a natural result of situations (remember the equity trading and settlement example in the previous chapter) or an intentional construction driven by vision and ambitions. It is inevitable; being in different situations or being driven by different ambitions creates natural or constructed differing speed levels within the same organization. Factors such as how fast we are required to, how fast we want to, and how fast we can fulfill our objectives determine how we define different speed levels and their evolution.

How multi-speed is enabled by the nature of a business

Let’s go back to our equity business example from the previous chapter. Equity trading has to be a milliseconds real-time business; otherwise, the bank risks losing market share in equities, with its stakeholders not having much tolerance for failure. On the other hand, equity settlement does not need to be in real time, with its stakeholders being more tolerant of failure and there being a lower likelihood of losing market share if things fail. These two situations, which are driven by different banking business natures, enable two different speed levels within the capital markets domain. Relating this to a DevOps adoption, perhaps advanced real-time infrastructure monitoring and auto-scaling capabilities being supported by a dedicated reliability engineer is more of a necessity for equity trading than for equity settlement.

How multi-speed is enabled intentionally or organically

How fast you need to be, when driven by banking business nature, is one parameter. But you also need to think about how fast you want to and can be. Certain areas within an incumbent bank have more ambitious product owners, more demanding clients, better technological foundations, better engineers, and a larger budget for innovation, even though situations and banking business nature might require those areas to run at the same speed as others. These areas are characterized by conditions that allow them to be the frontrunners of DevOps adoption and hence enable them to deliver software faster than others, for example. Those areas’ situational positions may, for example, require them to release new functionality weekly, but their conditions (ambition and capacity) enable them to deliver on demand. They over-achieve their banking business nature objective, even if it’s not necessary, thus exceeding expectations. In this case, it is due to their aspirations and the conditions that they operate in, rather than out of natural necessity, that different speed levels arise. This is a common phenomenon that can be observed in incumbent banks, and you will find those areas mostly in the capital markets, wealth management, and digital banking business domains.

What is the role of circumstances in enabling multi-speed?

Circumstances also play a key role in multi-speed environments. Let’s look at another example. Two sub-sub-situations of very similar banking business natures, such as equity settlement and equity safekeeping, might be addressed with the same objective of improving their reliability due to high instability. The equity safekeeping system team, with support from their product owner, makes the brave decision to prioritize the hypercaring of the production environment and the resolution of all the preventive measures appointed after P1 incidents, rather than releasing new functionality. In contrast, the securities settlement team has been urgently requested to respond to a compliance readiness request by a large partner incumbent bank to which it provides global custody services. They have only 2 weeks to generate the necessary evidence. Inevitably, due to resource constraints, as well as urgency and product owners’ priorities, they cannot focus on reliability. This example proves that circumstances also contribute to the creation of different speed levels. Not every sub-sub-situation will work on their DevOps-related work at the same speed – not because they do not need to, but due to the present condition and circumstances.

The role of individuals in multi-speed

Going back to the incumbent’s banking business nature context, principally, not all product teams within it need to release on demand, not all teams need to re-engineer their platforms to be cloud native, and not all teams need to hire site reliability engineers. This is acceptable, so long as they meet the functional and nonfunctional objectives set for them. Do you recall the quality of relevance from the previous chapter? Something that’s relevant to equity trading is not necessarily also relevant to equity settlement. But there are some human elements involved: personal ambition and perception. These elements generate yet another factor that defines the levels of speed, and they are quite crucial, as we will see later in this book. Certain people within an incumbent bank define the services’ functional and nonfunctional objectives and can influence the conditions that a service finds itself in, along with how those conditions evolve.

Understanding multi-speed banking in a DevOps adoption context

Understanding every aspect of multi-speed within your organization is an impossible task that is not worth the investment. The present factors, sub-situations, conditions, and circumstances are countless and ever-evolving. Therefore, you will never have perfect information on the speed levels that characterize your context, and you must expect them to evolve alongside your DevOps adoption and also be influenced by it. However, understanding your high-level multi-speed context, as well as its drivers and how they shape it, while also having the means to keep track of its evolution, helps determine the vision, objectives, approach, and degree of success of your enterprise’s DevOps adoption. Despite the difficulty of precisely capturing the multi-speed context, there are some key parameters, criteria, and factors that can support a speed-level grouping of our incumbent’s business and application portfolio, with a relative and practical proximity to how the current context is shaped. This kind of grouping can be used as an enterprise DevOps adoption framework for meeting the qualities of relevance and 360°, as well as facilitating the intelligence mechanism behind the adoption’s rollout. We will explore this multi-speed banking DevOps framework when we discuss business domains and flows, ecosystems, and portfolio classification later in this book.

Understanding your state-of-art DevOps context

In the previous chapter, we discussed the external and internal context of our incumbent bank. In this section, we will deep dive into the third contextual layer, which is the state-of-art DevOps context, by providing an average representative snapshot of how the DevOps context of an incumbent bank looks. We will focus on contextual elements and capabilities that we consider the most important.

Important Note

To avoid misunderstandings, it is important to clarify that with the term “state-of-art” in our book, we refer to it as the level of development reached at a particular time, within a certain organization, as a result of the DevOps methodologies and practices employed.

Why examining your state-of-art DevOps context is vital

“Do not start changing something if you do not know it well enough,” an ex-CIO of mine used to say. DevOps is a concept that most incumbents have been adopting for many years. Some have done so in a harmonized and tactical way, while others have done so based on individuals’ aspirations; some at scale and some in a more fragmented way. Some have already adopted advanced DevOps enablers, such as public cloud services, while others are still in the proof-of-concept phase of core CI/CD pipeline capabilities; some have already adopted shift-left practices on their CI/CD pipelines, while to others, shift left is still a confusing term. However, some common DevOps contextual snapshot characteristics can be found across incumbent financial service institutions.

Having a deep, comprehensive understanding of your state-of-art DevOps context is of vital importance for various reasons:

• It provides input on defining your DevOps vision and objectives. Why focus on implementing CI/CD pipelines across your portfolio if you have already done it?
• It guides your adoption approach. Are you to transform, evolve, or radicalize your DevOps context?
• It allows you to identify foreseeable DevOps adoption forces.
• It provides an understanding of how ready your organization is and identifies the foundation you need to build on top of.

Before we move on to the representative state-of-art DevOps context of an incumbent, let me tell you a story. This will provide insight into why it is possible to capture an average snapshot of some incumbents that can act as a representative picture for the whole industry.

Once upon a time in Berlin

One time, I was at a Fintech conference in Berlin, sitting around the lunch table with people representing incumbent banks across Europe, discussing our organizations’ DevOps approaches. At some point, a CI/CD architect of a large incumbent bank said, “Guys, it seems that we all have the same problems. It feels like we kind of work for the same bank.” We all laughed at that comment. It was spot on! Another person at the table continued, “It is true actually. We have all worked for the same banks, read the same books, attended the same conferences, are in the same industry, have the same regulators, and operate in the same markets. It is natural that we follow similar approaches and face the same challenges.” Everyone around the table agreed with those views.

Why industry imitation is decisive in shaping DevOps adoptions

The reason for telling the Berlin story was to make an important point. Incumbent financial service institutions have, to some degree, depending on the case, been imitating business and technology concepts, DevOps included.

This is not a coincidence and is driven by five main conditions:

• Fear of falling behind the competition and the desire to follow in the steps of others, in an attempt to stay relevant in the industry.
• The belief that the actions of others who are perceived as more innovative and reputable are driven by a high degree of intelligence. See the example of ING and its Spotify model-inspired adoption. ING’s success in improving its Agile Way of Working (WoW) served as an example for Danske Bank, ANZ, and Commerzbank, to mention a few. Do we know what others have done? is a typical question asked in strategy meetings.
• Industry synergy purposely creates incentives for imitation. Historically, incumbents have created alliances among themselves, which has influenced the adoption of certain concepts. The domains of public cloud, compliance, and cyber security are good examples.
• Partnerships with technological vendors and management consulting firms have played a significant role in creating incentives for imitation across the industry. We have all seen slides with titles such as What the big players in the industry do or How we helped a UK bank to advance its DevOps practices.
• People are rotated across incumbent banks, especially at regional or national market levels. It’s obvious, right? When you jump to the competitor, literally in the building next door, you take DevOps intellectual assets and insights with you.

Imitating the actions of others is not necessarily a harmful tactic and does not strictly imply that you have identical visions, objectives, implementation approaches, and outcomes, nor that your DevOps context is state-of-art and will eventually look identical to others’. Factors such as your firm’s internal context and dynamics are great influencers, and despite certain industry commonalities, conditions such as culture, budgets, leadership, people, and the ability to think and execute quickly differ from institution to institution. Therefore, state-of-art DevOps contexts have certain similarities as well as differences, which require tailor-made approaches due to the nature of DevOps having to balance case agnosticness and sensitivity – case agnosticness in the sense that certain DevOps approaches can be applicable equally across different contexts (e.g., CI/CD pipelines adoption) and case sensitivity in the sense that certain DevOps approaches should only be applicable to certain cases (e.g., public cloud security for cloud-native applications).

Are there several DevOps “states of the art” within an incumbent’s context?

Yes. DevOps varies not only between incumbents but also within them. By conducting a simple internal environment scan, you could find an extreme variation between different DevOps state-of-art within the same firm. Some will be quite different, while others will be quite similar. While you will probably discover areas such as capital markets and digital banking at the forefront of the DevOps journey, you will also discover many areas in your back office or group operations and core infrastructure that are left behind, and maybe have not even set the fundamentals up. At this stage of your adoption, you should only focus on the broader organizational DevOps state of art rather than specific areas of the organization. While you probably do not have the means or the time to do so, you also need to try to get a representative picture of every single area. This will be an exercise that the stakeholders of its sub-situation will have to conduct later in your adoption, as we will see in the coming chapters.

The following figure provides a visual representation of the various contextual layers of an incumbent:

Figure 2.1 – The contextual layers of an incumbent that influence the DevOps adoption

The preceding diagram visualizes the layers of our incumbent that need to be captured while establishing the fundamentals for enterprise DevOps adoption. In the coming sections of this chapter, we will see how that multi-layer contextual understanding is essential in defining the DevOps vision and objectives, as well as deciding on the DevOps change type and approach.

What does a representative state of art DevOps adoption look like for an incumbent bank?

Most incumbents will find that there are several state of art DevOps elements that are repeated quite often across the industry, with some being dominant in representing the average context of most large incumbents.

Your state-of-art snapshot exercise should be targeted at key, core DevOps enablers, capabilities, and organizational aspects, rather than covering every single DevOps aspect and corner of your organization. It would not be humanly possible to cover everything. Also, it is important to mention that when understanding the context, you do not need to measure maturity. We will cover how and when in your adoption you should address maturity aspects later in this book.

Now, let’s examine the most common elements of the state-of-art DevOps context of incumbents. You will notice that in attempting to provide a quantified representation, we use the symbol N, borrowed from mathematics, which indicates an infinite number. In our context, an infinite number means that we don’t know the actual number and we can’t project it with confidence or based on data, which is a common situation that incumbents find themselves in:

• N unofficial DevOps operating and adoption models: This indicates the absence of a commonly launched DevOps operating model for the organization, and it’s the parameter that defines most of the rest of the contextual elements to some extent. This absence has probably led your organization, with its different organizational units and functions, to define its own DevOps operating model and consequently create a significant variation of DevOps approaches within the same firm. Typical observations of things that have led to this in teams is having their own daily DevOps organizing principles, no streamlined way of measured adoption, the freedom to build their own DevOps capabilities and not consume central ones, the ability to deal with compliance individually, and a lack of alignment with the firm’s corporate and technological objectives. This situation results in extreme, unknown, and uncaptured variations in DevOps maturity levels within the same organization.
• Nonstructured DevOps teams organizing principles and topologies: The main phenomenon in this parameter is the absence of harmony and alignment in how your teams organize in a DevOps context. For example, in some business IT areas, it is developers who provide production support and have access to production data, while in other areas, there are dedicated operations teams providing production support, with developers’ access to production being revoked. There can also be a third flavor of developers performing the operations work and an operations team performing only business support work. In general, a rather anarchical situation is observed in terms of roles and responsibilities, separation of duties, identity and access management, data protection, and more. Note that there is nothing wrong with operating in a hybrid and multi-speed setup, as long as there is alignment and consensus.
• Organizational structured walls: Another typical phenomenon, especially in organizations that have implemented a hardcoded separation of duties policies, is finding two different operating models characterized by conflict and fragmentation. The software development side of the organization uses advanced software development practices, while the operations and infrastructure side of the organization uses process-driven practices. Such situations violate the core principle of DevOps, shifting the organization toward Dev | Ops | Infra. The | symbol indicates fragmentation and discontinuity within your organization.
• Lack of trust in central platforms: Another typical observation is around common DevOps platforms. For various reasons, driven primarily by the lack of a common DevOps operating model and DevOps know-how, as well as conflicting incentives and strategic directions backed up by leadership appetite, in many DevOps adoptions, common platforms have not managed to establish themselves as trustworthy service providers. Common platforms, that is, teams offering central DevOps capabilities, such as CI/CD pipelines, containers, hybrid cloud, and tactical automation, have struggled to find their place in the organization. There are some specific reasons for this phenomenon:
  • The business’ IT areas are ahead because they have been building their own platforms well in advance of the central teams.
  • Lack of collaboration in defining requirements, customer journeys, and experience.
  • Central platform teams realizing they are running behind more advanced IT business areas and attempting to catch up leads to them jeopardizing quality, with platforms characterized by reliability issues.
  • Traditionally, the core infrastructure teams of incumbents (some refer to those teams as “dark IT”), such as infrastructure provisioning and hosting, network, and storage, have been very slow in responding to DevOps advancements and consequently have held organizations back.
  • Lack of domain know-how backed by outdated skills.
  • Lack of self-service and automation, backed by infinite hours of lead times.
  • Opinionated engineers and architects driving their agendas in business IT areas.
• N technological capabilities: duplication, fragmentation, proliferation, and omission: Shadow IT at its best, a colleague of mine used to call it. This is the phenomenon of numerous and duplicated solutions across DevOps technological enablers and corresponding frameworks. This includes multiple CI/CD pipelines, test automation and observability tools, cloud-native technologies, and security tools – the list can go on forever. A mild scenario that can be observed is that each business line has solutions but they are streamlined within the business line; this is similar to the asset and wealth management IT teams using their own solutions but standardized across their business lines. An even more problematic situation is that even within the same business line, business domains use their own solutions. For example, within the business line of digital banking and among “sister teams,” separate DevOps solutions could be built for the mobile banking applications, compared to the online banking applications, without valid business justification and purely driven by the actions of certain individuals and leadership’s dark motives, such as fulfilling personal ambitions. The proliferation of such solutions introduces several implications:
  • Increased operational cost, risk, and maintenance
  • Fragmentation across the technological ecosystem’s capabilities
  • DevOps adoption compliance has a lack of visibility
  • Enterprise-level scalability challenges
  • Extreme innovation without tangible business value
  • The data related to the adoption of DevOps is stored in countless home-grown solutions and is not aggregated, resulting in a lack of visibility and transparency

As well as the proliferation of unnecessary capabilities (such as six different application monitoring tools), there are also capabilities that are totally absent. These gaps in capabilities, in certain cases and depending on their nature, can severely restrict incumbents from advancing in their DevOps journey. They are mainly discovered in the domains of public cloud, security, and data.

• DevOps conceptual reconciliation gaps: DevOps is not the only concept that’s adopted in an incumbent bank. Business and enterprise agility models, enterprise portfolio planning mechanisms, IT Infrastructure Library (ITIL) processes, IT risk management and controls frameworks, software development methodologies, Site Reliability Engineering (SRE) models, and more are all part of the enterprise. However, they don’t always coexist in harmony. A common phenomenon is gaps in the reconciliation of DevOps concepts and practices with other concepts adopted within an organization, which promotes a conflicting situation from an overall concept adoption and reconciliation perspective. We all know about the DevOps versus ITIL versus SRE dilemma. Reconciliation gaps not only arise from an overarching perspective across different concepts but also during their practical implementation. This includes problem management processes not being reconciled with backlog prioritization, development squads being distant from operations teams, and IT controls not being aligned with DevOps continuity. These reconciliation gaps are primarily created by gaps in understanding concepts and conflicts of interest with stakeholders. Different concepts, the use of different terminology, and a lack of horizontal understanding and ability to connect the dots create misunderstandings. At the same time, different stakeholders pursue their own agendas.
• Misalignment of performance indicators and measurements: The main phenomenon that’s observed is the lack of a common, structured, and transparent mechanism for outlining the main performance indicators and measurements that are related to DevOps. Typically, you will find that four main DevOps metrics – time to market, change failure rate, change frequency, and mean time to recover – are used by incumbents due to their convenience and simplicity. These are considered industry best practices. But usually, there is a lack of front-to-back accountability with development and operations directors owning conflicting KPIs, a lack of value chain flow visibility across the SDLC, and a lack of credible data across platforms, with the primary source of data being IT service management tools, representing incidents, problems, changes, and availability management numbers. In addition, time to market is the dominant indicator, which is backed by a Deploy, Deploy, Deploy (DDD) culture.
• The “trust me, I am an engineer” approach: Many incumbents’ state-of-art contexts are characterized by a lack of trust but verify mechanisms that are embedded in the technological ecosystem by design. The main observations are either that IT controls are not implemented in alignment with various areas within the organization and that there is a lack of strong implementation evidence mechanisms, or the IT controls are complemented by significant manual and bureaucratic overhead on their practical adoption and evidence-generation mechanisms, impacting productivity. Moreover, one-size-fits-all approaches are used to address compliance, without taking their relevance to each case into account.
• Lack of necessary DevOps experience and expertise: We are all aware that there is talent scarcity in the market for any sort of DevOps engineering profile, from CI/CD engineers to cloud engineers, to security engineers to SREs. As we saw in the previous chapter, the external talent competition for new entrants is aggressive. Also, people within an incumbent’s organization tend to move toward more advanced areas, widening the internal DevOps experience and expertise gap. Overall, incumbent banks are observed to not possess the necessary skills, in terms of both quality and quantity, to achieve their DevOps objectives.
• DevOps is not prioritized: For many areas of an incumbent, DevOps is not a priority. If a team manages to deliver with acceptable release velocity and be close to its required service reliability numbers, that is just good enough. This area is considered DevOps done; no budget becomes available for DevOps activities and the product owner will not prioritize DevOps advancements in the product’s backlog.

Understand that your state-of-art DevOps context will never be completely perfect, either because you lack credible data, you have as many approaches to adopting DevOps as you have feature teams, or you do not have the time. An approximate qualitative picture that best characterizes the average practices of the teams in your organization will be sufficient. Where possible, it is advisable to collect indicative quantitative data to be able to best define your enterprise DevOps objectives.

Advice

During this exercise, be gentle in your approach to ensure that you do not generate resistance from people, as they could misunderstand your intentions and feel that they are being judged.

Enterprise DevOps vision and objectives

Now that we’ve outlined some fundamental aspects that define the foundation of your enterprise’s DevOps adoption, such as multi-layer contexts, as well as outlined the qualities and definition of DevOps, the next step is to define what you want to get out of DevOps. In this section, we will define the enterprise DevOps vision of an incumbent bank, as well as the corresponding objectives that can support its materialization.

Recapping the forces and qualities that shape the DevOps vision

The following is a brief recap of the forces that influence how the DevOps vision is shaped:

• Contextual forces:
  • External environment: Macro factors from the external context
  • Internal environment: Micro factors from the internal context
  • DevOps state of art: The current level of DevOps adoption
  • Multi-speed: The condition of running at different speed levels
• Strategic forces:
  • Corporate strategy: The incumbent’s business strategy, which is set by the board of directors
  • Technology strategy: The strategy that is set by the technological units to materialize the corporate strategy
• DevOps qualities:
  • At relevance: The DevOps adoption should consider some specific parameters of different situations when defining and implementing objectives
  • 360°: The DevOps adoption should be characterized by completeness, continuity, interoperability, and reconcilability
• DevOps definition: Your tailor-made DevOps definition, which indicates your vision

Figure 2.2 – Diagram of the main forces and qualities that influence the DevOps vision

The next section is dedicated to the strategic forces that we have discussed so far.

Examining the incumbent’s corporate and technology strategies

In this section, we will discuss corporate strategy and technology strategy and outline their strong interrelation, along with the key targets and priorities that underpin them.

Corporate strategy

With the term corporate strategy, we are referring to the strategy that sets the firm’s overall direction for the future in terms of target destination and objectives. The corporate strategy and the decisions that shape it define the direction that the business should take and are strongly influenced by the external context, while defining how the internal context is shaped. In the following list, we will focus on the most fundamental corporate strategy objectives for incumbents that have a close relation to DevOps. You should be able to intuitively relate these objectives to the incumbent’s external and internal context, which we discussed in the previous chapter. Corporate objectives such as increasing return on equity, improving the sustainability footprint, and increasing capital ratios are outside the scope of this book, for obvious reasons:

• Accelerate digitalization at scale: The objective of improving the delivery of digital services and the products portfolio to the market
• Best-in-class customer experience: The objective of improving customers’ digital journeys when dealing with the incumbent’s services and products
• Operational and capital efficiency: The objective of becoming more effective in delivering products and services while managing costs
• Preferred partner for customers: The objective of attracting new customers while also maintaining the current customer base
• Compliant and secure: The objective of meeting compliance demands and becoming proactive in addressing security threats
• Data-driven: The objective of utilizing data to support business decisions
• Simplicity and standardization: The objective of standardizing and streamlining operating models and processes
• People first: The objective of investing in the development of employees

Tip

Are you interested in the corporate strategies of different incumbent banks and want to examine the preceding objectives in terms of their financial performance, societal contribution, and business lines? I propose that you read the latest annual reports of some incumbents.

An important point to make that can influence DevOps adoption is that the different markets that the incumbent operates in create a dynamic multi-speed corporate strategy that balances the play to win and play not to lose tactics. The following table summarizes some of the differences between the two tactics that can impact DevOps adoption for certain domains:

Table 2.1 – Play to win versus play not to lose strategy differences

Technology strategy

With the term technology strategy, we refer to the strategy being shaped by the various technological units within the firm in responding to the objectives set by the corporate strategy. Again, we are taking a representative sample of incumbents with the difference that this time, we do not need to conduct a DevOps-relevant selection, as the totality of the technology strategy objectives has direct or indirect relevance to DevOps.

The following is a complete overview of the representative technology strategy objectives of an incumbent:

• Run the bank: Focuses on the ability of the technology to ensure adequate organizational and operational means of supporting production IT services
• Act commercially: Relates to optimizing the expenses of building, delivering, and running IT solutions on both the IT application and infrastructure layers
• Modernize and deal with legacy: Refers to eliminating or modernizing various legacy components in the organization, such as platforms or processes
• Improve WoW and efficiency: Advancements in the WoW models across technology areas and also with the business line partners, as well as eliminating waste and lead time to improve operational efficiency
• Build or acquire skills: Acquiring or building the necessary technological skills
• Compliant and secure by design: Effectively addressing compliance demands and ensuring security threats are dealt with proactively
• Plan ahead in alignment: Ensuring portfolio planning mechanisms are implemented to achieve alignment and synchronization across various teams
• Simplify and standardize: Removing complexity and duplications, re-engineering certain processes and policies, and shifting toward streamlining
• Deliver on commitments: Meeting the defined targets of service-level agreements (SLAs), security risk profiling, time to market, and recoverability targets

There are several parallels between the corporate and technology strategies, and this is expected, or rather, mandatory. The following figure provides a clear idea of how the corporate and technology strategy objectives are reconciled. Annual and quarterly re-alignment and benefit realization activities should be carried out at the enterprise level, as we will discuss in Chapter 10, Tactical and Organic Enterprise Portfolio Planning and Adoption:

Figure 2.3 – Corporate and technology strategy objectives reconciliation (“R” stands for reconciliation point)

Shaping the DevOps vision

Having discussed all the factors that contribute to shaping the DevOps vision, we are now ready to start defining it by combining these elements. In this book, we are taking the approach of defining DevOps objectives first, the totality of which will define the broader DevOps vision, which is also expressed by the DevOps definition. We will provide a one-to-many relationship, with many objectives, and define one vision. Such an approach helps you to think about how the vision can be shaped more tangibly as part of a collection of objectives, as well as understanding what the motives behind them are.

Advice

Start by defining the objectives and then summarize the vision in a single line. If you do this the other way around, you will find you are restricted in that the possible objectives from a linguistics and practical perspective (verbally, as in not able to find descriptive words, or conceptually, as in not able to consolidate practical aspects of concepts) do not seem to fit in the vision’s single-liner.

Needless to say, the DevOps vision should be tailor made based on the nature of the factors that impact your organization. The people in your organization should find it relevant and be able to find a place for themselves in it, rather than perceiving it as nothing more than high-level DevOps buzzwords with no real meaning.

Defining the DevOps enterprise OKRs

A widely used and very successful practice to follow is Objectives and Key Results (OKRs). Using this approach, you can define an objective and some key results as outcomes. In our case, we will go a little bit further by also appointing the motivating factors for each OKR, which will help with acceptance and realizing the benefits. While doing so, be extra conscious of the following points:

• Create a sense of urgency by highlighting not only the value proposition but also the potential consequences.
• Be careful about how you phrase the motivating factors. Do not call out issues within specific problem areas and teams; this will create a feeling of blame and discomfort.
• For transparency and traceability purposes, link each OKR to the technology and corporate strategies.

Now, let’s discover the fundamental DevOps objectives that incumbent banks define.

OKR 1 – improve time to market

Here, we focus on speeding up the path to production for the incumbent’s application portfolio:

Table 2.2 – Sample of the improve time to market enterprise OKR

OKR 2 – improve compliance as code

Here, we must ensure the incumbent’s portfolio fulfills its compliance requirements using DevOps practices:

Table 2.3 – Sample of the improve compliance as code enterprise OKR

OKR 3 – improve reliability through engineering practices

Here, the aim is to improve the reliability of services through reliability engineering practices:

Table 2.4 – Sample of the improve reliability through engineering practices OKR

OKR 4 – enable a tactical platform modernization mechanism

Here, we must enable a mechanism for application classification based on its technological nature, as well as enable mechanisms for portfolio modernization and interoperability:

Table 2.5 – Sample of the tactical platform modernization enterprise OKR

OKR 5 – enable a tactical hiring and incubation mechanism

The aim is to strengthen the incumbent’s DevOps engineering capabilities through hiring and incubation:

Table 2.6 – Sample of the tactical hiring and incubation enterprise OKR

Π-shaped profiles indicate people who understand the big DevOps picture (the horizontal line on the Greek letter Π), such as the DevOps vision, and have at least two DevOps engineering specializations (the two vertical lines of the letter Π), such as CI/CD pipelines and observability. We will get back to this definition and look at it in more detail in Chapter 12, People Hiring, Incubation, and Mobility.

OKR 6 – improve DevOps journeys and experience

Here, the aim is to improve the productivity and experience of the people that are part of the DevOps adoption:

Table 2.7 – Sample of the improve DevOps journeys and experience enterprise OKR

OKR 7 – improve the DevOps WoW

Here, the aim is to improve the WoW from the perspective of multidimensional DevOps and other adopted concepts:

Table 2.8 – Sample of the improve the DevOps WoW enterprise OKR

OKR 8 – improve standardization and simplification

Here, the aim is to streamline and standardize 360° across DevOps enabling and adoption capabilities:

Table 2.9 – Sample of the improve standardization and simplification enterprise OKR

Advice

Avoid using the words culture and cost in both the corporate and technology strategic objectives, as well as the DevOps vision and objectives. They simply give the wrong message regarding your motives and can cause unnecessary resistance.

In summary, the following diagram outlines the DevOps enterprise adoption OKRs that define what you want to get out of your DevOps adoption at an enterprise level. With these OKRs and by consulting your DevOps definition, you will find your DevOps vision to be appropriately expressed by the following statement:

Figure 2.4 – DevOps enterprise adoption OKRs

We will learn how those enterprise OKRs will eventually become more tangible for the business IT areas and your infrastructure teams later in this book.

What circumstances influence your vision and objectives?

How your enterprise DevOps objectives are formed and their priority, as well as the overall vision, will depend on your current but also short-term foreseeable circumstances. The following factors are key influencers and need to be considered and assessed based on their pressure barometer (also known as priority level) in your organization:

• Market competitiveness
• Macroeconomic environment
• Regulatory pressure
• Falling behind digital innovation
• Difficulty to attract talent
• Production services instability
• Cost pressure
• Are you already in the middle of another transformation?

Deciding on the nature and extent of your DevOps adoption

A DevOps enterprise adoption, despite its objectives, vision, or magnitude, is a change management process. Its connection to the corporate and technology strategies constitutes strategic change. You are modifying or replacing certain elements of the way that DevOps has previously been deployed in an organization. Your current state-of-art DevOps context will change during the adoption and will not look the same by the end. In this section, we will discuss a decisive decision that you need to make.

Why you need to decide on the nature and extent of change

A tool that I always find easy and intuitive to use when planning strategic changes is Types of Change Source by Balogun and Hope Hailey (2004). Through that, an organization can define its change type approach by looking at it from two dimensions. The first one is the nature of change, while the second one is the expected result. The nature of the change defines the sequence and speed of it and is divided into incremental, referring to gradual changes executed in sequence, and big bang, referring to one big change executed in one go. The result of the change defines the magnitude of its scope and is separated into realignment, which refers to small adjustments, and transformation, which refers to significant adjustments.

The possible combinations of the nature of change and the resulting dimensions define four possible strategic change types, as shown in the following diagram:

Figure 2.5 – Types of Change Source by Balogun and Hope Hailey (2004)

Let’s look at these in more detail:

• Adaptation: Primarily used to realign the way DevOps is adopted in the organization and is implemented through incremental steps. Can be executed with the existing culture and applied incrementally across the DevOps capabilities.
• Reconstruction: A more foundational approach to realigning the way DevOps is adopted in the organization, with several simultaneous initiatives. Fundamentally, the culture does not change, and the change execution is rapid.
• Revolution: A radical approach to changing the way DevOps is adopted with simultaneous radical changes. Fundamentally changes the organization and culture through enforcement.
• Evolution: A transformational change approach to the way DevOps is adopted through several simultaneous and interlinked initiatives that are delivered incrementally. Organizational capabilities and cultural advancements are achieved over time.

Which is the most pragmatic approach for an incumbent bank?

Choosing the most suitable and fit-for-purpose change strategy for your DevOps enterprise adoption requires not only strategic planning, design, and execution but also a level of political correctness and fairness toward your organization. Maybe you have not yet reached the desired state of DevOps in your organization, but you have taken concrete steps and enabled fundamental organizational DevOps capabilities, and some of your teams have gone quite far already. From a change marketing perspective, to ensure that you achieve a status of buy-in and limit resistance to change, demonstrating appreciation with words and actions for what has been already achieved in your DevOps adoption is crucial. Your organization’s people will not like hearing that you plan to reconstruct your DevOps adoption, indicating that it is currently broken. You will also need to provide convincing answers to the potential questions raised by the people in your organization. This includes “We are already doing DevOps, what is this about?,” “We already have a common CI/CD pipeline,” and “We already involve the operations team in backlog prioritization.” In addition, there is probably no need to be radical and boil the DevOps ocean either. The materialization of your objectives can be gradually realized. In this book, by following a pragmatic approach and being inspired by how a representative sample of incumbent banks in a real-life business approaches their DevOps enterprise adoptions, we will propose the evolutionary change type as the most sustainable and pragmatic strategy.

There are some qualities, fundamental aspects, and conditions of an organization that will also support a jump-start of an evolutionary enterprise DevOps approach, as well as increasing the probability of materializing the expected outcomes. You should do a reality check on whether your organization meets any of these:

• Empowerment to make collective decisions in a hybrid manner. Hybrid in this context indicates decision-making taking place both from top to bottom (leadership to employees) and from the bottom up (employees to leadership), with the two directions meeting in the middle.
• A clear strategic vision, aligned between business and technology, must be established.
• Ability to deliver incrementally and experiment with psychological safety conditions.
• Identify interim changes, gradually leading to the end target.
• Sustained top management commitment and emotional intelligence.
• The fundamental DevOps capabilities are already adopted.
• No irrational sense of urgency to deliver in a short and fixed timeframe.

You are free to choose any other change type that possibly better fits your vision, objectives, organizational context, cultural aspects, sense of urgency, and current state-of-art DevOps context. It is also advisable to stick to one change type and not try to combine more than one; this will probably generate feelings of discrimination among your teams, plus it will require that you have variation in your collective strategic objectives, which will create confusion and misalignments.

This section indicates two milestones for the next phase of this book. In the coming chapters and sections, we will no longer refer to the term enterprise DevOps adoption; instead, we will refer to DevOps enterprise evolution – or as I enjoy calling it, as inspired by the field of international relations, DevOps industrialization and globalization. Here, we are talking about industrialization in the sense of evolutionary advancements in organizational DevOps capabilities and globalization in terms of moving away from a DevOps culture characterized by fragmentation and protectionism and shifting toward interdependency and interconnectedness. This alternative naming indicates the beginning of embedding international relations terms in our DevOps enterprise evolution; I am confident you will find this very interesting.

Bonus Information

International relations is a scientific field of study on how states interact with each other as well as with international organizations in a global context. You will be surprised at how international relations concepts such as law, diplomacy, foreign policy, globalization, and sanctions can apply to the context of an incumbent bank and its DevOps evolution.

Why is it important to define and weigh the forces of your evolution?

Your evolution will most definitely not go as planned, as with everything in life. There will be plenty of challenges in your path, with some creating opportunities, while others being pure obstacles that you will have to overcome. Some of these challenges are very difficult to predict, while others are easier. Certain forces are derived from your internal and external context that will be a source of challenges and opportunities. Identifying them in the early stages of your evolution and taking precautions will be game-changing.

The quality and outcome of this exercise will be impacted by four main factors:

• Prior change know-how: The level of know-how from prior change activities that your organization has undergone in its history.
• DevOps evolution know-how: Having done a DevOps enterprise evolution before, you can predict the positive and negative operational and organizational forces.
• Deep awareness of the organizational context: Context plays a key role in the precision of the prediction. Knowing the organization and its dynamics, as well as having awareness of other change initiatives running in parallel, is an asset.
• Deep awareness of the DevOps concept: Knowing your DevOps is important. The deeper your DevOps enterprise knowledge, experience, and expertise, the better you can predict what lies ahead in the evolution and be able to act proactively based on know-how.

A method that is commonly used in the industry is Force Field Analysis, developed by Lewin (1951). This method provides an efficient tool for capturing the macro and micro forces that influence the change, along with how they evolve. The process is rather simple and intuitive: you need to list all the forces that are perceived to contribute positively to your DevOps evolution, as well as the ones perceived to contribute negatively. Each force is weighed by pressure points from 1 to 3, with 1 being low pressure and 3 being high pressure. The sum of all the negative and positive forces shows you whether the pendulum leans toward supporting your DevOps evolution or not. Using such a method serves as not only a change design tool but also a proactive risk management and decision-making mechanism.

Figure 2.6 – Sample DevOps enterprise adoption Force Field Analysis

When using such tools, you should also be aware of certain limitations that arise that require extra consciousness and effort. The analysis itself, if not complemented by a proactive risk management mechanism, will eventually become a paper exercise. In addition, on achieving the best possible precision, significant environmental scanning is required with attention to organizations’ context and DevOps concept details. Moreover, some of the inputs might be subjective based on people’s experiences, perceptions, and biases, resulting in a manipulated picture. Furthermore, you need to be conscious that certain forces can be double-edged swords – that is, they can have a positive and negative influence at the same time, so they even themselves out. Compliance is one of them as it can be a DevOps enabler but also a distractor. Such an exercise does not need to be perfect, but approximate. However, it is important to have a way to check the evolution’s temperature and adapt it accordingly, especially when DevOps evolution fatigue kicks in.

Summary

In this chapter, we have seen that multi-speed levels that appear in an incumbent’s context can strongly influence a DevOps enterprise’s evolution. We also looked at the third contextual layer, the one of DevOps state-of-art, and analyzed the most repeatable and representative contextual elements that we typically find when looking at a representative sample of incumbent banks. The core DevOps-related elements of an incumbent’s corporate strategy were defined, followed by the corresponding ones of its technology strategy. As we discovered, the corporate and technology strategic objectives have several similarities, and it is very intuitive to link them to a DevOps enterprise evolution. Then, we explained the importance of defining your DevOps enterprise objectives before your vision and outlined the most dominant and representative objectives of incumbents, the sum of which we used to define our DevOps vision in a single line. Continuing, we stressed the importance of defining your DevOps change type and provided arguments about why your approach should be evolutionary. At that stage, we reached an important milestone in this book and announced that for the remainder of this book, we will be referring to enterprise DevOps adoption as DevOps enterprise evolution. Finally, we provided a sample tool for identifying and measuring the forces toward and against such change.

Now that we’ve looked at the fundamental and foundational aspects of a DevOps enterprise evolution, in the next chapter, we will focus on further conceptualizing this vision by using an enterprise model. To do so, we will define the core governance elements that will steer and orchestrate this change.