I the early part of the ‘unpanel’ session at last night’s post Cloud Expo London CloudCamp there was a good deal of debate about DevOps and what it means. Some people talked about new skill mixes, others talked about tools. These are I think simply artefacts. The more fundamental change is about design. At the risk of repeating myself, if something is designed for cloud then it is designed for operations, so DevOps is an expression of industrial design maturity.

At the same event Pat Kerpan from CohesiveFT challenged conventional wisdom by saying ‘go for production first’ (rather than go for the low hanging fruit of dev and test). I think his point was that unless you choose a path that can be seen to work in production, then you might never actually get there. Perhaps the way to build a bridge between these two seemingly opposite approaches is by the use of continuous deployment, which has much in common with ‘DevOps’ .

So here’s what I think is going on:

1. The first stage of (industrial) design maturity is design for purpose – a cottage industry. The people who make software (Dev) aren’t the ones keeping it alive in production (Ops) and there are likely many inefficiencies and resultant costs. This (unfortunately) is how much enterprise IT works[1].
2. The second stage of design maturity is design for manufacture. This optimises the process of making software, so we might see practices like continuous integration, but doesn’t concern itself with the operational environment. This is how most packaged software is made, as the people cutting the code aren’t the ones holding the costs of looking after it in production (hence the myth of software support).
3. The third (and final) stage is design for operations, which optimises for end-end cost of ownership for the software and its care and feeding in the production environment. Anybody running a software as a service (SaaS) platform must (at least aspire) to achieving this level as they will be at a competitive disadvantage if there are inefficiencies between Dev and Ops. Of course most enterprises that do in house software should also be trying to get here, which is why DevOps shouldn’t just be for lean startups.

I’ll take all the debate about skills and tools as evidence that we (as a community in general) don’t think enough about design and design maturity. This is perhaps where PaaS comes into play – people that don’t think about design very much can use something with design baked in by those who do.

Notes

[1] I caught a few references to ‘enterprise grade’ at CloudCamp last night, used in a way that implies higher quality. This is of course at odds with Don Box – So Long, 2006 ‘The blogosphere embraced the term “enterprisey” to describe the lack of quality that previously had no name’.