So much has been debated lately about the emergence of “Platform Engineering” as a solution to software operations problems.
It’s an interesting proposition.
However, it is not your silver bullet that will fix all things one felt didn’t work out with Dev versus Ops, DevOps, or SRE.
We are missing something very important in our conversations when we trumpet platform engineering as a panacea.
3 things come to mind to fill the gaps in such conversations:
- Clear articulation of the problem we would like to solve
- The opportunity we are trying to explore and
- The challenges we want to overcome
To this day, how many of us can confidently explain SRE or DevOps during an elevator ride or a water cooler conversation to our colleagues, peers, decision-makers, partners, or customers?
So much so that they would like to hear more and learn more when the conversation has concluded.
It has become clear over time that many involved in the technology product lifecycle have genuine difficulty articulating where one discipline, one set of practices, or one mindset ends and another one begins.
To make things more complicated, the explanation or description should differ and not look the same across different companies, engineering cultures, and business domains.
It then holds true that what we do, how we do it, and most importantly why we do it is 100% contextual.
It deserves deep thought and analysis of your problem spaces, challenges, and opportunities.
It won’t help anyone to merely relabel a department, a team, or a discipline to “Platform Engineering” if we haven’t done the work to understand our customers’ concerns, internal or external, or our business nuances.
Ricardo Castro, a Continuous Delivery Foundation Ambassador, has aptly said, “People saying that Platform Engineering replaces DevOps is enough evidence that those people didn’t get what DevOps is all about.“
Platform Engineering will do very little unless we collectively learn to communicate the value propositions of the various disciplines, models, and implementation approaches. We ought to advocate and influence more.
We should aim to become better coaches and educators for our business and technology colleagues and repeat ourselves as often as necessary.
All this while DevOps matures further, SRE evolves and Platform Engineering takes its place among the implementation options.
We should try harder to clearly and consistently “sell” how the above can help create better products, services, customer experiences, and more effective technology organizations.
Platform Engineering risks being diluted, compared, and downgraded to yet another technology buzzword, shiny object, or as Gartner calls it, “hype”.
This will certainly be the case if we can’t help each other articulate the following questions before deciding which path suits our specific circumstances:
Why should one embrace these mindsets, models, practices, techniques, and disciplines?
What value do they bring to my team, my product portfolio, my customers, and my company culture?
How are they different from each other?
What are the synergies amongst SRE, DevOps and Platform Engineering, and other existing disciplines?
Why can’t we do the things those practices promise already with our existing people, processes, culture, and technology?
What are our organizational blind spots, pitfalls, and idiosyncrasies? Are we ready to expose them, talk about them and continuously work towards a better outcome?
He is a strong advocate for software leadership effectiveness and clear SRE practices.