Operability

The Business Case for DevOps

Posted on May 24, 2013June 14, 2013 by Matthew Skelton (@matthewskelton)

[At the Unicom DevOps Summit on 23^rd 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:

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

Continue reading The Business Case for DevOps

Three Org Changes to Encourage DevOps

Posted on April 25, 2013April 25, 2013 by Matthew Skelton (@matthewskelton)

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

Posted on April 5, 2013April 24, 2013 by Matthew Skelton (@matthewskelton)

Includes recommended reading for software operability: SoftwareOperability.com

Software 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?

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

(With a nod to whoownsmyavailability.com)

View original post

How build & deployment shapes software architecture – WebPerfDays 2012

Posted on October 8, 2012November 12, 2017 by Matthew Skelton

It was a privilege to be part of the first WebPerfDays EU in London on 5th October 2012. Together with the folks from CCPGames, I facilitated a session on Continuous Delivery, opening the discussion with an overview of how build & deployment shapes software architecture at thetrainline.com:

The Continuous Delivery session prompted some excellent discussions around CD; there seems to be interest in setting up a London-based meetup, which I agreed to help coordinate.

Kudos to Steve Thair (@TheOpsMgr) and team for organizing such an excellent event.

Talk: How build and deployment should shape software architectures – IASA Ignite talks

Posted on September 11, 2012November 12, 2017 by Matthew Skelton

I gave an ignite talk* at IASA UK’s second ignite series, slightly cryptically entitled “Architecting the Impossible“. Having seen just how strongly build and deployment concerns can shape the software that we put into production, I spoke on How build and deployment should shape software architectures, ending with the slightly (and deliberately) controversial point that: