The Business Case for DevOps

[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:

  1. Using appropriate terminology
  2. Recognising the huge technology shift which has occurred over the last few years
  3. Emphasising the importance of operability in our software systems

Continue reading The Business Case for DevOps

Three Org Changes to Encourage DevOps

[#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)

Continue reading Three Org Changes to Encourage DevOps

Who Owns My Operability?

Includes recommended reading for software operability: SoftwareOperability.com

Matthew Skelton (@matthewskelton)'s avatarSoftware Operability

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?

Who Owns My Operability?

Update: the site now shows selected recommended reading on each page load.

(With a nod to whoownsmyavailability.com)

View original post

Tutorial – How to build your own website using HTML and WordPress

I have published a set of workshop notes on Github called Build Your Own Website – A Beginner’s Guide, covering the basics of HTML and WordPress-driven websites. I gave the workshop at a recent Engineering Day event at thetrainline.com, where the audience was largely non-engineers from marketing/finance/HR etc., and it was interesting and useful to return to the first principles of HTML in ways accessible to novices.

Continue reading Tutorial – How to build your own website using HTML and WordPress

Cloud Deployments – Alex Papadimoulis at QConLondon 2013

Alex Papadimoulis (@apapadimoulis) of Inedo (and TheDailyWTF) gave a really useful talk on deployments for cloud-based software systems at QConLondon 2013 recently [slides, PDF, 1.6MB].

He stressed the importance of finding the appropriate deployment (distribution + delivery) model for each application, and to keep deployments as simple as possible. In fact, we can follow the best practices from Continuous Integration and apply them to deployment.

Continue reading Cloud Deployments – Alex Papadimoulis at QConLondon 2013