Which DevOps topology is right for me?

Why should I read this?

You're working in an organisation that aims to explore the benefits of working according to DevOps principles. You've heard terms like "platform team" and "SRE" and you have an idea what "you build, you run it" means. These terms, however, have made your exploration into DevOps more complicated and now you even have to choose how to organise your team(s). This blog provides an overview of the three most applied DevOps topologies and which conditions make a specific topology a good fit for your company.

As a reference, Matthew Skelton's "DevOps topologies" (http://web.devopstopologies.com/) page gives a nice overview of all kinds of organisational topologies. These topologies have been implemented by companies around the world in their quest for agility and operational excellence through DevOps. Although many topologies have been documented, I believe that they are all variants of these three topologies:

1. All teams are product teams. Each team does everything that is needed to run their software including the use of any infrastructure components, usually cloud-based PaaS.

2. Internal platform team(s) and Product team(s). Product-teams make use of the infrastructure/platform-services provided by internal platform-team(s). Services provided by the platform-team(s) can range from infrastructure and "run" services such as monitoring to Continuous Integration tools and dashboarding tools.

3. Internal Platform team(s), Product team(s) and Site Reliability Engineering team(s) (SRE). This topology is based on Google's best practices around running software. Product teams can gain the SRE teams' support in running their software if they need it and if their software adheres to standards defined by SRE teams. SRE teams can also share on-call responsibility with product teams. The platform-team(s) provide infrastructure/platform-services.

The DevOps topology that will have the best fit within your organisation is dependent on your current organisational hierarchy, scale, regulatory requirements and people's skills. It is also important to recognise that any chosen topology has its pitfalls, which need to be dealt with.


All teams are product teams

This topology is probably the most common; every team adheres to the "you build it, you run it" mantra and uses (and therefore maintains) infrastructure and tools of their own choice. That means that teams need a lot of expertise to be able to run their services/applications.

Example of a topology where all teams are product teams.

Possible gains:

  • Teams enjoy full autonomy in building and running their products
  • Teams don't have to share any infrastructure or tools.
  • No shared responsibility for running software.
  • Responsibility is easy to govern.
  • Product teams can grow towards automation goals at their own tempo

Possible pitfalls:

  • Potential inefficiencies; teams can and will build their own solutions for each problem. Re-use of tools and infrastructure components between teams limited.
  • Each autonomous team needs their own infrastructure-, security- and compliance expert
  • Each team needs to spend time on maintaining their infrastructure, and tools
  • Each team needs to create solutions to comply with any regulatory requirements

This topology makes a good fit for your organisation if:

  • Your company makes use of cloud-services (which can be automated) for the infrastructure.
  • Your company/department consists of 1-5 teams or can provide each team with all the expertise that is needed
  • Regulatory needs such as audit logging do not have to be standardised.
  • There is no economic benefit in creating a separate team to provide infrastructure or tools to product teams.
  • Your focus is speed, and you don't care much for standardisation. Focussing on speed is a good idea when you want to explore and learn what the benefits of DevOps are without having to reorganise teams within your company,
  • You don't have a legacy IT-ops department/team because you're the next unicorn startup.

Internal platform-team(s) and Product teams

Once your company grows past a certain threshold, it makes sense to have one or more platform teams provide generic platform services (such as infrastructure and/or CI/CD tools). Platform teams offer all their services in the form of self-service APIs to the various product teams. Often, platform teams themselves make use of cloud infrastructure services and combine those to offer more value. For example, a platform team can provide a container platform as a service with connectivity and access management already set-up to meet company requirements.

Example of a platform team/product team topology.

Possible gains:

  • Efficient re-use of platform services between product teams.
  • Re-use of infrastructure components provides standardisation as a side-effect
  • Product teams are unburdened when it comes to maintaining infrastructure and tools.
  • The separation of concerns between platform- and product teams means that product teams can focus on delivering value to customers. Platform teams can thus focus on enabling product teams in running their software.
  • Regulatory requirements such as audit logging can easily be met by using services provided by the platform-teams.

Possible pitfalls:

  • The Product Owner of the platform-teams needs to both have a vision on the future of the platform and manage requirements of all the product teams
  • Product teams need to be coached to give regular feedback to the platform team instead of creating their own tools whenever the platform cannot provide those tools.
  • Platform teams need to be able to collect feedback from product teams

This topology makes a good fit for your organisation if:

  • It is cheaper to run a platform team that builds generic infrastructure/services instead of having each team doing it separately. This threshold depends on your organisational context.
  • Regulatory needs such as audit logging have to be standardised.
  • You cannot provide each product team with their own infrastructure-, security- and compliance expert
  • You want to standardise your infrastructure and tools
  • You have outsourced your infrastructure and/or tools
  • You have an existing IT-ops department, and you are running a (highly) regulated business such as banking or government.

Internal Platform team(s), Product team(s) and Site Reliability Engineering team(s) (SRE),

