Platform Engineering: Our Research Focus for 2023

PivotNine's research focus for 2023 will be on platform engineering which is a new name for an old idea. We think of platform engineering as creating and maintaining infrastructure—the platform—on which other things get built.

Given our focus on enterprise infrastructure technologies, the kinds of companies and products we include in this broad idea should be fairly clear. It's the same servers and storage and networks and software we've always covered, but we think the new term could be genuinely useful, as we've stated before.

We've done some thinking over the past couple of months, taking in the various trends we've been observing and what clients have been saying. The idea of platform engineering means, and

Building for others

We hope to convince people that platform engineering should be about building infrastructure specifically so that it can be used by other people. This should have always been the goal, but too often IT organisations have been somewhat selfish and inward looking. Their focus has been on the technology and not its benefits to other people. They have focused on technology that makes their own lives easier, often at the expense of other people.

The appearance of cloud computing, particularly Infrastructure-as-a-Service, should have been the long overdue wakeup call that shook everyone out of complacency. It has been, but not nearly as much or as quickly as we believe it should have been. Organisational behaviour in enterprise IT, particularly in infrastructure, has been remarkably resistant to change.

This slowness is particularly stark when we compare and contrast the behaviour of application developers with infrastructure teams. Developers have proven to be far more aggressive in changing the way they work. Partly this is because software is more malleable and easier to change than hardware, but not so much more that infrastructure couldn't have changed more quickly. We know this to be true because the changes have occurred, just mostly in cloud and as-a-Service companies. Change came from without, rather than within.

The as-a-Service moniker is a substantial clue as to why. Internal IT, as I have long argued, has not been good at customer service. Internal IT has been aggressively disinterested in what its customers want because it has not seen them as customers.

That is now, finally, changing.

The past few years of pandemic accelerated the desire to automate sluggish IT systems, which we think is mostly good news. Feeding the machines with the blood, sweat and tears of human beings is incredibly tedious and wasteful, if not downright immoral. Change was forced from without, and many organisations surprised themselves with how much change they were actually capable of. Infrastructure people, but particularly infrastructure vendors, have embraced automation and are making their systems more programmable.

Death to DevOps

A lot of the pressure to automate has come from developers and Infrastructure-as-a-Service. The techniques have been around long enough that a critical mass of software developers now use highly automated processes by default. Software begins on a laptop somewhere and, thanks for containers, that laptop ends up in production via the convoluted yet heavily automated process of DevOps.

The term DevOps as we hear it used by clients loosely encapsulates the idea that developers and operations are all part of an integrated system that is operated mostly as software. The software parts are full of CI/CD pipelines and automated test suites and APIs that talk to each other. The infrastructure also does this, if you're using public cloud services or the complex Rube-Goldberg machine that is Kubernetes. A lot of traditional infrastructure vendors have come to the party, even the laggard Cisco.

Yet we think DevOps as a term has proven to be too vague. It covers too much, lacking a clear boundaries to indicate what DevOps does not cover. We think platform engineering can provide clearer limits while importing the beneficial parts of what we think DevOps was meant to achieve.

DevOps is really about communication between different groups, but by blurring them together (particular when we end up with strange, Chimera-esque creatures like FinDevSecOps) we lost clarity on what makes development and operations different. When everyone is special, no one is, and we lose the real, tangible benefits that quaint concepts like division of labour provide. There are things both disciplines can learn from one another, definitely, but to do this well requires that we acknowledge their differences.

Infrastructure operations and software development are different. And that's okay.

Focus on platform teams

By choosing to focus on platform engineering this year, we hope to tease out what good platforms look like and how enterprises can build them. Not just the few global brands that built everything themselves from scratch in the cloud, but the broad majority of enterprises that have a little bit of everything. Progress is accretive, and adding a few things here and there to make things better is a wiser choice than trying to attain some unrealistic idea of perfection overnight.

Our aim this year is to plant some flags near useful progress points that enterprises can work towards, and then work backwards to where they are now, erecting markers and signposts along the many paths they might take. There is more than one right way to go, though many more ways that lead to a sudden plunge off a cliff or into a thorny bramble.

As many organisations are looking to constrain spending in times of uncertainty, there is plenty of work to be done that we know will improve things. Much of it is simple, straightforward stuff that can be built upon later to make something more complicated. Each step is a platform on its own, and any journey begins by taking that first one.

This is PivotNine's first step on our year of rambling, and we hope you'll join us for at least part of the way.

If you'd like to talk to an analyst to discuss your company's platform engineering efforts, as a customer or a vendor, book a meeting today, or email us at [email protected] for more information.