Platform Engineering is an innovative approach with a passionate community that works to improve the future of software engineering. However, just like DevOps and Agile project management before it, Platform Engineering stands at a dangerous precipice.
While having no definitive model allows innovation to flourish, it also leaves room for the practice to become bloated. Just as the DevOps Engineer job title became bloated and lost definition when it hit the enterprise IT level, Platform Engineering is risking the same fate.
So, what can we do to fix this? Nigel Kesten, Field CTO at Puppet, argues that Platform Engineering needs a prescriptive model to avoid the risk of bloat and help newcomers and seasoned engineers alike to use Platform Engineering without getting lost.
Interpretation, mental models, and metaphor
Because there are so many stimuli in the natural world, the brain uses cognitive grouping to quickly interpret and make sense of that stimuli. In short, incoming stimuli are open to interpretation, which will always be influenced by internal biases, past experiences, and other cognitive distortions.
These things cumulate in mental models that allow individuals to make sense of the world. Certain philosophers, such as George Lakoff, describe this process as metaphor. This is the idea that the way humans think and act is a result of the metaphorical meaning they apply to incoming stimuli.
Progress in computing has largely been driven by metaphor. Nigel says:
“Look at the desktop - it’s an incredibly pervasive metaphor that enabled computing to move beyond the high priests of technology to become much more accessible to office workers. It’s a familiar metaphor for them. They could say ‘I'm producing a document’, ‘I'm moving it into a folder’, ‘I'm putting it in the bin’ and they all understood what that meant. This aided in the progression and expansion of technology so that more people got value out of it.”
With that being said, not every model drives computing forwards. While the Agile project management philosophy started simple, there are now massively complex frameworks that do little but bloat what was otherwise a valuable innovation.
What we can learn from DevOps and Agile
During last year’s State of DevOps report, Nigel interviewed Patrick Debois, who he described as “the godfather of the whole movement”. This is what he learned from Patrick about the early days of DevOps:
“There wasn’t really a plan for DevOps. There were a bunch of like-minded people who saw that something was fundamentally broken in how we built, released, and operated software. And there were a bunch of practitioners who were interested in using new technologies to fix how we interact with software and each other.”
What eventually emerged from this new innovative culture was a series of metaphors that described how someone could approach DevOps and, in particular, the different focus areas like culture, measurement, and sharing. However, none of this formed a prescriptive model.
This lack of definitive direction is obvious in various online forums and communities. The conversation around DevOps is significantly different to that around Platform Engineering. Newcomers are constantly confused as to where they need to begin with DevOps because they lack a prescriptive model that gives definitive answers for the things that engineers need to learn, do, and work towards.
Something that enthusiasts within these communities need to remember is that not everyone shares their passion. For many people, things like DevOps and Platform Engineering are just a job that puts food on the table. This doesn’t make them any less capable as engineers - it just means that they have other interests. The lack of a prescriptive model specifically hurts these engineers because they aren’t as intellectually stimulated by finding the way forwards as the more passionate community members. They simply want to be pointed in the right direction, but there’s nothing there to help them.
Similarly, this lack of a prescriptive model also hurts DevOps on the organization's side. Nigel explains:
“These days DevOps engineer is about the most useless job title I can possibly imagine. You could be running CI/CD, you could be a cultural consultant, you could be essentially running different projects, it could be anything. In the absence of a prescriptive model, people struggle with what a DevOps engineer should be.”
By working with the same team that built the concept of DORA metrics, the team behind the State of DevOps report aimed to build a prescriptive model. However, while DORA metrics are a great way to focus on output and to optimize the DevOps procedures an organization already has, they didn’t help people to get started.
The final push to create a prescriptive model came in 2018 with the DevOps maturity model. Unfortunately, this came too late. Nigel says:
“There were too many vendors who saw this huge vibrant community of people who are really interested in trying to change things and said ‘Yep, our software is DevOps’. All of that started to distort and mutate the whole movement. By that point, expectations and understandings became more difficult for people to reach.”
A similar thing happened with the Agile philosophy. The original manifesto was relatively simple, but because there was no prescriptive model, consultants and vendors attached themselves to it to sell solutions that fit the philosophy. While undoubtedly many would have done so with good intentions, it resulted in big, complex, inflexible frameworks that typically run counter to the spirit of Agile.
Protecting Platform Engineering with a prescriptive model
So what can engineers learn from DevOps and Agile? Nigel says:
“This is ultimately my thesis - if the people with experience on the ground don’t step up and work together to describe a prescriptive model, the big vendors and consultants will fill the gap.”
Of course, not all consultants and vendors are created equal. As with DevOps and Agile, many will come into Platform Engineering with good intentions. However, whenever there’s a significant commercial interest in an engineering space, the natural distortions of capitalism will take over and it won’t always result in ideal outcomes for engineers.
With that in mind, what kind of prescriptive model does Platform Engineering need? Nigel explains:
“What we want is something where there's space for new practices to emerge but also has specific and concrete approaches. It needs to be useful for new people to get started but it also needs to have enough room in it for innovation to occur. Even if we all decided on a model for Platform Engineering today, that will change over the next year or so as technology and the pace of innovation change. So, whatever model we use needs to have flexibility baked in.”
Platform Engineering is still a relatively new community, and it’s already seen a significant amount of innovation. However, going back to the idea of mental models and metaphor, a good deal of that innovation has come from a shared context from the most passionate engineers within this community.
As with DevOps and Agile before it, Platform Engineering will see newcomers that work within more traditional engineering environments and infrastructures looking to transition to this modern engineering methodology. It’s these engineers that have the most to benefit from a prescriptive model as they will not be working with the same level of context as more experienced Platform Engineers.
Fortunately, Platform Engineering already benefits from some good models. Team Topologies by Matthew Skelton and Manuel Pais offers a good descriptive model. It offers engineers a high-level framework that’s relatively easy to consume, along with prescriptive guidance that engineers can build upon to help less experienced engineers adopt Platform Engineering principles. All in all, it helps both experienced and new Platform Engineers to move in the right direction while being flexible enough to be built upon.
Nigel goes on to explain:
“I think this is one of the most important things to be thinking about in these early days. Platform Engineering is genuinely a transformative approach to running infrastructure, running Opera applications, and doing software delivery. But as we keep building up this body of work as a community, it’s absolutely critical that we keep in mind the people who are going to come along later with less context, in less sophisticated environments, and with different use cases.”
A call to action for the Platform Engineering community
Nigel concludes:
“We need to take part in shaping a prescriptive model, otherwise I worry that we'll end up in the same slightly cynical spot in a couple of years that we've ended up in with DevOps. I think there is a path forward that involves practitioners being deeply involved in working with other teams like the Team Topologies folks to produce their own material. We need to be talking about how we’re succeeding and how we’re failing in a way that lets us avoid all of the mistakes of the past.”
Platform Engineers can learn a lot from how the flexible approach taken by DevOps and Agile has resulted in both of these philosophies becoming bloated and distorted. With a prescriptive model, Platform Engineering can ensure it continues to endure with its core philosophies intact in a way that’s accessible to everyone.
Thanks to Nigel Kersten for this eye-opening and insightful talk into his vision for the future of Platform Engineering. Make sure you watch the recording of this fascinating keynote speech from PlatformCon 2022.
.webp)
.webp)
