3

The DevOps 360° Operating Model Pillars and Governance Model

In this chapter, we’ll introduce the core pillars that comprise the skeleton of the DevOps 360° operating model and provide an overview of its domains. Then, we will discuss the two main governing bodies that you should establish; that is, a DevOps 360° vision authority group and a 360° design and advocacy group, along with their responsibilities. After that, we will stress the importance of engaging a broad DevOps ecosystem of stakeholders across your organization and provide an overview of the ones we believe are the most important, along with their corresponding DevOps value propositions. Then, we will define the workstreams that should be enabled to support the materialization of DevOps enterprise OKRs. We will use compliance as code as an example to define the workstreams’ responsibilities. After that, we will discuss the value of understanding the governing dynamics of your organization and how they can influence its evolution, as well as the need to ensure that you are speaking the same language to all DevOps stakeholders. Finally, we will deep dive into the role that organizational structures and hierarchies have in DevOps evolutions. We will examine organizational structures and hierarchies through the lenses of three real use case examples from different incumbents.

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

• The core pillars of the DevOps 360° operating model
• The vital role of the DevOps vision authority
• The need for a DevOps design and advocacy group
• Why you should engage your DevOps enterprise evolution ecosystem
• The evolutions workstreams and scope
• Why you need to understand your governing dynamics
• A simple tool so you speak the same DevOps language
• Three real use cases where organizational structures influenced DevOps evolutions

Defining the DevOps 360° operating model core pillars

In the previous chapter, we discussed the link between DevOps evolution and the strategic objectives of an incumbent, and we defined the core DevOps enterprise OKRs and visions. We will start this chapter by outlining the skeleton of the DevOps 360° operating model and its core pillars. In this and the upcoming chapters of this book, we will explore the model’s journey toward completeness.

In the following diagram, you can see the skeleton of the DevOps 360° operating model that will unfold throughout this book. It fulfills the 360° qualities of completeness, continuity, interoperability, and reconciliation while enabling adoption at relevance in a multi-speed incumbent bank:

Figure 3.1 – The DevOps evolution 360° operating model skeleton

We can define each of the three pillars around a unique value proposition:

• Direction and orchestration: This defines all the mechanisms that will direct, steer, and coordinate the evolution throughout its life cycle, as well as the new WoWs.
• Evolution and enablement: This focuses on DevOps capabilities evolution and enablement, ensuring that the four 360° qualities are materialized by engaging the totality of DevOps enablement stakeholders.
• Roll out, accelerate and scale: This enables the necessary mechanisms for launching and adopting the evolved DevOps capabilities and achieving a tactical and organic adoption. It is also inevitably characterized by alignment, acceleration, and scale in a multi-speed context.

Tip

In the initial phase of the evolution, keep the 360° operating model as brief and compact as possible so that you don’t overwhelm your organization with too many details about the pillars. Presenting the full magnitude of the evolution in this phase is likely to generate resistance.

The evolution’s core governance

In this section, we will discuss the core governance bodies and mechanisms that we suggest you establish when governing your evolution. Note that we will intentionally not refer to communication tools, progress and risk reporting, and change management methodologies, as we consider these to be obvious basic hygiene mechanisms that should already be established.

Establishing a DevOps 360° vision authority group

Direction setting, orientation, steering, and sponsorship will be required and strong involvement from senior management will need to be secured. Senior management in our context refers to senior directors from various units, including business, technology, and group functions, that are hierarchically positioned one or two levels below the group COO, depending on your organizational structure. We suggest that those stakeholders become your DevOps 360° vision authority group and take on the following responsibilities:

• Reconciling the objectives of the corporate and technology strategies with the DevOps enterprise evolution vision and objectives
• Ownership of the funding, prioritization, and risk management mechanisms
• Ultimate strategic decision-makers who also serve as escalation points
• Delegation to middle management, connecting decision authority with the rest of the organization
• Continuous measurement of the evolution’s temperature and tempo setting
• Definition of the early adopters as part of the evolution’s tactical adoption, as we will see in Chapter 10, Tactical and Organic Enterprise Portfolio Planning and Adoption.
• Definition of the evolution’s workstreams
• Ultimate ownership of the DevOps 360° operating model

