Why DevOps, Why MBA
Marc Andreessen’s maxim “Software is eating the world” has become an uncontested principle in the world of Business today. Software underpins and encompasses every single human activity, and the trend has only started.
This inevitably leads to another maxim: every company is in effect a software company. If it doesn’t consider itself one, and not working towards becoming better at it, it will go out of business soon.
In order to exist, survive and thrive, companies of all sizes need to create, build and deliver software to their customers. Be it a service, an app, a widget, an IoT device or an AI component, regardless of its nature and purpose, software needs to be conceived, developed and then reliably and securely packaged and shipped, in a way that is consumed continuously, as it evolves.
There are two distinct phases in the software lifecycle that coexist in a feedback loop, but are different in nature. The first one could be described as the creative endeavour of conception. This covers the Design and Development of the product. The prevailing way of going about doing that is the Lean Startup methodology, of hypothesis-driven development combined with fast feedback from users. The nature of the work in this phase has to be innovative, meaning that past experience is typically absent, whilst confidence in estimation and the variance of expected results is highly variable.
The second phase picks up from where the previous phase left things off, and proceeds to ensure that the proven hypotheses and the good ideas, can actually deliver their potential value. Its purpose is to reduce variability and uncertainty in results and estimates. The Intellectual Property created in the first phase, has to be packaged up and securely delivered to all customers on the various channels and outlets.
Nowadays, businesses compete at breakneck speed. Delivery cycles tend to get shorter, whilst the complexity of the products tends to increase with each update. The work required for this part of the software is essentially the Testing and Operations part.
<parenthesis>
Interestingly, in order to deliver the tools and platforms for this second category, first category thinking and mindset is required. That’s how AWS came to existence for example, or Docker or HashiCorp. There is a renaissance of Systems software as of late, but will leave that for a future piece.
</parenthesis>
So, how do we make those two different aspects of the s/w lifecycle work together?
Enter DevOps
But what is DevOps? It is a movement and a school of thought that sprung out of Operations. It’s a nuanced term that can be read with the Dev as an adjective to Ops, signifying a different style of Ops that understands and uses Dev in order to carry out its work. This is embodied in the Infrastructure as Code ideas and the SRE discipline as has been put forward by Google.
It has also been interpreted as a portmanteau of Dev and Ops, that creates a new discipline altogether, one that sits between pure Dev and pure Ops. This is an interpretation shared by many a CIO, IT manager and Recruitment Agent. Although widespread and commonly used, it’s unfortunately misguided, as it tends to just perpetuate the status quo, by adding yet another IT function that provides some useful capabilities, but fails to address the wider organisational needs.
Finally and crucially, it’s understood and used, as a tag to the culture, processes and tools that break down the wall between Devs and Ops. This is done by removing the silo mentality between departments across the organisation, thus enabling the necessary synergy across functions, which has become a prerequisite for coping with the increasingly complex and sophisticated software that is munching the world away.
Clearly, this wider collaboration does not apply just developers and operations and the rest of the tech disciplines that make up the software creation machine. Product owners and managers, SMEs and Business Analysts, all stakeholders, are an inherent part and need to be brought to the party. Hence, terms such as BizDevOps have been used in an attempt to capture the all encompassing nature of it.
Nowadays DevOps is mainstream. There have been three main attempts to capture the essence of DevOps.
People, Processes, Tools
Culture, Automation, Measurement, Sharing
The Three Ways of DevOps
All DevOps definitions comprise of two distinct elements. One is about the technical tools and skills required to provide automation, continuous integration/development/delivery/deployment, monitoring, orchestration etc.
This part is moving fast, changing all the time and going through a Cambrian period of sorts.
The other part though, is all about people, culture, process, sharing, change, transformation, strategy …
Enter MBA territory
But how can DevOps deliver to the full spectrum of its promises and vision, if the people who conceived it and practice it don’t necessarily have the right skills and attitude, while the ones who do have those, don’t actually get it?
It’s not by accident that the Phoenix book happy ends with the main character, a VP of IT Operations, getting a company funded 3 year training programme that will prepare him for the COO position.
Culture eats strategy for breakfast and vice versa. Change Management and organisational transformation usually mean McKinsey level of spent and involvement. We are clearly into MBA territory.
In this series, among other things DevOps, we’ll be addressing all those “MBA” aspects of the DevOps movement, in way that is not handwavy nor kumbaya. Rather, we’ll be looking through a contemporary management theory & practice lens.
Disclaimer: The author does not hold an MBA, nor is he a DevOps founding father figure. He is however deeply interested and somewhat experienced in both those fields. Above all, he is curious to see how they can be happily wedded, as it seems it’s become necessary, if not inevitable.
