14

360° Recap, Staying Relevant, and Final Remarks

We have reached the end of this book. In this chapter, we will go over all the parts of the DevOps 360° operating model that we have seen throughout this book. We will highlight the most important concepts, frameworks, and aspects of each phase that we consider key takeaways from this book. Following that, we will provide an extra set of final remarks that various incumbents discovered during their DevOps evolutions so that you can learn from the mistakes of others.

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

• Recapping the DevOps 360° operating model phases
• Final remarks

Recapping the DevOps 360° operating model phases

Throughout this book, as we unfolded the core phases and aspects of the DevOps 360° operating model, we covered several DevOps terms, concepts, frameworks, and practices. This book and its flow were structured based on a triangular model:

• Each chapter consisted of a small “DevOps pocket guide” for the domain and phases of the DevOps 360° operating model that it was representing.
• The sequence and flow of this book’s chapters took you through a potential array of steps for designing your model.
• All the chapters represented a relatively complete DevOps 360° operating model.

We covered quite a lot in this book, so you may not be able to remember everything. You may have also been a little bit puzzled about what knowledge to retain from each chapter. In this section, we will go back to the beginning of this book and reflect on it. This will help you refresh your memory regarding the most important aspects of the DevOps 360° operating model.

Context and DevOps value proposition

In Chapter 1, The Banking Context and DevOps Value Proposition we started by introducing the main actor of this book: the incumbent bank. That was not only to introduce you smoothly to this book but to also highlight that who you are as an organization can significantly influence your DevOps adoption. We also stressed the importance of examining and understanding your internal and external context and how they work together from a DevOps perspective. After, we defined the DevOps value proposition for banking, starting with outlining the definition of DevOps that we would use throughout this book. The value proposition we detailed went word by word through our definition, providing examples of DevOps practices that support its materialization, while using a mobile banking application as an example.

Then, we introduced two of the major themes of this book that underpin its philosophy and approach: relevance and 360°. I strongly recommend that you also use these as guiding principles in your DevOps evolution. Regarding the former, we discovered how situations and circumstances vary across the context of an incumbent by using examples of equity trading and settlement. Try to find similar examples in your context so that you can use them as foundations for your at relevance mechanism. Regarding the latter, we outlined the four qualities of 360° with examples – that is, completeness, continuity, reconcilability, and interoperability. Please keep these in mind throughout your DevOps evolution. The concepts of relevance and 360° were continuously used throughout this book.

“Multi-speed,” vision, objectives, and change elements

Chapter 2, The DevOps Multi-Speed Context, Vision, Objectives, and Change Nature was very rich in terms of content due to its importance in setting the foundation for the DevOps 360° operating model. Initially, we defined the concept of multi-speed in banking, which, together with the concepts of at relevance and 360°, constitutes the foundation of this book. Examples were provided on how speeds are constructed naturally but also intentionally and we stressed the importance of understanding this. Understanding how different speeds are shaped in your organization will help you apply sophistication to your evolution.

Then, we highlighted the decisive need to understand your internal DevOps state-of-art concept and outlined a representative picture of it as a collection of several incumbents. In particular, we explained the multi-layer nature of your DevOps state-of-art context and the need to capture it. Please invest heavily in understanding where you stand in the early days of your evolution.

The most important part of this chapter was defining the DevOps vision and objectives. We started by highlighting the role of the corporate and technology strategies while providing a representative example of where incumbents place their focus when shaping them. The need to reconcile the two strategies was highlighted as a fundamental element of defining your DevOps enterprise OKRs.

We focused on the DevOps enterprise OKRs and provided some concrete examples that you can use in your evolution. For each, we investigated the main objectives, key results, linkage to the corporate and technology strategies, as well as motivating factors. The consolidation of all those OKRs and their materialization led us to define the overarching object of a 360° DevOps operating model.

Finally, we focused on the need to decide on the nature and extent of your DevOps adoption, concluding that evolution is the most suitable and sustainable path. Please do not boil the ocean by being unnecessarily radical!

The 360° DevOps operating model skeleton and governance

We opened Chapter 3, The DevOps 360° Operating Model Pillars and Governance Model by providing a visualization of the core pillars and phases of the 360° DevOps operating model so that you could foresee what was to follow in this book, all while grasping the big conceptual picture. As we moved on, our main focus was to provide recommendations around the governance bodies that you could consider establishing during your evolution to steer its direction. The DevOps 360° vision authority and the DevOps 360° design and advocacy group were mentioned as the leading governing bodies. Then, we looked at the broader DevOps stakeholder matrix, where we outlined a plethora of stakeholders that you could potentially involve while stating the DevOps value proposition for each. References were also made to the DevOps workstreams you could establish by designing the outcome of each of the DevOps enterprise OKRs.

Finally, we focused on the necessity to understand the dynamics of the DevOps 360° evolution and its stakeholders, who have a significant influence on that evolution. In an attempt to make the dynamics more vivid, we presented and discussed three use cases from different incumbents, whose organizational structure had an impact on their evolution.

Enterprise architecture and the DevOps center of excellence

Chapter 4, Enterprise Architecture and the DevOps Center of Excellence focused on two vital orchestrators of the DevOps 360° evolution, which we also perceive as part of the main governing bodies: the enterprise architecture and the DevOps Center of Excellence (CoE).

We looked at the multidimensional value proposition of the enterprise architecture and focused on three main domains. We discovered the importance of defining your portfolio’s critical path in terms of domains, flows, applications, and services. That, as we saw later in this book, provides the foundation for the tactical part of the evolution. After, we examined the four major platform modernization strategies that an EA function can help form. We complemented this by covering their business case drivers and providing real financial services industry examples. The last domain that we discussed from an enterprise architecture perspective was reference architectures, where we outlined their importance for DevOps acceleration and standardization while citing the most important reference architectures that incumbents adopt.

From a DevOps CoE perspective, we examined its value proposition through the potential roles it can have in your evolution. We looked at it from the angles of the evolution’s maestro, the DevOps 360° operating model owner, the technological capability provider, as well as the tactical enablement partner. We concluded that, as with DevOps as a concept, the way you set up your DevOps CoE is characterized by “what you make out of it” and it will be shaped according to your ambitions. To create some inspiration, we provided four use cases from four different incumbents that approached their DevOps CoE establishment in different ways.

Business enterprise agility and DevOps ways of working

Chapter 5, Business Enterprise Agility and DevOps Ways of Working Reconciliation introduced us to the world of business enterprise agility. We started by discussing how it can be reconciled with DevOps, concluding that both concepts need each other to deliver the maximum return on investment. After this, we discussed the four dominant enterprise agility models in the financial services industry and examined them from a DevOps perspective. We concluded with two main observations that I am certain you can relate to. The first one is that DevOps can be adopted agnostically in any enterprise agility model, while the second is that all enterprise agility models share similarities in how they deploy certain DevOps concepts. I urge you to invest your time and effort heavily in ensuring the agnosticism of these two concepts.

After that, using the Spotify model as a basis, we provided an 11-step proven practice on how to define the DevOps ways of working and organizing principles for your Agile DevOps teams. By doing so, we examined important elements of relevance that you should consider since one WoW cannot fit all. The proven practices were based on certain templates that you can adopt in your organization.

DevOps SDLC 360° evolution and engineering

Chapter 6, DevOps Software Development Life Cycle 360° Evolution and Engineering was dedicated to the heart of the DevOps 360° operating model. To start this chapter, we discussed the importance of considering the four qualities of 360° when designing an evolved SDLC, along with ensuring the DevOps equilibrium is fulfilled. Then, we provided you with some inspiration about the potential SDLC phases, which you can use as a foundation to design your evolved SDLC. In particular, we focused on the importance of frameworks and the capabilities that belong to their various phases. Carefully designing these fully is an important proposal we made. In supporting you, we provided a proven eight-step guide that you can use either by the book or adjust to your own needs. You should be extra conscious about designing your DevOps 360° SDLC paths based on relevance and speed. Not all of your portfolio has to follow the same path and that should be reflected in your DevOps paths designs and DevOps capability catalog. In addition, from the SDLC early design phase, you should set the target for the velocities that you expect to meet via its adoption. This move is foundational for the next phases of the DevOps 360° operating model and how they benefit measurement and realization.

The DevOps 360° technological ecosystem as a service

In Chapter 7, The DevOps 360° Technological Ecosystem as a Service we focused on the part of the DevOps 360° operating model that most people find more interesting to work with: technology. We started by looking at the high importance of bringing clarity to the misunderstood relationship between technology and DevOps. Technology is a DevOps enabler, not DevOps itself, and this is something you need to clarify within your organization. After this, we provided a detailed picture of why you should pursue technology standardization during your DevOps 360° evolution, while also taking precautions and carefully assessing your circumstances. Using standardization clean cuts is the most viable approach that we proposed for your consideration. Then, we discussed the value proposition of platform teams while looking into proven operating and service models that you can consult when designing yours. Remember to put extra focus on defining the platform team and agile DevOps team’s white paper and social contract to ensure clarity of expectations from both sides. The DevOps journeys, experience, and productivity should be another area to focus on, along with assessing their impact on the ways of working applied by the agile DevOps teams. In case you decide to pursue the approach of platform teams across your DevOps 360° technological ecosystem, we highlighted some platform team domains, along with their corresponding services, that you can consider enabling.

360° regulatory compliance as code

Chapter 8, 360° Regulatory Compliance as Code was dedicated to the notorious regulatory compliance domain of DevOps. Understanding the regulatory landscape that influences your DevOps 360° evolution helps with your evolution’s fundamental activities, along with conducting a preliminary impact assessment in case you do not manage to fully comply with regulatory requirements. Our advice is to take full advantage of these requirements to accelerate your DevOps 360° evolution. For inspiration, you can go back and look at the four stories that we provided. Primarily, my advice is to focus from a regulatory compliance perspective on the DevOps controls and segregation/separation of duties domains. Understanding the full anatomy of the former and embedding them using engineering means across your SDLC should increase your speed while ensuring compliance and improving reliability. You can consult the array of controls we proposed and adopt them based on their relevance to your context. We also provided very rich considerations that you can benefit from when designing and implementing the controls. Regarding segregation/separation of duties, you must focus on two determinants: data and duties. Separation of Duties (SoD) must be applied with relevance to your context. We saw how that can happen regarding the rotational and fixed-model ways of working. Having dynamic and robust identity and access management capabilities, as well as strong logging capabilities, will be fundamental to proving SoD compliance. Discuss these with your regulator to avoid a hardcoded SoD, meaning implementing SoD as an impenetrable wall between development and operations. Remember that this must happen early in your evolution to bring clarity to your relationship with your regulators in terms of scope, decisions, and expectations. To define the topics of this discussion, you can consult the list we provided.

The DevOps portfolio classification and governance

Chapter 10, Tactical and Organic Enterprise Portfolio Planning and Adoption was the core of the at-relevance principle. We highlighted the strong importance of classifying your portfolio and noted that not all of your applications will go through the same DevOps journey. Two classification types that you can consider using are criticality and impact and technology and architecture. Combining the two will give you an even more well-rounded and dynamic at-relevance mechanism. You can consult the examples we provided regarding whether DevOps becomes relevant or not based on the classification of each business application or platform. Remember to include the DevOps platforms in the process. To help you define the DevOps speeds to complement the portfolio’s relevance, we provided a speed formula based on five variables that you can play around with and shape the formula according to your context and ambitions. Speed comes with responsibility, and you should trust but verify, along with providing direction. You can get inspiration on how to launch the concept from the sample governance model we provided. Later in this chapter, we discussed the portfolio governance aspects, and we stressed the importance of performing a tiered portfolio registry based on the business domain, applications, services, IT assets, and DevOps attributes. These are the DevOps attributes you must use as part of defining relevance and speeds. The core mechanism that we proposed you use during the portfolio registry, also alongside your evolution, is the production readiness review. You can consult our example and build on top of it. To relate the license to continuously deliver and the production readiness review, you can look at the distinction we made at the end of this chapter. One of the most important elements of this chapter to remember is the concept of DevOps minimum viable adherence. If you manage to effectively launch the minimum viable adherence concept, you will achieve a decisive victory in your evolution by aligning your whole organization with the adoption of fundamental DevOps capabilities.