The SRE team is "what happens when a software engineer is tasked with what used to be called operations." according to Ben Traynor, who founded the first SRE team within Google. One could argue that an SRE team is like a classic IT-operations team and does not match with DevOps principles such as end-to-end responsibility. The difference of the SRE-model lies in the shared responsibility model between product teams and the SRE-teams. For further reference material on the SRE model; Google's book on the topic is available online for free at https://landing.google.com/sre/book.html.

Platform teams provide all their services in the form of self-service APIs to the various product teams.

Example of an SRE/platform team/product team topology.

Possible gains:

  • Product teams require a lot less Ops expertise than the previously mentioned topologies. This expertise can be grouped in the SRE teams.
  • SRE team actively coach product teams in improving the quality of their software and in running the software
  • SRE teams actively look for opportunities to automate and improve the delivery and running of software.
  • Product teams that are responsible for business-critical applications feel safer in running their software because of the SRE teams' support

Possible pitfalls:

  • The difference between SRE vs classic IT-ops teams is nuanced. Misunderstanding this nuance will lead to more organisational complexity.
  • SRE team members require software engineering and coaching skills

This topology makes a good fit for your organisation if:

  • There is a limited number of IT-ops specialists
  • The existing IT-ops specialists have extensive coaching skills
  • There is a different requirement in Ops expertise between product teams. For example, only product teams that build business-critical software require the support of an SRE team, while other teams run their software on their own.
  • Your company has more than five product teams
  • You have an existing IT-ops organisation that separates infrastructure-ops teams from application-ops teams.
  • You are in a (highly) regulated business such as banking or government
  • You have outsourced your infrastructure and/or tools
  • You want to ensure that product-teams that deliver business-critical software adhere to a defined software quality threshold


I've read your blog. What now?

Whether a DevOps topology will work for you is highly dependent on your current organisational context. The topologies mentioned in this blog are not mutually exclusive so consider mixing and matching them if you decide to start a journey towards DevOps. In that journey, remember that in the beginning, maximizing your learning experience is vital. Only by learning from your experience will you know what topology fits best at a certain point of your journey.

One thing is for sure: copying another company and it's DevOps success stories will not work, but let yourself be inspired.

Further reading on this topic:

Scrum Master Q&A Fulltime Scrum Master Role

In my Scrum Master training courses, I get a lot of questions about the workload of a Scrum Master. One question I hear frequently is this:

Is the Scrum Master role a full-time job?

The answer is yes! In my opinion, the Scrum Master role is a full-time job. As a Scrum Master, you support the Development Team, the Product Owner, and the organization. You help others understand and master Scrum, and to achieve their potential at different levels.

Scrum Master activities can include any of the following:

  • facilitating Scrum events
  • working on the Scrum process
  • helping teams to become better
  • supporting empiricism
  • promoting inspecting and adapting
  • facilitating teamwork
  • removing and solving impediments,
  • assisting the Development Team to become self-organizing
  • help the Scrum Team to live by the Scrum values,
  • and observing team dynamics.

You will have your Scrum Master radar on at all time. You watch the things that are not being said, and you sense the things that are not on the surface. You can’t do that if you’re not there.

With this in mind, here are some answers to some other frequently asked questions.

Can you combine your Development Team role with the Scrum Master role?

No, you will lose focus and will not be able to excel in either role.

Imagine yourself as a developer, you are in the zone, minding your own business and delivering value. Then, suddenly, another developer has an impediment - the deployment to the acceptance environment did not go well because this environment is down. Your team member has tried everything to get it back up again, but it doesn’t seem to help. He asks you if you could help him. If you do not help your team member right away, he is not able to continue. So you leave your current coding and help your team member. When you finally have solved the impediment, you return to your work and continue. You have to connect with the subject again, since you were distracted for a while. Your focus is lost.

What if your company requires you to combine your Development Team role with the Scrum Master role?

If your company requires you to combine your team and Scrum Master role, make clear agreements with the Development Team about how to interact in the event of an impediment. Make it explicit agreements which role has priority.

Can we rotate Scrum Mastership amongst Development Team members?

No, you can’t rotate Scrum Mastership amongst Development Team members because not everyone on the team is a capable Scrum Master. The Scrum Master role requires certain capabilities, skills, and behaviors. Some of these Scrum Master characteristics can be learned, coaching, listening, facilitating, mentoring, observing, intervening but others are innate, such as servant leadership and being pro-active. If you have a role on the Development Team and you are also the Scrum Master, you will lose focus.

What if your company requires you to rotate Scrum Mastership?

If your company requires you to rotate Scrum Mastership, make sure that you are the Scrum Master for more than one sprint (e.g. three sprints) so you can start developing SM skills before you switch.

Can you combine the Product Owner and Scrum Master role?

No, it’s not a good idea to combine the Product Owner and Scrum Master roles because it creates a conflict of interest.

As a Product Owner, you’re busy with your stakeholders, changes in the market, exploring what delivers the most business value and helping the Development Team understand the requirements you have. As a Scrum Master, your focus is on supporting the Development Team, the Product Owner, and the organization. So, the people you contact the most are different and have different approaches.


