Author Archives: Matthew Skelton (@matthewskelton)

Download a free chapter from Team Guide to Software Operability

Posted on by

We have published the first chapter of our Team Guide to Software Operability as a free chapter on Leanpub – download it now from the book website. In this first chapter we explain how to use what we call Run Book collaboration to increase operability and prevent operational issues.

single-software-operability-contents-image

Future chapters will cover additional material including:

  • Deployment Verification Tests and Endpoint Healthchecks for rapid feedback on environments
  • Run operational checks within a deployment pipeline to gain rapid feedback and increased collaboration
  • Modern log aggregation and metrics for deep operational and product feature insights
  • Information radiators and dashboards to drive effective behaviour and good psychological responses

Download the free sample chapter of Team Guide to Software Operability now.

— Matthew Skelton (@matthewpskelton) & Rob Thatcher (@robtthatcher)

Team Guide to Software Operability – book coming November 2016

Posted on by

Inspired by our consulting work over the last 3 years and events like Operability.io conference, we (Matthew Skelton and Rob Thatcher) have been working on our book on software operability. We expect to publish the book – eBook and paperback – in November 2016. Sign up for updates here: https://skeltonthatcher.com/publications/

software-operability-cover-crop

We have taken a ‘team-first’ focus for the book – with techniques and practices that work for teams rather than just individuals – because  in our experience many organisations struggle with the team aspects. This will be the first of a series of books on aspects of software systems with planned titles including: Software Testability, Metrics for Business Decisions, and Build & Release Engineering.

Sign up for news (and 15% discount) here: https://skeltonthatcher.com/publications/

Early version of ‘Software Operability’ book coming soon

Posted on by

We’re pleased to announce that an early version of our book Software Operability: how to make software work well in Production will be published soon via our LeanPub site at operabilitybook.com

We are busy adding significant new chapters and practical examples based on our recent work with organisations in the UK and Germany. Oh, and we have a nice new cover for the book too. Follow us on Twitter for updates: @Operability.

Matthew Skelton & Rob Thatcher, authors, ‘Software Operability’

Cover of Software Operability book

Slides – Software Operability and Run Book Collaboration

Posted on by

I gave a talk at DevOps Summit Amsterdam on 14 November 2013 on Software Operability and Run Book Collaboration; here are the slides.

Thanks to Unicom Seminars for organising the event, and to all the attendees for some great questions and conversations over coffee.

Operability can Improve if Developers Write a Draft Run Book

Posted on by

The run book (or system operation manual) is traditionally written by the IT operations (Ops) team after software development is considered complete. However, this typically leads to operability problems being discovered with the software, operational concerns having been ignored, forgotten, or not fully addressed by the development (Dev) team. If the software development team writes a draft run book or draft operation manual, many of the operational problems typically found during pre-live system readiness testing can be caught and corrected much earlier. Because the development team needs to collaborate with the operations team in order to define and complete the various draft run book details, the operations team also gains early insight into the new software. Channels of communication, trust, and collaboration are established between the traditionally siloed Dev and Ops teams, which can help to establish and strengthen a DevOps approach to building and running software systems.

Clay tablet, Museum of Athens, Greece

Do not carve the run book in stone; focus instead on the collaboration needed to write the draft.

I will be talking about run book collaboration at DevOps Summit in Amsterdam on 15 November 2013.

Continue reading →

Patterns for Performance and Operability – Summary

Posted on by

Patterns for Performance and Operability The book Patterns for Performance and Operability by Ford et al is one of the few publications which addresses directly the operability of business software (which is partly why I am writing Software Operability:  A Guide for Software Teams). Patterns for Performance and Operability (‘PPO’) is an excellent volume, containing many valuable insights into the ways we can improve the operability of software systems; this blog post explores a few of the key themes and ideas found in the book.

 

Continue reading →

Speaking about Run Book Collaboration – DevOps Summit, Amsterdam

Posted on by

I will be speaking about Run Book Collaboration at the DevOps Summit in Amsterdam in November 2013:

Practical steps for larger organisations to try in order to improve Dev and Ops collaboration, especially via the System Operation Manual (or “Run Book”).

DevOps Summit Amsterdam - logo

Early Bird ticket prices for the event end on October 14th – book with Unicom to secure your place.

Software Operability article in DevOpsFriday

Posted on by

DevOps star Benjamin Wooton (@benjaminwooton) has published the latest installment of his DevOpsFriday newsletter  – Insight from DevOps Thought Leaders – at http://devopsfriday.com/devops120413.pdf, including articles by David Mytton of @serverdensity, Matt Watson of @Stackify, Sandy Walsh (@TheSandyWalsh) and the RethinkDB team (@rethinkdb).

I contributed the following article on software operability and why it is so important for today’s software systems; it takes the form of an interview, with Benjamin Wooton asking the questions.

Continue reading →

Let’s Talk About Operational Features, not Non-Functional Requirements

Posted on by

Using the term ‘non-functional requirements’ to describe aspects of software systems which are invisible to the end-user but essential for effective service operation is counter-productive; we should instead use ‘operational requirements’ or ‘operational features’, and schedule these for delivery alongside end-user features.

Update: the Experience DevOps workshop series now has sessions on Software Operability – find out more at http://experiencedevops.org/

Operational-Features

Continue reading →

Who Owns My Operability?

Posted on by

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)