y este en el body:

The implementation of DevOps practices into the Software Development Lifecycle provides substantial improvements in software construction and maintenance. However, experience in adopting these practices varies from one entity to another, influenced by factors such as size, Agile maturity, architecture model or integrations with legacy systems.

The primary aim is to enhance the performance of development teams by introducing the concept of “developer experience” to assess excellence. Although work has been done to provide these teams with the necessary tools and to measure improvement with every change, the results are not always optimal. For example, in multi-team organisations, lack of homogeneity in the development and delivery cycle, as well as the range of tools used, leads to complexities, additional maintenance and has a negative impact on costs.

Furthermore, in organisations with a centralised DevOps team, the “cognitive load” of the development teams is reduced due to a wider distribution of responsibilities in defining the development and delivery cycle, as well as the associated tools. However, this does not prevent tensions between DevOps and the Development teams due to lack of understanding in contentious situations.

These situations divert attention away from the essence of DevOps, which aims to automate the life cycle of the software (SW) in order to align initiatives and foster cross-team collaboration, so that software can be delivered in a more efficient and less stressful way; essential for doing this on an ongoing basis.

 

A new DevOps approach

New trends are emerging that are looking to transform the DevOps model into a business product, moving away from its treatment as a mere project. The Agile Product concept is being adopted and is focussed on clarity in the interaction between teams, training to maximise the value contribution, an increased stream of deliveries and a reduced “cognitive load” for the development teams.

The proposal involves standardising the infrastructure, creating self-service interfaces for developers and dedicating a team to maintain everything as a platform. This evolution is called “Platform Engineering“, and involves changing the name of the DevOps team to “engineering team”. 

The strategy is to continue with DevOps while changing its management style to turn it into a global company with returns, guaranteeing that the needs of the development teams will be incorporated as they emerge through the Product Owner’s Agile profile to create and maintain a product that solves all their daily needs and challenges.

The main idea is to reuse existing tools and processes to minimise the initial impact. In new organisations, it is recommended to contract integrated products, such as GitLab or GitHub, that already offer the necessary tools and evolve with additional options for integration with other freemium or community products.

The creation of the Platform team will include existing DevOps, Operations/Systems/Security teams, and members of the development team convinced of the benefits of this change. Understanding the needs of the users, the ability to prioritise work and the construction of a useful platform are critical, despite the difficulty. The aim is that, through the platform, development teams will be able to develop and deliver within their required task times, focussing on the application rather than taking on incremental learning of DevOps issues.

To provide organised and comprehensive access to the new product, an “Internal Development Platform” through a centralised portal is recommended. Studies indicate that the creation of an Internal Development Platform positively impacts the evolution of DevOps practices by standardising a self-service model of tools and technologies for developers, reducing the cognitive load that could be detrimental to their performance.

 

Conclusions 

Companies such as Spotify, Airbnb and Zalando have already adopted this model, and Gartner predicts that by 2028, 80% of software development organisations will have in-house ‘Platform Engineering’ teams, providing reusable internal services, components and tools to development teams for software delivery.

 

Download the Keys for 2024