“DevOps is dead, long live Platform Engineering” article was not that long ago. But today it is justified to ask, if Platform Engineering is not, in fact, dying as well.

AI is winning the budget-battle over Internal Developer Platforms. Since the public release of ChatGPT in November 2022 (the one which started AI rush for good), I hear about AI at least dozen times every day… and hundred times during any budgeting / resource planning / strategy-related meetings. I wish to say this about Platform Engineering, but the truth is – it’s not that sexy, even if it can bring more value to the business today, without all risks assigned to AI (technical, cost-related, legal or ethic ones). Is business people so blind that they do not see it…? No. We, Platform Engineers, are not speaking the language they will understand.

I think the main reason we cannot convince Business to build Platforms – and even so, so frequently fail with delivering the promises made even if we are trusted with implementation budget – is because Platform Engineering experts, me included (especially me last few years…), are focused so deeply on platform itself, that we fail to “sell” this idea to the business properly – and build the platform, which will be a fast-flow enabler.

What I see now is that Platform Engineering is entering the “trough of disillusionment phase” (Gartner’s Hype Cycle of Emerging Technologies, explained here). I had been inspired by Syntasso Colleagues talk & article, which started to make me think about how we sell the idea – and then, how we delivered Platforms. What you are going to read is not pleasant, but… if we do not change our approach, Platform Engineering will be dead. But there is still hope – because once I’ve posted this as a thought, it went viral, and I think community in general starts to see it as well.

So, let us first make a short retrospective why Platform Engineering seems to be dying – and then think about what we can do better in order to resurrect it. And to win this budget-battle over AI (or better way – find a synergy with AI initiatives).

Reasons, why Platform Engineering reached “trough of disillusionment”

So, why Platform Engineering is dying – or using more accurate words, loosing the budget-battle with AI and not being welcomed by the companies which never tried (or tried and failed)? There are few reasons I suspect to be the clue for finding our trend killer.

1. Platform not even started, because engineers / managers used DevEx and Self-Service as a key selling point. Business do not care about DevEx and Self-Service if we won’t calculate and articulate a true value behind it: which is reducing SDLC cost of waiting, meetings & re-inventing technical configuration with each and every new software / new release, and increasing a time-to-market for new business features & fixes through self-service and well-defined responsibility boundaries. So instead “we will have improved Developer Experience”, we should say “we will have less meetings & fast flow through improved Developer Experience“. I hope you see a difference now.
2. Platform treated as technical project, closed within DevOps Team only. Under this topic I place all situations where Platform Engineering “adoption” ended up as initiative focused on orchestrators deployment, portal creation, a new tool deployment or infrastructure automation. Yes, all those things are often necessary to be performed within true Platform Engineering adoption – but those are just tools, not initiative goal. You can have a Platform without a portal, you can have a Platform without fancy orchestrators (if your company is small, sometimes terraform or simple script enabled manually will be enough), but you cannot have a successful Platforms without recognising developers cognitive load, thus… talking to other teams and departments. Platforms are not technical projects – they are a work organisation change initiatives.
3. Platforms over engineered, thus – budget exceeded. There are two scenarios I see under this point: either the goals & success measures had not been set or communicated (aka: platform management failed) – and engineers had not been provided with priorities because of it; or engineers were so focused on technological perfection of the platform, that they “forgot” to deliver a value with assumed budget. Platforms should not be perfect. Platforms should be good enough, and easy-enough to use by developers so they won’t avoid using it (thus, shadow-platforming by themselves).
4. Platform being “sold” too low in the organisation. It results either with a tied-hands of Platform Manager (not being able to change SDLC responsibility boundaries, communication flows or make necessary changes in technology) – or, focus on addressing small percentage of application teams, not being able to scale for the whole company – thus, having a Platform not addressing true bottlenecks, achieving a local optimum instead of global one.

Delivering value with Platforms – and “selling” the concept efficiently

How to resurrect Platform Engineering as a trend – and move it to the “Plateau of Productivity” phase (or simply: deliver real value with Platforms)? Well, I have few ideas.

• Build a business case around SDLC metrics, which impacts the cost & efficiency. Time-to-market for business apps, cost of meetings / developers handling DevOps tools are obvious ones, but there are also important ones not always being associated with platforms, like business application team experts retention causing delays and onboarding costs (people tired of waiting, or permission model blocking self-service), time-to-fix (because of fuzzy responsibility matrix for troubleshooting & bug fixing – platforms are organising it) or even technology portfolio management, leading to… hiring costs (platforms are usually reducing the number of DevSecOps technologies used, and the ones remained will have a lower entry-level for developers). Depending on what you are struggling with, Platforms objectives may also differ.
• Do not fight AI as competitive trend – because… it’s not competitive (this is my recent revelation… I am not that smart after all, because it took me a while). In fact, you cannot utilise AI tools & scale RAGs / AI-supported business applications delivery and operations without Platforms. All new skills and technologies around training AI-models, utilising LLMs or managing costs is already a new cognitive load for application developers. A cognitive load Platform Engineers can address! I will risk a statement that AI used at scale will fail without Platform Engineering. Fail as not delivering the promise made to business management, not being able to prove a business case.
• And speaking of cognitive load… your Platform should be driven by its reduction. So do not start Platform initiative with Backstage instance deployment. Start with business analysis! Yes, business – because your developers and ops teams are, in fact, your internal customers. Treat them accordingly! Platform, just like any other system, should start with recognising the needs and prioritising based on what brings the biggest value.
  • “Ok, but how to do a business analysis of SDLC process? We know how to do it with business apps, but with Platforms…?”. Well, lucky you, because last 4 years I’ve spent mastering this topic. And you can now learn on my methods and my mistakes within few hours – here are more details.

Cognitive Load analysis, Platform Business Case, SLA & Goals definition – missing in many Platform initiatives

Ok, so… is Platform Engineering truly dead? Well, just like any trend – expectations were high, and multiple organisations tried & fail. There are many that succeeded though – and from my experience, the ones which are happy with the Platforms, are the ones which understood that Platform Engineering is 80% organisation change, 20% of technology adoption. And the companies which succeeded, usually started with cognitive load analysis, business case, SLA & goals definition – which led them to focus on what is essential to achieve fast flow of SDLC.

If you are interested in catching a high-level view on Continuous Platforming – here is my article about it.

Past four years I had a chance to lead successful Platforms, and having previous experience as analyst & software developer, I have used the skills necessary in my previous roles within Platform Engineering. I have developed my own Platform Analysis framework, and having a long experience with SDLC as developer and tech lead, I have created a guideline how to talk to developers and management about Platform Engineering to build business-case, set-up goals, convince right people to invest – and avoid mistakes I’ve made within the journey. You will find my “Efficient Platform Manager” course here, which is 100% online, self-paced.