The decisions that are taken by the DevOps 360° vision authority group should be binding and its members should be obliged to fulfill them and be held accountable for the parts of the organization that they represent. Decision and action unilateralism by certain parts of the organization should also be addressed by this group and disciplinary/deterrence actions should be taken by the group to ensure that such actions don’t recur. In other words, this group should be the Leviathan that governs and brings order to the evolution so that those involved are able to unleash their creativity in an environment characterized by DevOps alignment and solidarity.

Bonus Information

Leviathan (the Leviathan in our case being the DevOps vision authority group) is a masterpiece of political philosophy written by Thomas Hobbes and published in 1651. This book is concerned with the structure of society (or, in our case, the structure and evolution of the DevOps enterprise) and who has the authority to govern. According to Hobbes, in the absence of a Leviathan, life becomes chaotic and people cannot focus on creativity, as they constantly fight for survival.

Ideally, this group should be headed by two people: a senior executive appointed by the group’s COO, and someone who can be accountable for the DevOps evolution, who should either be the head of your DevOps CoE, the Chief Information Officer (CIO), or the Chief Technology Officer (CTO). All the core stakeholders’ areas should be represented in the group, to ensure the best possible balance. The vision authority group should have permanent members as well as guests based on the agenda to be discussed at its assemblies. The guests should be representatives of the DevOps 360° design and advocacy group and workstreams.

Tips on Managing the Vision Authority Group

Based on my experience of working with such groups, I recommend that you consult the following tips:

• Base the membership of the group on the four qualities of the change forces that we outlined in the last section of Chapter 2, The DevOps Multi-Speed Context, Vision, Objectives, and Change Nature.
• When meeting as a broader assembly, ideally, you should meet offsite. Changing scenery will energize things and improve relations.
• Understand the power bases of the group and the overall dynamic.
• When important decisions are to be made, speak to the members in one-to-ones before the session and conduct a psychological scan of them to predict the atmosphere in the room. With the term psychological scanning, we refer to the process of observing their psychological state and reactions when they are presented with the decisions that are to be taken. For instance, are the members energized and confident or do they look confused and uncertain? Does their body language reveal resistance or calmness?
• Always use relevant data (hard and soft) so that educated decisions can be made, along with calculated justifications.
• Study the members’ background and personalities to adopt your DevOps vocabulary. As in, you need to adapt the DevOps terminology you use and change how you position it contextually for each stakeholder. As an example, you will have to adjust your wording and practical examples when you explain release engineering to the Head of IT Operations, compared to the Director of Fixed Income Trading.

Establishing a DevOps 360° design and advocacy group

The first thing you should do in order to engage stakeholders outside the vision authority group should be to establish a DevOps 360° vision and advocacy group. It is crucial to hand-pick the members of this group based on a combination of the following characteristics:

• They should have a strong passion for and knowledge about DevOps at enterprise scale.
• They should have championed and practiced DevOps successfully for several years.
• They should belong to the tactical evolution areas you have chosen.
• Their profiles should balance hard (technical) and soft (interpersonal) skills and they should be able to take a collaborative and collective approach.
• They should have good reputations and recognition across the organization.
• They should have proven experience in enterprise initiatives.

Ideally, the composition of this group should be diverse in terms of roles and organizational origin; there should be everyone from developers and architects to infrastructure engineers and middle managers. These people should be easy to identify as they should have already made their DevOps name in your organization. Diversity is very important in ensuring a good range of DevOps skills and experience across the broader DevOps ecosystem, as well as to cover organizational context-specific aspects, requirements, and views. A senior developer from the payments domain would oversee certain aspects of DevOps differently than an Oracle database administrator from the core infrastructure domain. Mixing insiders and outsiders in this group is also important as you will require people that know your state-of-the-art DevOps context and its historical evolution well, but also people who are fresh hires that have seen how DevOps is done elsewhere and can inject fresh ideas, eliminating unconscious bias.

The advocates need to have decision making authority mandated by their line managment and the vision authority group. The vision authority group and the advocacy group’s line managers will neither have the time nor the domain expertise to make all of the decisions themselves; they would become bottlenecks or require extensive coaching. Nevertheless, this advocacy group won’t be able to make all the decisions as some will be too strategically significant, require political correctness, or be too difficult to come to a collective agreement about. Hence, a clear decision-making and escalation process should also be defined.

The main responsibilities of the group should include the following:

