Platform Engineering - Perforce Puppet: Taming chaos in DevOps teams
This is a guest post for the Computer Weekly Developer Network written by Margaret Lee, manager of product management at Perforce Puppet.
The full title of this piece is “Taming chaos in DevOps teams… and what success looks like in practice” so let’s dive in.
Lee writes in full as follows…
DevOps may have laid the cultural groundwork – collaboration, automation and shared ownership – but software has become faster and more complex, with added pressures of compliance, demands to reduce riskand the need to get products to market faster.
DevOps practices alone aren’t enough to tame all this.
Platform engineering is an answer that addresses this chaos with a structure that turns the DevOps ethos into something scalable, consistent and designed for reuse.
IDP Golden Paths
However, like any technology, theory does not necessarily translate into success in practice. For instance, internal developer platforms (IDPs) are designed to be curated, self-service environments that enable developers to spin up infrastructure, deploy code, run testsand more.
Done well, IDPs create what some call ‘golden paths’: pre-approved workflows that balance freedom and security. However, when overly rigid or over-engineered, IDPs can backfire, adding yet more complexity. Platform teams need to be able to enforce consistency while staying open, using policy as code, audibility and modular frameworks. That tension – between abstraction and transparency, autonomy and control – is where many platform teams struggle.
The way to eliminate this tension is to build a platform that will solve 80% of the problems for your developers. Build flexibility into the platform so it is not overly prescriptive, but prescriptive enough to solve major operation obstacles and ensure consistency and security are enforced – abstracting the complexities away from dev teams and allowing them to do what they do best: build and develop products and applications.
When building an IDP, knowing who the audience is and what problems they face is table-stakes information. Otherwise, adoption will be low and ROI unattainable. The starting point has to be knowing what will make a positive impact on users because, without that, there will be more bespoke implementations and divergence because the platform is not solving real problems for real users. Start with the pain pointsand also know that not every organisation needs a large-scale IDP from day one. Questions to ask here include: are onboarding times too long? Does it take weeks to provision secure infrastructure to build on? Are changes difficult to track or roll back? Those are signs it is time to move beyond tribal knowledge and ad hoc scripts.
This is why more leaders are treating platform engineering as a product mindset, not just technology and that means a cultural shift, which is where some teams will hit a wall.
Handle with care
Perforce Puppet’s Margaret Lee: Platform engineering has to prioritise usability
However, organisations need to treat internal systems with the same care and intent they give customer-facing products, with clear users, goals and feedback loops. Platform engineering teams are not just building architecture; they are solving problems like reducing time to deploy, mitigating risksand helping teams work more efficiently.
Likewise, platform engineering has to prioritise usability. The best platforms disappear into the background, removing friction rather than adding layers, making access and insight easier. Think natural language queries, role-aware views and self-service with appropriate guardrails.
It’s also not enough to help teams move faster; they also need to do so safely, which is why security and compliance have to be first-class citizens here. So, policy-as-code, identity-aware access controls and infrastructure insights that provide full traceability have to be central to any platform engineering strategy, all while not getting in the developers’ way, just quietly enforcing security.
The organisations that succeed best in platform engineering treat it like a living product, measured by adoption, feedback loopsand real-world value, such as reduced time to onboard or less friction, not just uptime and delivery speed.
Those organisations also know that they need to stay flexible, adapting to the gaps that arise when a space or problem matures, which may mean new challenges or needs emerge. Plus, platform engineering will inevitably change and I would argue it is already changing, especially with the AI boom. What it looks like today will not be the same in five years (and probably a lot less).
When it works well, platform engineering is a tool that supports the challenges DevOps faces, giving developers what they have always wanted: the freedom to focus on building great software without the distraction or being bogged down by what’s under the hood, serving them (and not directing them). While DevOps remains the logic generator that keeps the SDLC together, platform engineering is emerging as the best way to handle all this operationally, ensuring security, compliance and resiliency.
DevOps isn’t dead – it’s getting its own platform.
