The world of software development characterized by DevOps is moving fast; one new tool chases the next and new buzzwords like DevSecOps or SRE (site reliability engineering) make headlines. A frequently discussed question in the DevOps community is what is the next big thing. Platform engineering is highly touted as the latest potential replacement for DevOps. The latest edition of the online conference PlatformCon attracted thousands of participants from around the world.
Advertisement
- With a focus on the productivity and job satisfaction of development teams, platform engineering is establishing itself as an alternative to the DevOps toolkit.
- Platform engineering seeks a balance between standardization and flexibility.
- To be successful, platform engineering must follow the principles of product development.
The DevOps community is quite an open-minded community as there is no manifesto or methodology that can define an in-group or out-group. Concepts such as SRE or platform engineering are considered more as a supplement to the DevOps toolkit, allowing companies to improve the way applications are delivered and increase the productivity of development teams. In addition, productivity is a good indicator of job satisfaction (keyword: developer experience). In practice, factors such as work and cognitive load on development teams often have a negative impact on productivity.
Platform engineering is different from other current trends because it addresses a problem that has only recently come to attention: the increasing complexity of software delivery. Platform engineering addresses this challenge with the aim of improving the productivity and work satisfaction of teams. This comprehensive approach also explains why platform engineering has gained popularity so quickly.
(Picture: Julian Dolman Headshot Photographer ,
Mirko Hering is Accenture’s managing director and global DevOps lead. He is the author of “DevOps for the Modern Enterprise” and shares his experiences in the blog “Not a Factory Anymore”.

Is Platform Engineering the next DevOps? – No!
So is platform engineering the new DevOps? Rather, no. DevOps has given the IT community a plethora of tools and principles that are constantly being improved and extended. DevOps is characterized by a strong cultural dimension: “flawless post-mortems”, for example, emphasize avoiding burnout and breaking down organizational silos. These are overall organizational concerns, while many trendier concepts examine a specific dimension: DevSecOps focuses on security, SRE on modern operating models. Platform engineering aims to provide teams with the technical capability to deal with increasing complexity. Platform engineering is therefore a new way of looking at DevOps. It combines the focus with the developer community and corporate interests such as security and infrastructure operations.
against the growing complexity
Why is it so complicated to deploy applications and IT infrastructure today? About 15 years ago, quarterly software releases were common, and for each release developers had to deliver a few dozen systems – mainly monolithic individual software and software packages. Go-live was usually preceded by a strict code freeze period lasting several weeks. A “war room” had a printed project plan including a list of all required elements and their versions.
Since then, the situation has changed significantly with the emergence of cloud (native) technologies (see Figure 1). It is easier to incorporate the services of cloud providers. But the growing proportion of open source software results in hundreds of open source elements being included in software releases, with many variable dependencies that multiply the elements included in the source code. The typical release cycle is no longer quarterly, but monthly, weekly or even shorter in duration. The associated work, as well as the rapidly growing number of tools, increase complexity. While a lot of work used to be done manually, today dozens of tools are involved in the release cycle – including in the areas of testing, building, releasing and infrastructure. The practice of allowing teams to choose their own tools, which has been developed in the course of DevOps and agile methods, has also led to a strong diversification of tools, especially in larger companies – and has thus contributed to even more complexity.
These aspects of IT delivery have changed significantly in recent years (Figure 1).
(Image: Mirko Hering/Accenture)
While in the days of war room releases, the individual responsible people were still able to gain a complete understanding of the software to be delivered, today this is hardly possible given the multitude of processes and tools as well as shorter release cycles. However, increased complexity is not inherently bad. Rather, it is a consequence or side effect of significantly more comprehensive delivery capabilities in software development. However, platform engineering provides suitable means to effectively counter the threat of losing control due to excessive complexity, as well as the increased costs and risks.
Platform engineering combats complexity with a uniform framework and common templates. This is more difficult than it sounds, as many failed implementations of integrated tooling platforms based on the “one size fits all” motto have shown. Especially in large, diverse organizations, it is often difficult to strike the right balance between standardization and flexibility when bringing a variety of technologies under one roof for everyone involved.
To provide developers with a variety of options to find answers to their most common problems related to security, infrastructure or application deployment, platform engineering includes extensive documentation and a variety of patterns. Additionally, company standards should be made easy to follow. But development teams also need the flexibility to experiment with new tools and practices. This primarily includes new services and functions from cloud providers for software engineering. Platform engineering must achieve the right balance and the necessary governance for the pendulum that constantly swings between expansion through experimentation and subsequent consolidation. This is the only way to find a reliable operating model for the developer platform. The architecture of the platform should be based on the architecture of business applications (see Figure 2). To achieve this, the entire software development life cycle should be based on an integrated platform that is only loosely coupled. Among other things, this ensures the freedom to replace components when it appears necessary – for example if a new, better tool is available for a particular task. Loose coupling makes it easier for experienced teams to make changes and contribute to the platform themselves.
Components of the software platform architecture (Figure 2).
(Image: Mirko Hering/Accenture)
It is advisable to align platform engineering according to the principles of product development with a focus on internal development teams. It also involves external developers if available. The scope and approach of platform engineering is aimed at empathizing with the needs of users/customers and thus increasing the acceptance of the platform. However, platform stakeholders remain the custodians of processes and standards such as security and infrastructure. The platform development team must therefore mediate between the various stakeholders to create a workable solution for everyone involved.