• Accountability for the future design of the DevOps 360° operating model.
• The design and approval of DevOps solutions and frameworks.
• Workstreams coordination and DevOps enterprise catalog definition.
• Acting as a bridge between business IT and core technology.
• Piloting the new DevOps 360° operating model in their respective areas.
• The communication aspects of advocacy for the DevOps evolution, such as awareness sessions and demos. The group must also have the ability to continuously improve the DevOps operating model based on regularly collected feedback.

It will be necessary for this group to think ahead about how the DevOps model should develop, and this vision should be closely aligned with that of the vision authority group. This will help them steer workstreams, be forward-looking when it comes to decision-making, and have the necessary time to prepare the organization for evolution.

Be Aware

There will be spies in this group. They will be people that, due to conflicting DevOps agendas, will attempt to spy on what is being planned for the DevOps evolution and bring the information back to their units so that they can prepare their defense plans.

Availability and commitment will be an issue when it comes to the members of this group, either because they are scarce and very important to the business or because they are not dedicated enough to the cause of the group.

Defining your DevOps enterprise evolution ecosystem

Maybe the problem is that it is called DevOps! This is a phrase I have borrowed from a fellow DevOps practitioner who interviewed me once upon a time at a DevOps conference. We were discussing why many organizations often follow a developer-centric approach when adopting DevOps and exclude operations. And is it only operations that they omit? The fact that the concept is called DevOps can make people intentionally or accidentally neglect several other important DevOps stakeholders. As we will see in this section, there is a wide range of stakeholders, each of them bringing a unique value proposition, that are involved in ensuring that all of the four qualities comprising the DevOps 360° operating model are fulfilled.

Who should be considered as key stakeholders?

As different incumbents have different organizational structures, we will focus on DevOps domains rather than unit names. The following tables provide an overview of the primary and secondary domains that you should consider including in your evolution:

DevOps Domain/Stakeholder	Value Proposition
Primary
Software Development and Operations	Builds and runs software. The primary consumers of technology utilities and DevOps capabilities.
Business Units	Owns and uses products, applications, and services. Manages DevOps priorities for business applications and funding.
Enterprise Architecture	Forms the governing mechanism for architecting your portfolio of applications, services, platforms, domains, and flows.
DevOps CoE or CoP	Sets your organization’s DevOps standards.
Control Center	This is the first line of service operations and continuity.
Enterprise Service Desk	Handles business inquiry fulfillment on IT applications.
Process Governance	Owns the service life cycle operational processes.
Common Platforms	Comprises utility teams offering technological DevOps capabilities.
Cyber Security	Enables security policies across your SDLC.
Service Portfolio Governance	Form the application and service registry mechanism.
IT Risk and Controls	Facilitates the implementation of the IT risk management framework.
Business Agility CoE or CoP	Oversees the business agility model of your organization.
Data Governance	Enacts data classification and protection policies.
Quality Assurance	Facilitates the creation of quality assurance strategies and plans.
Core infrastructure	Provides the core technology infrastructure capabilities.
Data Analytics	Provides telemetry and reporting capabilities.
IT Audit	Provides an overview of open IT audit remarks.
Talent Acquisition and HR	Manages recruitment, mobility, incubation, and job descriptions.
User Experience	Facilitates DevOps journeys, experience, and value streams.
Regulators	Manage the alignment of regulatory demand responses.

Table 3.1 – Primary DevOps ecosystem stakeholders

As you can see, the primary stakeholders consist of more than just developers. To some extent, they represent the enterprise as a whole. Now, let’s extend the list a bit more by looking into the secondary stakeholders:

Table 3.2 – Secondary DevOps ecosystem stakeholders

The broad stakeholder’s ecosystem, as we will see later in this book, is used in several dimensions of the DevOps 360° operating model. As your new model comes to life, each of these stakeholders will not only support its formation but will eventually own parts of it that relate to their domain.

Stakeholder appointment needs to be conducted by people who fulfill the four qualities that we discussed at the end of the previous chapter due to the following reasons:

• For some domains, due to structural ambiguity, it will be difficult to identify the right people.
• Explaining to the broad stakeholders how they are expected to contribute, as well as what’s in it for them, will be necessary.
• A cross-capabilities stakeholder dependency matrix will have to be created.
• Knowledge of historical internal dynamics will be vital to overcome the resistance of stakeholders who do not see themselves as a direct part of the DevOps model.