Benefit measurement and realization

Chapter 11, Benefit Measurement and Realization introduced us to the traditionally challenging domain of benefit measurement and realization. We provided arguments on why you should try to think more broadly than the mainstream DevOps indicators and metrics. In addition, we talked about why you should aim to define targets, instead of indicators, considering the difference between a proof of success and an indicator of success. Distinguishing between targets and metrics will be very beneficial. Remember that the former is what you wish to achieve via the target, while the latter defines how you measure progress toward achieving that target. We strongly recommend engaging the broad array of stakeholders in your DevOps ecosystem to help define the target and metrics; you can use the small exercise we proposed to help with this. To bring more sophistication to this measurement, you can consider using the minimum viable adoption – minimum viable adherence – efficiency three-tier system. Come back to this chapter and look at the example we provided for guidance. For your reference, we provided some practical KPTs and metrics that you can borrow with pride. Finally, when doing the math for calculating your KPTs and metrics, remember that data is gold and its visualization helps you demonstrate progress. Once again, read through the further recommendations we provided to avoid pitfalls. Last but not least, please do not establish KPTs and metrics like the ones we cited at the end of this chapter.

Hiring people, incubation, and mobility

In Chapter 12, People Hiring, Incubation, and Mobility we focused on the DevOps evolution’s most valuable asset: people! We proposed that you should aim to enable Π-shaped profiles by balancing a broad DevOps awareness (the horizontal line) and deep specialization in two DevOps domains (vertical lines). When deciding how your Π-shaped profiles will be enabled, consider the evolution of the roles in the future to ensure that your profiles will be fit for purpose as time goes by. A lot of your efforts will go into hiring and incubation since your organization will likely not initially possess the skillset your evolution requires. When defining your hiring tactics, consider the parameters we have outlined. On the incubation side, remember to include your organization’s leadership, be targeted and work-driven, and stay relevant. We also recommend investing in people’s mobility within your organization, but please take precautions by consulting the areas that we outlined.

Site reliability engineering

I must admit that I wanted to give you even more meat in this chapter. I promise I will do this if there’s a second edition of this book. Chapter 13, Site Reliability Engineering in the FSI was dedicated to SRE – the purest distillation of DevOps. The first thing you must do to start a scaled SRE adoption is to reconcile it with DevOps and provide clarity on the DevOps versus SRE dilemma. Kill the misconception from the start, making it clear that the two concepts do not conflict. As we proposed, use the tenets (the common set of responsibilities across SRE teams) to reconcile the two concepts and define the SRE’s responsibilities. You can either use the ones we provided out of the box and adjust them or create your own. At the end of the day, SRE is what you make of it. The choice is yours. There are a few things to remember regarding the tenets: you must shift SRE left, monitor the balance, and understand that despite SRE being an operations-focused concept, it spans across the SDLC and provides gatekeeping authority using mechanisms such as PRR. As with DevOps, you need to apply SRE when it’s relevant. We have cited several mechanisms from which you can draw inspiration. Consider the SRE eligibility parameters, distinguish between a tactical and an organic adoption, define an engagement model, and reconcile it with your ITIL adoption. By enabling the concept from a people perspective, there are several SRE professions you can define and get inspiration from the four we proposed. If you want some inspiration based on what others have done when deploying SRE, then take a look at the four use cases we listed at the end of this chapter. I urge you to not follow the path of the last one.

Final remarks

I have four final remarks before I say goodbye. Let’s take a look.

Do not use DevOps to mask cost-cutting initiatives

