DevOpsRun: DevOps is great but what about Run?

Is there a bigger picture than DevOps? (I defined it here). In theory no, it encompasses the whole IT lifecycle of services. But in practice it seems to me much DevOps discourse is still Build- and Transition-centric. We can expand thinking to all of DevOpsRun.

The Ops side of DevOps does tend to focus on Transition more than Operation. There are still people downplaying the importance of Operations, in the extreme case with daft ideas like NoOps.
I've coined the term DevOpsRun to reflect this potential for growth in the DevOps ideas.

Here is the presentation I gave at the excellent AgileNZ conference last year.

In summary:

1) My (limited) personal experience is that DevOps is still more Dev than Ops [comments folks?]

• The whole online face of the UK government is supposedly converting over to "Gov.uk". That means a lot of developers building to the new interface. They get advice on how to build, compiled as the "Government Service Design Manual". When it came out it was so lame on the Ops side that I mocked it. It has improved but as advice to teams operating and supporting the public face of British government services, it is still eye-poppingly glib in places.
• A hosting company that thought it would be OK for a government department to approve each release transition by replying to a phone SMS message.
• A software development and hosting company who were excitedly discovering the distinction between an incident and a problem
• A major corporation with six Agile IT product teams who all had entirely different transition and operations processes

2) A phrase I got from an Arrested DevOps podcast, and I think it was also raised at the DevOps Enterprise conference, is "Operational code not functional code". I'd like to see some data on how many DevOps teams truly build operational code not functional code: that is, code that is designed and built from the ground up to take account of such aspects as:

• Resilience
• Scalability
• Monitoring
• Database independence
• Compliance

When you are racing to meet sprint cycles, and users are waiting on the results, my gut tells me function wins over operation, and deferred technical debt grows. Prove me wrong.

3)There are a raft of risk management issues that trad Operations people are familiar with, which I don't see and hear so much in the DevOps conversations, for example:

• Impact on users: you cant just (constantly) roll out new functionality to non-IT users and expect them not to go into change shock
• Operating model: who does what, especially across complex multi-supplier value streams
• Security vs openness: there is a cultural disconnect exemplified by open source software
• Service levels: who defines, measures and reports them
• Compliance and audit
• Archiving data and the need to process data up to say seven years old
• Productionised IT tools
• Dark IT vs Shadow IT: the need for the organisation to have visibility and policy influence

Even running a single website can be fraught, when it is say for example Obamacare, but the complexities multiply when it is the complex interlocking systems of a corporation. People are solving these problems in the DevOps context, and the DevOps Enterprise conference was about just that. But as I listened to all the presentations at DOES14 I couldnt shake the feeling that if these were "horses" presenting, most had one blue spangly unicorn leg. That is, it was very often one team within the Enterprise who were doing their own DevOps thing, and the problem of enterprise-wide DevOps was yet to be solved. In particular, IT is the custodian of IT technology and information assets: IT constantly has to balance risk and value across that asset portfolio, to Protect and Serve.

4) The future for Continuous Delivery and DevOps needs to take into account:

• process over technology: cool tools are not enough. the bigger and/or more mission-critical it gets the more you need to manage it. In particular just having a Sevrice Desk function isn't enough: there needs to be strong process around requests, incidents, major incidents, problems, changes, and releases. I cant believe its 2015 and I'm reminding people of this, but don't worry: many trad shops still need to hear it too.
• legacy systems: how do we bring them into a DevOps methodology?
• complex value chains: how does the DevOps life-cycle work when development is not in-house? When support is outsourced? Or database admin?
• mainstream: DevOps is still a little fringe, and it attracts passionate committed people. That's nice. What happens when you have to work with the other 95% of the IT industry who haven't drunk the KoolAid, who aren't multi-skilled "renaissance people" as happy in Dev as in Ops? What happens when you try to do DevOps inside an enterprise that top performers don't wants to work for? When DevOps isnt exciting and leading edge any more?
• The Hype Cycle: ITIL went through it. You DevOps guys just wait - boy are you in for a ride!

5) The future for ITSM includes getting our heads around some key DevOps concepts, such as:

• Fail fast. Understand the benefits of this strategy and finds techniques to decide when the risk is acceptable.
• Operational Change Management as a facilitator instead of a gatekeeper
• Automation of transition and operations isn't a nice to have: its essential to survival. ITSM talks about automating Run: Event, Request, SL reporting..... But for expertise in how to do this stuff, those DevOps guys are the CoE.
• Infrastructure as code
• Creating a learning culture as compared to giving lip service to CSI as an after-the-fact back-room function.
• Trust culture instead of command-and-control. E.g. Developers should assess the risk of their changes - who else is better qualified to do so? They should also do the deployment into production for the same reason. [Sound of Ops brains popping]

======

DevOps can learn from ITSM and vice versa. I've talked about the potential for this cross-over before and I started capturing ideas in the Kamu Project.

In particular for this post, I still feel like not enough attention is paid to the Run aspect of Operations in DevOps as compared to the Transition aspect, and especially the Support part of Run.

You can take the boy out of the Dev but you can't always take the Dev out of the boy. (Sorry). DevOps can become stronger in thinking about how the service is going to work in its live state, how the risks to the organisation can be managed to the risk profile, and how DevOps principles can be applied to further improve Run.

I feel there is potential to use the DevOps CALMS principles to further strengthen Run in most organisations:

• Trust culture: the empowerment of people who know what they are doing to be able to do it. There is some crossover here with my Standard+Case approach. This also links in to giving them the tools to do it through...
• better automation of testing, release, monitoring, alerting, catalogue, request fulfilment, comms, service level monitoring and reporting, problem analysis...
• More application of Lean principles to ITSM processes: change, release, request, incident, problem....
• We talk about measurement in ITSM, but I think DevOps show us up with their devotion to data
• Likewise the DevOps emphasis on sharing is more committed than most ITSM approaches except perhaps Knowledge Centered Support. I particularly like the No Assholes Rule: we tolerate way too much anti-social behaviour in IT.

I.e. Lets extend the impact of DevOps all the way through the service lifecycle. Let's really transform ITSM with DevOpsRun.

Note: I'm sure I'll keep refining this post. I'll try to remember to mark the major revisions. So keep checking back. It's Agile writing: you have to deal with the ongoing change.

More from the IT Skeptic on DevOps