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’
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.
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.
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.
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”).
Early Bird ticket prices for the event end on October 14th – book with Unicom to secure your place.
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.
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)
Software Operability 