Bonus Information

In a bank I used to work in, we identified 31 different domain areas that had to contribute to creating a new DevOps enterprise operating model. Imagine how far you might have to go and how much effort it might require!

Defining the evolution’s workstreams

Each DevOps enterprise OKR and pillar of the DevOps 360° operating model will be enabled through several workstreams running in parallel and delivering incrementally and continuously.

Organizing the workstreams

Your workstreams should be designed in harmony with each other and operate under the same model and principles, as well as having a very close connection to the vision authority group and the design and advocacy group. Each workstream will comprise several stakeholders from the broader ecosystem. They will have different roles, as shown in the following table:

Table 3.3 – Roles within workstreams

Consulting the DevOps enterprise OKRs and vision that we have defined in this book, we propose the following workstreams, accompanied by a one-line value proposition for each:

Figure 3.2 – Overview of the DevOps enterprise evolution workstreams

The following sub-section provides a deep dive into the operating model of workstreams.

Defining workstream scopes

The workstreams will be primarily tasked with the following activities; to demonstrate, we will use the Compliance as Code workstream as an example:

• Define the starting, intermediate, and target states for the workstream:
  • Starting: Bureaucratic DevOps controls policies and inadequate implementation.
  • Intermediate: Policy engineering and minimum viable adherence adoption. These are two terms that we will discuss in detail in Chapter 8, 360° Regulatory Compliance as Code, and Chapter 10, Tactical and Organic Enterprise Portfolio Planning and Adoption.
  • Target: Policy as code embedded into the tech ecosystem and an automated minimum viable adherence mechanism established.
• Define the key domains across the broader DevOps stakeholder ecosystem that are to be part of the implementation. In our example, we foresee that we will need to involve security, IT audit, IT risk and controls, common platforms, and DevOps teams.
• Define the core initiatives for the enablement teams and support their backlog creation:
  • I1: Controls revision and simplification. Assigned to the DevOps CoE.
  • I2: Automated evidence generation. Assigned to the common platforms.
  • I3: Automated adherence attestation. Assigned to service governance.
• Facilitate the piloting of the teams’ part of the tactical evolution, as we will see in Chapter 10, Tactical and Organic Enterprise Portfolio Planning and Adoption. For instance, digital banking domain applications would need to be supported while piloting the DevOps controls, which we will further discuss in Chapter 8, 360° Regulatory Compliance as Code.
• Reconcile and align its initiatives with those of the other workstreams. For example, align with the DevOps speed, journey, and experience workstream to ensure that the new DevOps controls mechanism is tactically embedded in the new SDLC and can be consumed as a service in the new common CI/CD pipeline for cloud-native applications.
• Support the definition of the DevOps evolution enablement and adoption OKRs.
• Raise decision points for the authority groups. For example, will the control’s minimum viable adherence be mandatory across all business applications?

Minding the balance

With the formation and operation of the workstreams and the work that they will generate for the evolution’s enablement and adoption teams, a large proportion of your organization will have to be mobilized. Therefore, it is important to find the right balance between business as usual, other change activities, and the DevOps evolution. This will make people feel less distracted, plus it will be easier to institutionalize the evolution and make it organic in the long run. Let’s say you were to do enterprise business continuity testing in one month, upgrade the central JIRA instance this weekend, decommission the legacy trade general ledger application next month, and provide an update to your auditor on the progress of controls implementation in the next quarter. Build on those already-planned initiatives and let people continue delivering on what is already planned while injecting the evolution’s objectives and outcome incrementally. Overloading the organization or freezing it until you get the planets of your DevOps universe aligned is irrational. Remember that we have chosen the evolution type of strategic change to ensure that the organization evolves incrementally through interrelated activities without the need for radical actions and urgency.

Bringing it together

The following diagram summarizes the governing and materialization actors of your DevOps evolution:

Figure 3.3 – Governance bodies and stakeholders illustration

As you can see, there are two actors labeled as orchestrators that we have not focused on in this chapter. The next chapter will be dedicated to them.

Understanding the governing dynamics

