Devops design patterns

If you are a developer of a certain age (i.e. old like Dan and I) you would have lived through the "Gang of Four" Design Patterns era in the mid '90s. When the GoF book first came out in 1995 it had a spectacular impact on the development community - it was up there with "The Internet for Dummies" in terms of the best read tech book. You couldn't move with out hitting a design pattern. They were everywhere. They were in requirement specs, architecture specs, job specs and even in people's code.

It was usually an ominous sign when you saw them in code because you could be pretty sure that you would find all the patterns, everywhere - a clear indication of buzzword bingo being played by a development team that wanted to make sure their CV was chock full of the latest Abstract Builders, Observers, Memento's, Flyweights and everyone's favourite: the Singleton. (Never has so much damage been done by one pattern as the Singleton!)

As with all meme's the design pattern concept has started to drop out of favour in recent years, which is a shame as Patterns are actually a very powerful metaphor for describing systems.

The originator of the design pattern concept was Christopher Alexander. He was an architect who was interested in creating a pattern language that would help people to build houses and communities of any scale. Design patterns in the technology community have largely been restricted to developers and it is rare to find systematic use of patterns to describe other areas of engineering life. At the risk of getting shouted at by Doug, I have never, for example, heard of SysAdmin Design Patterns. Why is that?

I was therefore interested when I found a post this morning on a devops blog about design patterns for operations teams. The blog is really little more than a teaser but it got me wondering whether having a "pattern language" to describe a whole range of engineering tasks, not just development code structures might be useful. Would it be useful to have patterns describing various deployment options or ways/means to monitor systems? Would a set of operational pattern languages help us in describing the tradeoffs between various failure handling scenarios? Would it help us to cross boundaries between development, platform and ops? Would being able to express things as a pattern help people from different teams to think about what they really need to get done and why?

Thoughts?