Both smart but desperate companies invented how to unlock their ineffective DevOps implementations. They built Internal Developer Platforms (IDE), as a layer upon the set of tools in DevOps team portfolio. This is how a developer’s platform concept arose and reached its own, broader name: Software Engineering Platform.
IDE was designed to fulfill the self-service mode for DevOps engineers, providing all necessary system and platform integrations, tools, workflows. Covering the entire application’s lifecycle. This required a new team dedicated solely to build and maintain platform and interface developers teams may work on.
A New Paradigm Platform
This new team is based on a new paradigm: taking DevOps developers’ perspective to assure that the process will be smooth, according to their point of view. It’s getting even worse when the company following its strategic business needs to hire developers with advanced, specific skills. Their skills are not used effectively, not fully, underutilized.
This is how and why a developer’s platform concept arose and reached its own, broader name: Software Engineering Platform. The cornerstone of it is a team dedicated solely to managing/administering the platform. The platform offers an automated and easy-to-configure environment. This change establishes different roles based on different skills. Platform developers team creates integrated, secure, dynamic, and easy-to-use workspace.
In this model, a software engineer concentrates on its primary aim – to develop a decent system with decent technology. Platform team, on the contrary, concentrates on its primary customer – developers, to make their work easier, smoother, and more effective.
Let’s avoid problems, stop being reactive
Interesting to notice, that a typical DevOps team works reactively on tickets, such as “there’s a code to deploy”. The Platform Engineering team in contrast focuses on building a platform that will allow developers to avoid problems. The developer remains the one who decides about certain parameters and may easily choose the options or actions from his or her interface, except for those issues and options that are arbitrarily settled by the platform for architectural, regulatory, or other reasons. The developer is now supported in the entire range of features his code needs to be equipped with. They may start to act similarly: to help users avoid problems and win business opportunities.
We speak about building both a standard and self-service product which doesn’t require code developers and platform developers to communicate on an everyday basis. There’s a platform with a catalog of services – and it doesn’t require the typical developer to do additional configuration, change pre-configuration scripts, etc. The platform is easy to onboard newcomers, who quickly may become full-fledged members of the team.
We are at the beginning of an exciting journey. Customers start to talk about the necessity of the Platform Engineering approach in their software development process. Some vendors begin to provide off-the-shelf platforms. What is worth stressing is that platform software engineering is an approach that should look to avoid any vendor-locking.
It raises the question: is it still DevOps – Enhanced DevOps perhaps – or is it something new?