Eventually, you will need to reach an equilibrium across the main governing bodies of the evolution and its executors. By the term equilibrium, we indicate a situation where every stakeholder balances what is best for the part of the organization that they represent with what is best of the organization as a whole. Being inspired by the Nash equilibrium, I borrow the phrase governing dynamics and add an element of DevOps to it. One of your aims in your evolution should be to come into a DevOps equilibrium across the organization by doing what is best for individual areas and what is best for the broader organization. One of the ways to do that is to ensure that you understand and balance your DevOps governing dynamics. Governing indicates both the ones that govern (the vision authority) the evolution, but also the ones being governed (the organization’s lower levels) in the evolution.

Understanding the balance of power in the governing bodies

Balancing the power of the members of the governing bodies we discussed earlier in this chapter will be a complex yet necessary activity to perform. Typically, and especially among senior stakeholders, you will observe the following types of power that different people possess. Those different types of power should eventually come into a balance-of-power equilibrium:

• Hierarchical: The power that comes with a given position
• Personal: The power that comes from being influential and persuasive through personal appeal
• Agenda setting: The ability to set the agenda for any discussion or decision making
• Information: The power that comes from having privileged access to insightful information
• Knowledge: The power that comes from deep domain knowledge and expertise

Bonus Information

The balance-of-power theory in international relations suggests that states may secure their safety by preventing any other state from gaining enough power to dominate everyone else. Typically, states choose between two tactics – balancing, by creating alliances with others, and bandwagoning, by aligning themselves with the power that threatens them.

Bringing two different worlds together

Your organization probably runs with two modi operandi that focus on autonomy and alignment. Some teams operate autonomously, seeing any centralized decision-making only as a bureaucratic means of controlling them, while others operate in alignment, following central decisions and direction. Those two worlds have certain characteristics that you can use to spot and manage them, as you will have to bring them into equilibrium:

Table 3.4 – Organizationally aligned teams versus autonomous teams

These dynamics will have a key role in your evolution as you will see some people that are not in managerial positions, for example, being reluctant to make decisions without their managers’ involvement, while with others, it will be the opposite. Also, while you will find people who are used to working in alignment with a central governing body and find it acceptable and desirable to work toward a common model, you will find others who feel that a common model violates their need for freedom, autonomy, and independence.

Speaking the same DevOps language

One of the fundamental aspects of human interaction is language. Due to its versatility, breadth, and lack of universal definitions, DevOps is a source of several misconceptions. Some are due to a lack of literacy, others due to convenience (as in, what they feel more comfortable with is what they will keep understanding, raising resistance to new ideas and concepts), and still others are due to promoting personal agendas within an organization. For everyone to make sense of each other during a DevOps evolution, you need to be able to speak the same DevOps concepts language, while killing DevOps misconceptions. Therefore, it is important to align concept definitions and perceptions. We have all been in a DevOps meeting where release velocity was confused with release management and where continuous delivery was considered the same as continuous deployment, while self-healing and auto-healing were implied to be identical.

It is not only a matter of definitions but also of perceptions. For instance, we have all participated in a debate where cloud-native, for some in the room, is perceived as necessarily referring to the adoption of public cloud capabilities and for others is perceived as referring to certain characteristics and qualities of an application and its infrastructure, such as scalability, modularity, and containerization. You should not be surprised to find conceptual misunderstandings and misperceptions during a DevOps evolution. While you cannot achieve a perfect understanding overnight, especially considering the fact that conceptual understandings require experience and knowledge, you can start by creating common definitions that get everyone on the same page and tailor them to your context, objectives, and vision:

Figure 3.4 – The DevOps language tree

Collectively defining the DevOps enterprise evolution lexicon within your governing bodies can help you set the fundamentals of DevOps communication among those groups and then cascade them to the rest of the organization. You can find plenty of DevOps lexicons by just googling them, and it is advisable to use one of them as a foundation to build on top of, using your organization’s understanding and interpretation of certain DevOps concepts as well as your own DevOps definitions and vision. Using the same language will help the DevOps CoE to understand its client and help the core platform teams to align with the enterprise architecture. This will also bring more consistency to your documentation and give you a better understanding across various stakeholders, including your business partners and regulators. However, you should expect that areas with vast contextual and technological differences, such as your core IBM Mainframe z/OS platforms and your cloud-native applications, representing two different generations will never speak the same language. They do not need to.

True Story

Once upon a time, a peer asked me to give a DevOps presentation to their team. They were starting their DevOps journey, balancing between traditional software development and ITIL, and were looking for inspiration from other teams. I made a nice deck, putting together the best of my team’s DevOps adoption, and met them. I always keep eye contact while presenting to capture reactions so that I can adjust my presentation style. To my surprise, I mostly observed bewilderment in the room. Ending the presentation, I asked if anyone had any questions and there were none. Then, I asked something to the effect of, “Did I confuse you?” One person responded, “Where can we find the definitions of the DevOps terms you used? This is the first time I’ve heard of them.”

We all have numerous stories such as the preceding one to tell. Some are quite entertaining, with people getting into conflict situations not because they were disagreeing, but because they were using different terms that meant the same thing. A common DevOps lexicon is a foundational tool that will not solve all your communication and perception challenges, but it is a good start. In the coming chapters, we will discover more tools and frameworks that will get you closer to speaking the same DevOps language.

Understanding your organizational structure dynamics

Organizational structures and hierarchies are core influencers of your DevOps enterprise evolution governance model and execution. Reporting lines, business operating models, and capabilities demarcation not only define your daily operations and dynamics but also establish an optimal governance mechanism. In this section, we will discuss three of the most dominant structural use cases found in incumbents, along with their potential implications. You will notice that we will be using the past tense when describing the use case dynamics that arose as we are observing real situations that occurred in the past.

What to look for in your organizational structure

The purpose of outlining these models is not to deep dive into the reasoning behind banking organizational structures as those are deeply rooted in the internal context and business model of each incumbent. Instead, we aim to highlight the core organizational structure elements that can generate DevOps structural constraints or efficiencies and need to be considered when deciding on a DevOps enterprise evolution governance model. The main elements of focus are as follows:

• DevOps capability concentration and density
• Strategic direction influence
• Decision-making authority
• Power polarity

In each use case, the organizational hierarchy starts with the group’s COO for two reasons. Firstly, your DevOps evolution will, to a certain extent, alter the way your organization operates with your group COO as they are the ultimate owner of the organization’s operating model. Secondly, the group COO is one of the main executives in your organization who interacts directly with your main regulator and is accessible to your largest and wealthiest clients. It is common in incumbents that regulatory audit reports and corresponding remediation actions are addressed by the respective COOs and also that large and wealthy clients have COOs on speed dial. Keep in mind these common characteristics of the COOs as we will return to them later in this book.

Use case 1 – segregated business technology lines and group technology

In this use case, we have several business technology lines, each one having a dedicated COO and CIO, with the application development teams being embedded. Those business technology lines are segregated by group technology, where the application operations and common platform teams are located, and are headed by the group CIO or CTO:

Figure 3.5 – Segregated business technology lines and group technology structure

Assessing the situation against the four main elements of focus, the following observations were identified:

• DevOps capability concentration and density: The segregation of people building software belonging to business IT areas and the people running software belonging to group technology caused tension and misalignment in the operating model domain’s design. The technology operations teams were not embedded in the incumbent’s DevOps adoption and therefore were not able to influence the operating model, which was primarily driven by the business IT areas having a dominant presence in the governing bodies. Also, as the business IT areas had built their own shadow IT DevOps solutions, they were very reluctant to move to common platforms, which resulted in solution interoperability challenges and the poor capturing of business IT requirements.
• Strategic direction influence: This was a one-to-many relationship on the leadership side reporting to the group COO, which shifted the balance of strategic influence and direction setting toward the IT business areas, which were also closer to the corporate strategy formation process. A conflict of interest came about as the most influential CIOs in the business IT areas favored their own interests and opposed the central group technology direction.
• Decision-making distribution: The business IT areas had full authority within their organizations and were not fully aligned, with the digital frontier CIOs having more decision-making freedom and influence, especially over group technology. In addition, group technology was being funded by the business IT areas, which also influenced the distribution of decision-making power. Therefore, decision-making was technically anchored to the most influential COOs and CIOs of the business IT areas.
• Power polarity: The situation involved balancing multipolarity and bipolarity among the several IT business areas that were, on the one hand, joining forces when in conflict with group technology but, on the other hand, were also acting unilaterally.

Bonus Information

Polarity in international relations refers to the way power is distributed within the international system. The main three types of polarity are unipolarity, one superpower; bipolarity, two superpowers; and multipolarity, several superpowers. Our current international system’s polarity is characterized by multipolarity between the United States of America, BRICS, and the European Union.

