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:
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:
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.
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.
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:
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:
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:
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:
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.
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.
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:
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!
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.
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.
The workstreams will be primarily tasked with the following activities; to demonstrate, we will use the Compliance as Code workstream as an example:
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.
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.
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.
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:
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.
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.
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.
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.
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:
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.
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:
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.
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:
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:
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.
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.
DevOps Domain/Stakeholder |
Value Proposition |
Secondary | |
Legal |
Supports regulatory negotiations |
Vendor Management |
Manages the renegotiation of contract terms |
Third-Party Vendors |
Offer technological foundation utilities |
Managed Services |
Offshore teams that support development and operations |
Friendly Customers |
Customers that support the piloting of new products |
Partnerships |
Partnering incumbent banks, technology innovators, and management consulting firms |
Roles |
Description |
Owner |
A vision authority group member who has expertise in the workstream’s domain of focus. This member also represents the business partners of the incumbent. |
Lead |
A senior member of the design and advocacy group who has expertise in the workstream’s domain of focus and who has coordination experience. This member, along with the owner, represents the business units. |
Integrator |
A person ensuring reconciliation with other workstreams running in parallel. |
Squads |
Permanent people who are appointed to be part of the workstream and come from the broader DevOps ecosystem. They are fixed for each workstream. |
Satellites |
Non-permanent members who join only when their domain of expertise comes into focus. They are not permanent and support several workstreams in parallel. |
The Organizationally Aligned | |
Differentiation |
Clear segregation of duties and responsibilities in the team |
Centralization |
Managers are fully aligned with central organizational priorities and decisions |
Standardization |
Tools, processes, and policies follow central standardization |
Supervision |
“Do not trust, get evidence and verify” |
The Organizationally Autonomous | |
De-differentiation |
Freedom when it comes to the allocation of tasks and responsibility |
De-centralization |
People have the space and mandate to go in their own directions |
De-standardization |
Flexibility in bypassing central tools, processes, and policies |
De-supervision |
“Trust, do not verify” |