Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News How External IT Providers Can Adopt DevOps Practices

How External IT Providers Can Adopt DevOps Practices

This item in japanese

IT suppliers can follow the "you build it, you run it" mantra by working in small batches, using an experimental approach to product development, and validating small product increments in production. According to Konstantin Diener, the supplier has to find out what his client’s goal is, and it has to become the supplier’s goal as well to work in a collaborative way.

Konstantin Diener, CTO at cosee, spoke about how external IT providers can adopt DevOps practices at DevOpsCon Berlin 2021.

The main challenge when companies are working with an external IT supplier is that it is a game of three instead of a game of two, as Diener showed with an example:

A successful engine construction company wants to build a new digital product. This product shall help the company’s customers to monitor their machines. As an outage costs them a big amount of money, they want to be informed as quickly as possible when one of their machines breaks. It would be even better for them, to be alerted before something breaks (aka predictive maintenance).

Let’s assume that the engine construction company doesn’t employ any software engineers. Now it’s a game of three: supplier, client, customers. The monitoring product will be developed by the supplier. At some point in the future it will be handed over to one of the client’s teams and will be operated by that team.

Even if a product is developed by a supplier, it will be most likely operated by the client in the future, Diener said. Some of them will want to take it over very soon. Others will wait years to hire their own team for operating and enhancing their product, he mentioned.

Diener stated that it is possible for an IT supplier to follow the "you build it, you run it" mantra:

The key is to overcome waterfall thinking. A modern supplier will work in small batches and will use an experimental approach to product development. The supplier’s product development team will create hypotheses and valid them with small product increments, ideally in production.

According to my experience, many IT suppliers use agile software development and Continuous Integration these days. But they stop their iterative approach at the boundary to production.

One problem of having separated silos for development and operations is that in most cases these two silos have different goals (dev = throughput, ops = stability), Diener mentioned. In contrast, a DevOps team has a common business goal.

IT suppliers can adopt DevOps practices, as Diener explained:

In order to adopt DevOps practices, the supplier has to find out what his client’s goal is. It has to become the supplier’s goal as well. We at cosee use product vision workshops to shape and document the client’s goal (impact) and its user’s needs (outcome). That’s a prerequisite for an iterative and experimental product development approach.

The DevOps movement tries to tear down silos and avoid classical hand overs (aka throw over the fence). As a client, you have to choose the right supplier who is willing and skilled enough to work with you in a collaborative way, Diener suggested.

InfoQ interviewed Konstantin Diener about adopting DevOps practices from IT suppliers.

InfoQ: How can suppliers deal with dependencies with their clients?

Konstatin Diener: That’s a very good question. Even greenfield products do usually have external dependencies. Maybe the product’s user interfaces are designed by an external agency or data protection topics are handled by the client’s legal department. This situation often again leads to having silos.

My advice is to use DevOps collaboration models to avoid these silos. First, you can try to embed these experts (designers, lawyers etc.) into your cross-functional DevOps team. That’s the classical agile way. If your team is not equipped enough to ship valuable product increments, add the missing expertise to the team.

Second, you can collaborate with these experts on a daily basis using job rotations, daily standup participation, pairings, etc. There are plenty more patterns in Matthew Skelton’s & Manuel Pais’ book Team Topologies. If your team hands products or product increments over to the client’s ops team on a regular basis, you might want to use some of Google’s patterns described in the SRE book like Production Readiness Reviews (PRR). In this case, the client’s ops team acts like an SRE team and checks the product’s production readiness based on a predefined PRR checklist.

InfoQ: Is it possible for an IT supplier to adopt DevOps practices?

Diener: Of course, it is. A prerequisite is modern software development practices. A good read on that topic is Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. In order to work in small batches one has to practice real Continuous Integration including trunk based development, very few branches and a solid basis of tests.

Furthermore, as a supplier you have to keep your application in a releasable state at any time. If your client wants to set up a new ready to use instance of the product, it must be possible by simply checking out a given repository and running the build & deployment pipeline. As you run your application in production or at least try to come as close to it as possible, you grow your product’s features and infrastructure guided by your own metrics.

InfoQ: How can DevOps be applied to do handovers between suppliers and clients?

Diener: As a supplier please don’t just use three days of workshop to hand a product over to your client. That’s fire and forget style. We at cosee love to use the two collaboration models described above to hand a product over to the client’s employees. Either we embed these people to our cross-functional DevOps team and take "our last steps of the product journey together", or we just collaborate with our peers by means of pairing, job rotation, etc, while remaining in different teams. Both approaches last several weeks or months, not just three days.

InfoQ: What benefits can blameless postmortems bring? What’s needed so that suppliers and clients can do them together?

Diener: "Sharing is caring" is an important mantra of the DevOps movement. First, both doing blameless postmortems and sharing the results with the client builds trust. Second, if the client’s team will operate the product in the future, it is crucial for them to be familiar with product history, especially with the things that went wrong in the past.

Rate this Article