Use case 2 – segregated business and technology

There was complete segregation between business and technology, with all technology units, including those concerned with the development and operations of business applications, being under the same organization. However, there was a dotted line connecting the business lines of the CIOs and COOs:

Figure 3.6 – Segregated business lines and technology

The following are the main observations regarding the four elements of focus:

• DevOps capability concentration and density: All the technological capabilities, including application development for the business areas, were concentrated under the group CIO, who owned the group’s technological means of production. This situation resulted in a better jumping-off point for striving toward technological capabilities consolidation, as well as alignment with DevOps organizing principles and topologies. The structural segregation between business and technology was bridged by the reconciliation of the DevOps and business agility operating models, with business stakeholders being embedded in the SDLC and holding the product ownership role.
• Strategic direction influence: An initial strategic gap formed as the priorities of the corporate and technology strategies became misaligned when it came to the DevOps enterprise OKRs, which also impacted alignment with the DevOps vision. This was primarily driven by the group CIO. While the business units’ influence over the business CIOs reporting to the group CIO and their control of the DevOps team’s backlogs was maintained, the gaps were eventually bridged to a certain extent.
• Decision-making distribution: The decision-making process initially followed the path of the strategies, with the business COO focusing primarily on business line decisions and the group CIO driving the technological ones. This resulted in several decisions being misaligned in the DevOps capabilities evolution. A representative example is the public cloud provider’s due diligence case. Did anyone ask the business? was a question that was raised repeatedly, highlighting the situation.
• Power polarity: This was the definition of a bipolar setup between business and technology. A broad coalition of the business areas was observed towards the group technology unit in cases of disagreement with the decisions and direction taken by group technology.

Use case 3 – consolidated business and technology domains segregated from the core technology

This use case is characterized by a heavy concentration of the business lines, where both the application and operations development teams were under them. They faced a “slim” group CTO area that was primarily offering infrastructure and common platform services:

Figure 3.7 – Consolidated business and IT domains segregated from the core technology

The observations according to the four design elements we are focusing on are as follows:

• DevOps capability concentration and density: There was a very uneven concentration of DevOps capabilities, between the business lines and group technology, with development and operations fully embedded and autonomous under the business lines, owning their own DevOps solutions, and having full control of the DevOps budget. The group technology unit was struggling to create demand for its common platforms and was soon faced with internal competition due to public cloud capabilities being built into business IT areas.
• Strategic direction influence: The business and technology domain lines had full influence over the corporate and technology strategies as well as DevOps vision, with the group technology unit being perceived purely as a utility delivering on the business line demand.
• Decision-making distribution: The vast majority of important decisions were taken by the business and technology domains, with the core technology unit just being informed after the fact. However, there was a challenge in gaining collective agreement due to the large number of IT leads not being represented by a single person. The absence of a single IT lead representative led to decisions not being followed equally by all IT leads.
• Polarity: The most definitive characteristic was the unipolarity of the business and technology domains.

As we can see, organizational structures have a significant influence on your DevOps enterprise evolution and governance. This influence will become more profound if you combine your DevOps evolution with organizational changes, as well as evolution in your business agility model, which is a common approach that many incumbents follow.

Summary

In this chapter, we introduced the core pillars of the DevOps 360° operating model, which we will discuss in more detail in the coming chapters. We also defined the two main governing bodies of the evolution – the vision authority group and the design and advocacy group, while we also discussed the workstreams setup. We covered their responsibilities.

Then, we outlined the core DevOps enterprise stakeholders’ domains that are of relevance to the evolution, along with their value propositions. The need for all these stakeholders to speak the same language was addressed and we proposed how to define a common DevOps evolution lexicon.

After that, we moved onto a critical dimension of the evolution, which is to understand the governing dynamics by identifying the power dynamics of the key stakeholders, as well as to capture the operating model differences within your organization, focusing on the organizationally aligned and organizationally autonomous teams. Finally, we discussed three different use cases based on three incumbents, proving that different organizational structures can have a variety of effects on a DevOps enterprise evolution.

The next chapter is dedicated to two core orchestrating bodies of the evolution, the enterprise architecture and the DevOps center of excellence, the roles of which we will discuss extensively.