I’ve seen this happen in several contexts and it never worked in the long run. You can optimize your operating expenses through DevOps outcomes, and you should aim for that. But having cost-cutting initiatives as your top DevOps priority without creating decisive efficiencies and adding end value is just wrong. Yes, it may make your balance sheet look better, but your daily operational reality will most probably get worse and be unsustainable in the long term. Also, your people are not of low mental capital. They will understand your incentives early on and plan their futures accordingly. The people on the ground care about building great solutions, not the cost/income ratio.

Manage uncertainty and the people exodus

There will be uncertainty during your evolution. DevOps will not be the only thing your organization focuses on and until you start making solid steps of progress and create a meaningful coalition (if you ever do), there will be a sense of uncertainty. This will inevitably cause a people exodus where people will resign and leave your organization. You know it will happen; you have probably seen it before. And you also know that it will be the very best ones that leave first. I have personally seen this happen again and again in the context of incumbents. It is an inevitable part of human nature to fight for survival when feeling that your future is at risk (do you remember Hobbes’s metaphor of brutish life from earlier in this book?). A people exodus will heavily jeopardize the progress of your evolution. Therefore, through speed in your thinking and evolution, you must provide transparency, communication, people engagement, continuous demonstrated progress, and constant reassurance to keep your people motivated and engaged. Increased salaries and bonuses that you might use as retention mechanisms will not keep them around for long – they will only buy you a few months.

Note

Do not use uncertainty as a vehicle to get rid of human debt. I heard that as a saying once. The idea is that if they (referring to the people with outdated skills) do not know whether they will have a job tomorrow, they will hopefully leave themselves, so we do not need to fire them and pay any compensation. In the end, they do not leave because their skills are outdated, and they cannot find another job.

Balance “changing people” with “changing the people”

Once upon a time, I had a CEO who used to say, I do not want to change people; I want to change the people. The former change was indicating a fire-and-hire tactic, while the latter change referred to an incubation tactic. Focus on doing both strategically and thoughtfully. You will never be able to hire all the people and skills you need and, equally, you will never be able to effectively incubate everybody. Some you need to let go of and others will need to be incubated. However, I do urge you to bring new blood into your organization. At the end of the day, I believe that if you already had the right people, you wouldn’t need to run a formal evolution and would never need to incubate them. This would have happened already organically. Think about it…

Manage your budget wisely

I know of two DevOps evolutions that ran out of budget in two different incumbents. One was terminated and the second one was compromised in terms of scope. I appreciate that life is uncertain, and I have mentioned that uncertainty aspect and its potential influence on your DevOps evolution in several parts of this book. But at the same time, I also think that if, all of a sudden and without a major event originating from the external environment, you realize that you do not have any more DevOps funding, it would call into question just how DevOps-serious you are. If you find yourselves in that situation, it is a clear signal of a lack of true incentives, a sloppy business case, and naivety on what it takes to evolve DevOps in harmony at an enterprise level.

Busting the misconception about banks

For better or worse, I have spent my whole career working with banks. Some realities and myths surround banks. People say that banks are slow, bureaucratic, cannot implement DevOps and SRE, are heavily regulated, are old-school in mentality, are only profit-driven, are left behind in digitalization, and so on. And while those statements describe the reality of several banks, especially large ones, they are not unavoidable stoppers of DevOps evolutions. Banks have changed rapidly in recent years and as we have seen in this book, there are plenty of DevOps success stories out there driven by banks. It simply takes passion, emotional intelligence, and good brains.

Summary

Summarizing the summary is irrational and therefore I will omit it. So! That was it for this book on DevOps in the financial services industry. I hope that you enjoyed reading this book as much as I enjoyed authoring it. To be honest, I found it pleasantly challenging to fit all my DevOps stories and practices into a little bit more than 300 pages. Nevertheless, I am confident that you have found plenty of useful ideas, frameworks, and concepts that you can apply in your DevOps endeavors. Having said that, I would like to wish you the very best in your DevOps adventures. Enjoy, envision, and keep pushing! If you wish to have a DevOps coffee and tell me about your DevOps stories, you can find me on LinkedIn.

One last thing for you to remember before I go is that where there is love, there is DevOps!

Over and out!

Σπυρίδων