DeepDive: DevOps in a Managed Cloud environment

Origin of DevOps

DevOps emerged as a response to the traditional, siloed approach to software development and IT operations. Before DevOps, these teams worked independently, often leading to inefficiencies, slower development cycles and a lack of coordination.

Pioneers of the DevOps methodology advocated for a cultural shift that emphasises collaboration, automation, and continuous improvement. By breaking down the barriers between development- and operational teams, organisations could achieve faster delivery of high-quality software, enhanced scalability and better alignment with business goals.

The key principles of a DevOps way of working are:

• Encouraging open communication and collaboration within- and between teams.
• Automating the integration- and deployment processes (CI/CD)
• Automate repetitive tasks to increase efficiency and reduce manual error

To good to be true

It almost sounds like DevOps is now the industry standard for IT teams across the board. However, in many companies and organizations, that is still not the case. Many teams are still struggling to work in an 'Agile' way, especially within a more operational context where it becomes harder to plan work within an Agile framework.

The DevOps method works great when the development and operational teams of an organization can work directly together. However, in many organizations, the operational team is focused on governance and control functions, delegating the actual deployment role of their team to an external partner or team.

With the introduction of a third party into the mix, the DevOps way of working becomes harder to apply. Communication and collaboration are more difficult, sometimes throttled via ITSM tools like TopDesk or ServiceNow. This creates a 'transparent wall' between the teams, allowing them to still 'see' the other side but not speak to them directly.

Creating a flexible layer

When organisations struggle with the efficiency of their development and deployment cycles, most often the teams get the blame. They are expected to work harder, faster, and (if even possible) more precisely. The fundamental issue here is that the teams are not the problem, nor are they the cause of the real issue at hand; it’s the way they’re allowed to work together.

To solve the issue for both teams, we could adopt both teams' processes, changing their ways of working and combining their workloads. However, that’s not a real-life possibility, especially when the teams are not even in the same company, such as when a third party is the active operational team.

No.

The real solution is to create a flexible layer between the teams—a pool of experts who can function as translators between the development and operational teams. By creating this layer, teams can work together in a DevOps (Agile) way with the new team. This setup creates an Agile framework for all teams to work together, increasing the efficiency and speed of the development and deployment cycles.

Translating between Dev & Ops

We interact with both the development- and operational teams on a daily basis, providing that desperately needed translation layer in between. We do this by proactively participate in meetings on both sides or join in working out strategies, creating designs- or code to help out the teams in their journey. By creating the actual hands-on experience for the teams, instead of just being an advisory consultant from an ivory tower, we quickly become the trusted partner. The end result is a proactive and open communicative collaboration between us and the teams.

Why? Because our mission is simple; when we help our partners and their teams succeed, we also succeed in our goals.

Your success. Our commitment!