In this episode I want to talk about the team structures discussed on https://web.devopstopologies.com/ - with a focus this week on the anti-types. The devopstopologies.com website is based on the work by Matthew Skelton & Manuel Pais. I introduced Matthew and Manual as authors of the Team Topologies book in the last episode. The work is a pre-cursor to the Team Topologies book - and work that I feel stands on its own two feet - with a specific look into how teams should work together to gain benefits from DevOps.
Or listen at:
Published: Wed, 25 May 2022 15:59:22 GMT
Links
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
In this week's episode, I want to look at the DevOps Team Topologies.
This episode inspired by, and heavily references, the DevOpsTopologies.com website based on the work by Matthew Skelton and Manuel Pais. I introduced Matthew and Manuel as authors of the "Team Topologies" book in the last episode.
The work on the DevOpsTopologies.com website is a precursor to the Team Topologies book, and work that I feel stands on its own two feet - with a specific look into how teams should be working together to gain benefits from DevOps.
This episode, I will take a look at the "Anti-Types" that they define; commonly seen bad team organisations that help us understand of what NOT to do. And in next week's episode, I'll look at examples of some topologies that they believe can work.
But let's start with a bit of a recap of what DevOps is. As I've said before, I really like the Microsoft definition of DevOps:
"A compound of development (Dev) and operations (Ops), DevOps is the union of people, process, and technology to continually provide value to customers."
It's a marriage of traditionally opposing forces - innovation and change out of Dev, while stability and limiting change out of Ops.
The DevOps Topologies website provides examples of how those two teams should and should not interact.
The DevOps Topologies website provides this in the introduction:
"The primary goal of any DevOps effort 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."
It later goes on to say:
"Remember: There is no "right" team topology, but several "bad" topologies for any one organisation."
And to help us, the site provides a list of topologies described as "Anti-Types" and also a list of topologies that can be shown to work. For the rest of this episode, we will focus on the Anti-Types.
Anti-Types, or bad patterns, in team structure can appear because of poor understanding of what DevOps is and what it is you're trying to achieve. There is considerable weight behind the benefit of DevOps. I myself have recently devoted seven episodes to the State of DevOps report, which I feel provides an excellent "why" you'd want to investigate DevOps. Unfortunately, it can be easy to get carried away and make changes without the knowledge of how to do it well.
I've certainly seen a number of executives who misunderstood DevOps, resulting in real world examples of some of the Anti-Types described on the site.
The website currently defines eight Anti-Types:
- Dev and Ops silos
- Dev and DBA silos
- DevOps team silo
- No Ops needed
- Embedded Ops
- DevOps as a tools team
- Rebranded sysadmin
- and fake SRE
Let's take a look at each one of those in turn.
Dev and ops silos. This is arguably our starting point in most legacy operations. They are two silo teams. They largely do not interact unless the Dev team want the Ops team to deploy changes, or the Ops team want the Dev team to fix something.
This is a structure we want to improve using DevOps in the first place.
The Dev and DBA silos is very similar to that Dev and Ops silo as a starting point - and something we look to DevOps to resolve. We have our Dev team and our Database Administrators (the DHAs) acting as siloed teams. And this can occur quite often in large organisations where there's a lot of data. Due to the amount, or importance, of the data we use a dedicated DBA team to manage and maintain that data.
This often leads to the DBAs becoming gatekeepers to any change made by Dev that would affect the data - which is likely to be pretty much everything.
Again, we have interaction problems here. The Dev team want the DBA team to make changes for them. The DBA team want the Dev team to focus on data problems. It produces that common "them" and "us" with the teams clashing on how best to get the work done.
The DevOps team siloed topology. Now, this is an attempt to resolve the problem of having two disparate silos by creating a third.
Our new team, DevOps, is its own team that lives between Dev and Ops - the assumption being that putting this team in the middle will improve the interactions.
Rather, it just adds more interaction problems - a third entity with its own agenda and biases.
Devops Topologies does suggest that this approach could be used as a temporary measure, say, for example, limited to less than 18 months and use as an enabling function. Now I'd agree if they worked with the Dev and Ops team to bring them closer and effectively work to make themselves superfluous, then potentially there could be value in that.
However, I suggest there's danger here. There's a danger that that team gets stuck in that topology structure and they become permanent. Thus, consider this approach with care.
The No Ops needed topology. There is an assumption from the Dev team that they simply do not need the Ops team and their expertise.
This can often happen if the Dev team move to using cloud providers as a way of bypassing Ops. I've certainly seen productivity jumps from the Dev team when they're able to quickly utilise the cloud offerings, cloud offerings that are available at the end of the credit card, especially if the Ops teams struggle to keep pace with those cloud offerings. And this can lead to the view that the ops team simply isn't needed.
However, many of those hard learnt practises and principles of the Ops team are generally lost doing this. For example, many security issues have occurred with that sudden adoption of cloud, but not having taken into account those hard one Ops expertise where potentially they could have been asking the hard "what-if" questions.
It often results in Dev having to relearn many of the basic Ops mistakes.
The Embedded Ops team topology. Similar to the No Ops needed, Ops functions are handled by the Dev team - but in this version there is no Ops team in the organisation at all - the responsibility is simply part of the dev team's duties.
Now this can seem like the desired outcome of DevOps - and indeed it might be if the relevant importance and time is put into those Ops responsibilities - however, the danger comes when those Ops responsibilities are overlooked or ignored in favour of overfocus on the Dev responsibilities.
If enough focus isn't put into the maintainability, the security and the reliability of the product, there is a real danger of the system continually failing.
Just because we've merged the teams doesn't mean those responsibilities have gone away.
The DevOps as a tools team topology. In this mode, a Dev team works on providing tools for the other Dev teams to make their operational process better. For example, working on improving tools for Continuous Integration, Automated Testing, etc.
And why this will provide a benefit, it will be limited if the Ops team are not engaged.
The DevOps as a tools team encourages a better set of tools for the Dev team, but does nothing to solve the interaction problems between the Dev and Ops silos.
The Rebranded sysadmin topology. This is simply the renaming, or potentially hiring, of somebody in the Ops team as "DevOps".
I've always considered a job title with the term DevOps as being a red flag. This is often when you'll find that an organisation is effectively putting the DevOps responsibility onto an individual rather than the organisation. Devops needs collaboration across Dev and Ops - and that takes an organisational change.
Simply employing somebody and changing their name, that job title, does not implement DevOps.
You need to fix those broken interactions and encourage collaboration between the two silos.
The fake SRE topology. Now, I've talked about Site Reliability Engineering practises that have come out of Google previously. This type refers to simply renaming your Ops to be called SRE, or Site Reliability Engineering team.
As with the Rebranded sysadmin, the change of name may sound like a tick in the box for you to claim that you're doing DevOps - but it isn't changing the communication or interaction behaviours of your organisation. It will produce no benefit.
In this episode, I've started to introduce the team structures as recommended by DevOpsTopology.com.
I focussed on the Anti-Types in this episode - the Anti-Types of:
- Dev and Ops silos
- Dev and DBA silos
- DevOps team silo
- No Ops needed
- Embedded Ops
- DevOps as a tools team
- Rebranded sysadmin
- and fake SRE
Next week, I'll take you through the structures that the site recommends.
Thank you for taking the time to listen to this episode and I look forward to speaking to you again next week.