Having already written about both DevOps in Kill DevOps and the challenge of selling IT initiatives to ‘executive hair’ in Sell me this IT, I thought that I now might combine the two. It was either going to be Kill IT or Sell me this DevOps and I’ve opted for the latter.
Most people who do or are DevOps (there’s another blog in “do or are”!) are enthusiastic about what they’re doing, and probably rightly so, but they find it difficult to explain why business executives should be interested. All this talk about CAMS and Continuous Everything makes sense to insiders but is complete techno-drivel to business folk. So let’s make an attempt to bridge the gap. Following Steven Covey’s maxim “first seek to understand, then to be understood”, we’ll start with the business. What language do business executives speak? MBA-ish. Benefits, costs and risks. Let’s explore these one by one.
DevOps and business benefits
Benefits depend on the kind of enterprise. The public sector will have different goals than the private sector. For instance, a Department of Justice would be looking at anything that contributes to the general public’s perception of safety and justice. While most private enterprises would be interested in the quantity and quality of revenue. For simplicity’s sake, we’ll explore the private case.
If you’re in the widget business, or the digiwidget business, you’re interested in a certain combination of selling more widgets, widgets for higher prices, and different widgets. So can we tell business executives that DevOps sells more, higher-priced or different widgets? Notice that I said “tell that”, not “tell how”. The higher up the corporate ladder you go, the more people are interested in what rather than how. You commit to deliver, and if you don’t, you’re out. Three strikes if you’re lucky.
Does DevOps deliver?
Before we can say whether DevOps delivers, we have to look at IT in general. The answer is, of course, yes. We can provide information systems with functionality that opens new sales channels (e.g. webshops) or speeds up the sales process. We can provide functionality that improves customer satisfaction (happy customers are loyal customers, and loyal customers buy more often and are prepared to pay higher prices). We can provide functionality that provides insight into customer behaviour that contributes to product innovation.
The next question is whether DevOps contributes to creating better functionality. It depends on your definition of the scope of DevOps. Seeing as there’s a reluctance in the DevOps community to define (and therefore restrict) DevOps, preferring a more fluid evolution, it’s more or less your call. If you believe in a broader application of DevOps in which DevOps encompasses development of functionality, then the answer is yes, DevOps contributes to creating better functionality. If, however, you just do or are DevOps in the deployment from Dev to Ops (something that Patrick Debois, the Godfather of DevOps, called DevOps Lite), then the answer is no, DevOps does not contribute to creating better functionality.
But in either case, DevOps does contribute to getting the functionality deployed quicker. And this means that the benefits that are related to the functionality will be accrued earlier.
DevOps also contributes to benefits by reducing the risk of outages, and therefore lost or delayed sales, and reduced loyalty, but I’ll deal with that in the section about DevOps and business risks.
DevOps and business costs
The first thing to do when talking to business executives about costs, is to distinguish between CAPEX[i] and OPEX[ii]. OPEX stands for operating expenditure and is the ongoing cost for running a product, system, or business. Its counterpart, capital expenditure (CAPEX), is the cost of developing or providing non-consumable parts for the product, system, or business.
We can confidently say that DevOps reduces both CAPEX and OPEX. Functionality is deployed and, depending on your scope of DevOps, developed more efficiently (but development is probably not reduced as much as deployment), leading to lower CAPEX. OPEX is reduced by improving the antifragility of the systems, leading to lower costs related dealing with disruptions.
DevOps and business risks
The term business risk [iii]refers to the possibility of inadequate profits or even losses due to uncertainties. Risks are internal and external, and are often classified into 5 main types:
- Strategic Risk associated with the operations of that particular industry, arising from:
- Business Environment: Buyers and sellers interacting to buy and sell goods and services, changes in supply and demand, competitive structures and introduction of new technologies
- Transaction: Assets relocation of mergers and acquisitions, spin-offs, alliances and joint ventures
- Investor Relations: Strategy for communicating with individuals who have invested in the business
- Financial Risk associated with the financial structure and transactions of the particular industry
- Operational Risk associated with the operational and administrative procedures of the particular industry
- Compliance (Legal) Risk associated with the need to comply with the rules and regulations of the government
- Other risks like natural disaster (floods) and others, depending upon the nature and scale of the industry.
Frequent change not a risk to stability
Contrary to popular belief, changing an information system frequently does not compromise the stability of the information system. By making changes frequently, you improve your capability to make changes well, leading to fewer and/or less disruptive malfunctions – particularly when the changes are small.
This clearly reduces operational and financial risks. Research[iv] backs this up. IT organizations that deploy code 30 times more frequently and 200 times faster than their lower-performing peers, have 60 percent fewer failures and recover 168 times faster.
When deployment to production is automated, compliance risk is also reduced[v]. Because the only entity with root access to production is the automation engine, you’re restricting the number of people who have root access and you’re creating an automated audit trail of what happens to production.
Strategic risk might also be reduced. It’s reasonable to assume that DevOps makes the IT function more flexible. This will be beneficial when there are unexpected changes, for instance in supply and demand, and when mergers and acquisitions require restructuring of the IT function.
DevOps and human benefits
A final and non-trivial consideration is that of employee satisfaction. The cultural change associated with DevOps entails giving practitioners more autonomy and involving them more in other decision-making. It is also about fostering a respectful, supportive work environment that emphasizes learning from failures rather than blaming; and about communicating a strong sense of purpose[vi]. This not only reduces stress. and therefore reduces turnover and increases productivity – it also benefits well-being and makes IT a great place to work.
IT practitioner summary
From an IT perspective, the main components that enable value are
- Functionality that enables better, higher-priced, lower-costed and different business
- A design that makes it easy for users to benefit from the functionality, and to impede the abuser
- Quick and reliable deployment of improvements into production
- Good operational availability, performance and security
- A flexible IT organization
- Lower IT costs
Much of this depends, however, on the user organization’s ability to articulate requirements, while the actual value realization depends on the information systems and services being used effectively, and the user organization playing its role in inhibiting abuse. Both business and IT have to be competent ‘dancing partners’ who anticipate each other’s moves.
Business executive summary
As far as business executives are concerned, an investment in DevOps contributes to the top line (revenue), while lowering both CAPEX and OPEX. It enables the enterprise to respond quicker and better to change, with a lower risk profile. Not a word of IT in there. Just as it should be.
Latest posts by Mark Smalley (see all)
- DevOps in a Baltic business context - October 2, 2017
- IT-Wise, Business-Foolish? Time to Look at the Bigger Picture - May 22, 2017
- A Journey from IT industry Guidance to Business Value - April 11, 2017