I chaired the May 2013 DevOps Summit in London, whose theme was Enabling DevOps. I gave a talk on The Business Case for DevOps (blog post), and the slides are on SlideShare:
(Thanks to all those credited on the final slide, and to Unicom for organising the event)
[At the Unicom DevOps Summit on 23rd May 2013 in London I gave a talk on The Business Case for DevOps; here is a summary of the talk, along with the slides. Update: now with video too.]
With an increasing number of organisations turning to DevOps to try to improve their software systems, it is becoming necessary to provide the business case for introducing DevOps, especially in organisations which perceive their main focus to be something other than software systems.
For me, building the business case for DevOps has three strands:
Here are some criteria which should be useful when trying to cut through the tangled mess of “DevOps” job titles in order to work out if a prospective role will actually lead to working within a DevOps culture, or whether you’ll be stuck in an old-school IT silo with a fancy “DevOps” name tag and the same crappy us-and-them mentality.
Continue reading Questions to ask when applying for DevOps jobs
[#encouragedevops] In the talks and break-out sessions at DevOpsDays London, in conversations at London Continuous Delivery meetup group, in numerous blog posts and articles talking about introducing a DevOps culture (e.g. http://devopsnet.com/, http://www.stephen-smith.co.uk/), and based on my own experience of organisations I have worked within, it is clear there are three key practical steps which an organisation can take in order to encourage a DevOps culture of collaborative, cross-functional, product-focused working which leads to more effective delivery of software-based services.
(I’ll be blogging about each one of these steps over the next few weeks with the tag #encouragedevops)
Includes recommended reading for software operability: SoftwareOperability.com
Operability is not something which can be ‘bolted on’ or retrofitted to software after it goes live; we need to design and build our software with operability as a first-class concern. You don’t build a bridge, then try to add load-bearing capabilities at the end of the project — but most software projects try to do exactly that, typically with costly results.
Ultimately, the product owner should be responsible for ensuring that operational requirements are prioritized alongside end-user features. If you are responsible for the software product or service, there is only one answer to the question
Who Owns My Operability?
Update: the site now shows selected recommended reading on each page load.
(With a nod to whoownsmyavailability.com)
Matthew Skelton 