As a Product owner, you want to deliver business value at the right pace. You can challenge the Development Team to take up a lot of items in the Sprint Backlog. As a Scrum Master, you protect the Development Team from overly demanding Product Owners (believe me, they exist). You do this by helping them asking challenging questions, like: Do we really believe we can finish this? Do we understand what is being asked? It is difficult to approach the team while wearing two hats. You will lose focus.


What if your company requires you to combine the Product Owner role and the Scrum Master role?

If your company requires you to combine the Product Owner role and Scrum Master role, make sure you have a clear distinction between them.  It’s also important to clarify which position you’re coming from with those with who you interact.


Can you work as a Scrum Master at a different location from your team or the Product Owner?

No, it’s not possible to function effectively in the role of Scrum Master if you are not onsite with the Development Team. You need to be present to sense the things unsaid or feel the vibe in the room. If the Scrum Master and Development Team work at the same location but the Product Owner and stakeholders are at another location, the necessary contact and collaboration are lost.


What if logistics require the Scrum Master and Development Team to work in separate locations from the Product Owner and stakeholders?

If you can't work in the same onsite location, interact with each other as often as possible. Make an all-day video connection if possible. Ask Development Team members who work on different locations to work together in the same location for a period of at least one month. The team members will get to know each other a bit, this will help to build trust in the team.

If you’re still stuck in a situation that prevents your Scrum Team from performing at its best, please contact us: info@scrumboosters.com


Scrum Master Scan

There was a point you were a Scrum Master for the first time. Maybe you read about Scrum and decided the Scrum Master role would be perfect for you, or maybe your company chose to work with Scrum and pointed you out as the Scrum Master. Either way, there was a day one as a Scrum Master, you started learning about Scrum, about people, about organizations and a lot more.
As Scrum Masters, we never stop learning. I learn every day, I experiment, I broaden, deepen and share my knowledge, and I challenge myself to keep learning. To find new suitable ways to facilitate, new models to use when coaching people, games to bring things across, etc.
I fail, and I learn, I succeed, and I learn. I do assessments, and I fail; I do assessments, and I pass. But in all these activities I learn. But in which areas can I learn most?
As a part of the learning process of a Scrum Master, we developed a Scrum Master Scan.
To see at which points you have learned and at what point you have room to learn more. The scan is an online survey with almost 90 questions. The result is a graphical display with a score on three areas, attitude & behavior, craftsmanship, and results. Are you a Scrum Master and want to use the Scrum Master Scan, please contact eroos@xebia.com 

TDD in React

It’s nearly impossible to keep up with the pace JavaScript frameworks pop up nowadays and I believe it’s good to have some focus. For me, this means the big three as defined in this post and more specifically doing basic TDD with React. Read more →

Creating a cascading resource import structure for Robot Framework: Pt. 1/3 - Introduction to resource sharing

This is the second post in a series that will address some of the problems and questions surrounding the usage of the Robot Framework (RF), that I encounter frequently in the field. Click here to take a look at the first of these posts. As I have stated in the introduction to that post, I will sometimes use these treatments also as an opportunity to make small digressions, so as to shed some light on the internals of the RF.

This post will show you how to implement a simple and yet very efficient mechanism for resource sharing within the framework. Actually, I will use three separate posts to do so. The post you're reading now, will be the first of these.

Robot Framework provides an out-of-the-box mechanism for sharing, i.e. re-using, various types of resources. However, depending on the size and complexity of your test automation project, this mechanism can sometimes entail quite some maintenance work in and of itself. In three posts I will describe a setup for sharing, that will virtually eliminate the involved maintenance effort. Additionally, this setup will provide you with a few, very fundamental, abstraction layers that you will have to apply in any given test project.

So, let's first have a look at the main types of RF resources and at how these resources can be reused within the RF (first post). Then we will describe the problem surrounding this native mechanism (second post). Finally, we'll be providing a solution to this problem (third and final post).

Read more →

SPACEMAP - organising a motivational environment

Introducing the SPACEMAP! A 'map' to gain insight into motivational problems within an organization/department, so that coaches and managers no longer have to talk about vague motivation problems, but instead tackling the lack of autonomy within the teams.

The map consists of generic 'work factors' that are required to create a motivational environment.

SPACEMAP - organising a motivational environment

the SPACEMAP was developed by Xebia coaches

Read more →

Combining Domain Driven Design and Behaviour Driven Development

In my previous post, I discussed why we want to write software with empathy in mind; software that is understandable for peers. For us to create software with empathy in mind, we need to create a shared understanding of the users' needs; the needs we are trying to satisfy with our software. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help us achieve this. By using Feature Mapping (a technique from BDD) and improving this with Event Storming (a technique from DDD), we can create executable specifications and a model for our business needs at the same time. This way, we can write software and tests that match the shared understanding the business has, which enables us to ship more value faster.

Read more →

Using Specification by Example / BDD for your refinements

When I'm joining new teams at clients it often becomes clear that the added value of refinements is not always seen. Team members complain that hours are wasted. The refinement sessions shouldn't be long draining meetings with endless discussions. Refinements should instead provide a clear added value in the form of requirements that the whole team can work with to deliver added value. How do you shape your refinements in a way that they add value? Read on to see how BDD / Specification by Example can help you!

Read more →

Share This