What Team Structure is Right for DevOps to Flourish?

Posted on by Matthew Skelton (@matthewskelton)

Update (2022): my company Conflux now offers consulting and training around DevOps topologies and related practices like Team Topologies.

Update (2019): I have co-authored a book – Team Topologies – that adds brand new material to these (original) DevOps Topologies patterns. In the book we cover dynamic organization evolution, team interaction patterns, the strategic use of Conway’s Law, monolith decomposition, and many more topics.

See teamtopologies.com and follow us on Twitter at @TeamTopologies for updates. The book is published by IT Revolution Press (Sept 2019).

Team Topologies: organizing business and technology teams for fast flow
Matthew Skelton and Manuel Pais
IT Revolution Press, Sept 2019

Update (2016): A new version of these DevOps team topologies is now here: devopstopologies.com

DevOpsTopologies-screenshot
Find more DevOps team topologies at devopstopologies.com

The new version has many new topologies that we’ve encountered in the wild and we’re taking pull requests on Github for additions and changes.

The primary goal of any DevOps setup within an organisation is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management; this means that different organisations might need different team structures in order for effective Dev and Ops collaboration to take place.

Butterflies in a Museum
Photo by James Emery: http://www.flickr.com/photos/emeryjl/3535989711/

So what team structure is right for DevOps to flourish? Clearly, there is no magic conformation or team topology which will suit every organisation. However, it is useful to characterise a small number of different models for team structures, some of which suit certain organisations better than others. By exploring the strengths and weaknesses of these team structures (or ‘topologies’), we can identify the team structure which might work best for DevOps practices in our own organisations, taking into account Conway’s Law.

Continue reading What Team Structure is Right for DevOps to Flourish?

Operability can Improve if Developers Write a Draft Run Book

Posted on by Matthew Skelton (@matthewskelton)

Matthew Skelton (@matthewskelton)'s avatarSoftware 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.

I…

View original post 1,295 more words

Leaving the Platform – Branching and Releasing for Independent Subsystems

Posted on by Matthew Skelton (@matthewskelton)

Matthew Skelton (@matthewskelton)'s avatar

For several years, much of the code for the systems at thetrainline.com has been versioned and deployed together as a single ‘platform’. Recently, we have begun to divide up the platform into smaller chunks, to enable us to deliver some parts more frequently and rapidly, leaving other parts to evolve more slowly (as needed). Moving from a single version number for all subsystems to multiple version numbers for independent subsystems has implications for how code is built and released; this blog post outlines some of the work we have done so far in this area.

My colleague Owain Perry and I recently presented on this topic at the London Continuous Delivery meetup group (http://londoncd.org.uk/) and the slides we showed relate to the details in this post:

View original post 1,214 more words

Roundup: Patterns for Performance and Operability

Posted on by Matthew Skelton (@matthewskelton)

Patterns for Performance and OperabilityI recently posted a review of Patterns for Performance and Operability by Ford et al on the SoftwareOperability website. I think that this book is exceptionally useful in its treatment of both performance and operability, and anyone who cares about how well software works in Production should buy and read a copy (there are paper and eBook editions).

Two other reviews might be useful too: my colleague Anant East (Head of Architecture and Infrastructure, thetrainline.com) wrote up a detailed review of Patterns for Performance and Operability on the tech blog at thetrainline.com, and I posted a short review on Amazon.

John Willis (@botchagalupe) on DevOps – “Culture, Culture, It’s Got To Be Culture”

Posted on by Matthew Skelton (@matthewskelton)

John Willis (@botchagalupe), one of the most respected and knowledgeable people in the DevOps movement, recently gave a talk at the Silicon Valley DevOps meetup group on DevOps Culture. John has been active in DevOps since the beginning (somewhere around 2008, and probably before) and has spoken to thousands of people about DevOps since then. Here’s what he had to say about culture in relation to DevOps:

If you don’t get the C, don’t bother with the A, the M, and the S.

This is a reference to Culture, Automation, Measurement, Sharing (CAMS) which has become the de facto shorthand moniker for DevOps. John is saying that Culture is the foundation of DevOps, and that Automation, Measurement, and Sharing are simply not worth doing if you do not understand that good Culture is essential for DevOps. He continues:

For three or fours years I have been going around saying “Culture, culture, it’s got to be culture”, and people look at you with stare-y eyes going “Shut the hell up” or “Yeah, we get it John. Our culture, absolutely, yeah. NOW CAN WE GET THAT CHEF RECIPE RUN?”. People think [culture] is a ‘kittens and puppy dogs’ thing which no-one really wants to deal with because it’s HARD.

He then goes on to characterise several different approaches to DevOps culture: organisations which try to IMPOSE culture, command-and-control style (doomed to failure); organisations which believe that culture is IMPOSSIBLE to change (also a failure); and organisations (the successful ones) which try to WORK WITH the existing culture and shape it gradually.

(Start from 09’00” in to hear the quotations above)