Stay competitive: embrace platform engineering

Platform engineering establishes an internal development platform (IDP), which helps support teams within cloud–native enterprises and encompasses the platform's design, implementation, and operational aspects throughout the service lifecycle. It has recently gained significant popularity due to the growing demand for improved developer and operations practices.

Platform engineering can provide “golden paths” or “paved roads” that developers can quickly adopt if approached correctly. These terms are used mutually, but they essentially address the same need–that platforms should offer an easier way for developers to build, ship, and run their software. The platform provides automation and different levels of abstraction to support the software development process according to a company’s governance.

Software development continues to gain traction in today's business landscape, regardless of the sector. Companies must prioritise investing in a well-designed IDP to achieve higher productivity, efficiency, and motivation.

Here’s a list of how having an IDP can help your business:

Speed up time to value

It's not just about speedily deploying software; it's about the broader effect new software solution has on user experience and business growth. A robust platform acts as a catalyst and can shield developers from the intricate details of infrastructure management–enabling them to focus on crafting features and functionalities that matter most to users and the business.

Increase cost efficiency

A unified platform acts as a catalyst for strategic financial management practice. Centralizing infrastructure and tools through a platform increases cost transparency and empowers service owners. With this visibility, teams can confidently gauge and balance their expenditures, aligning them seamlessly with the revenue and business value they bring. This convergence of cost awareness and business-driven decision-making fosters a culture where IT investments focus on value generation just as they do with cost containment.

Improve Developer Experience and attract new talents

Attracting and retaining talented developers is key to any software-driven organisation. By investing in platforms to unify and streamline software delivery, an organisation lays down clear, safe tracks for its developers to race on. A platform provides a welcoming environment to start projects and the safety to experiment. Thanks to a robust tech stack, the platform team can enable developers to produce meaningful work without friction.

Ensure compliance and security

With the digital landscape being as vulnerable as it is, tighter security and privacy are no longer just options; they’re necessities. Guardrails like Automated Audit Trails, Policy as Code, Secured Self-Service, and Consistent Environment Configurations can be integrated into your platform. A successful platform integrates compliance and security into the workflow seamlessly. That way, developers can focus on innovation without the burden of security and regulations.

Check out the podcast episode "Platform engineering done right" about the capabilities of an IDP in a Portuguese bank, Millenium BCP.

IDPs offer self-service capabilities for developers, enabling them to focus on their most important work. Many businesses know the benefits of adopting IDPs, but finding the right talent and strategy to build a compelling platform is challenging.

How to get started with platform engineering

There are many factors to take into account. Technical teams must collaborate with organizational stakeholders to obtain the necessary digital platform support and resources for the project. Getting executive help is crucial, as building an IDP alone requires significant resources and isn’t just about technical challenges. 

This undertaking can be costly, particularly for larger organizations. So here are some steps a CTO could take to get started:

1) Get management buy-in and let them own the greater vision

2) Establish a team and let them define their charter and mission

3) Discover opportunities that provide good value to application development teams

4) Establish measurements for success

5) Prioritise, focus, and deliver (software and documents)

6) Capture feedback and outcome

7) Communicate achievements and challenges to sponsors and stakeholders

8) Revisit team charter (mission)

9) Iterate from step 3

Learn more about each step in our blog series "If I were a CTO, I'd approach platform engineering like this." 

Hear how TV2, a Danish national TV station and streaming platform, got started with platform engineering.

Don’t build on assumptions—experiment and improve

Falling into the rabbit hole of building on foundational layers is common. Before we welcome our first team into the platform, we want everything in place. After all, we want developers to have a great experience, so we need to “have it finished” for them to run their services. 

But things are never done when it comes to software. From the start, we need to work on incremental improvements with actual developers as early as possible. Otherwise, we build on assumptions, and they tend to fail us. After all, we haven’t proven the right to play as a platform team.

Perhaps this anti-pattern comes from the word “platform”. We believe it should support the entire software delivery, security, quality, monitoring, and operations upfront. It’s okay to think about the bigger picture, but start out small and build the Thinnest Viable Platform iteratively (a concept from the book Team Topologies). So, figure out the smallest possible use case that provides value to developers and build just that. Measure the outcome and learn what to build next.

If you’re scared of going into production (as we all are) and just need to do a little more work, resist this urge and reach out to your most open colleagues who want you to succeed and offer their help to test the platform.

To learn more about the challenges and pitfalls of Platform Engineering, check out the talk on “Platform Engineering is Hard, and We are Doing it Wrong” at DevOpsDays Denmark 2023.

Documenting your IDP

Begin by creating a documentation plan and anticipate what matters based on the needs of developers, depending on the challenges they’re currently facing. If you don’t, you will likely face the issues listed below:

• Developers will need help getting started on using your platform and its services.
• You will need to explain how certain concepts and ideas work repeatedly.
• Developers will remark they tried following your documentation but failed one of the steps as they didn’t have the correct version of specific software installed.
• Developers will approach you for troubleshooting when they face roadblocks rather than referring to the documentation.
• You will constantly direct the same people to the same documentation, with little results every time.

The goal is to provide a clear overview of your users and how it can benefit them. Save the detailed technical documentation for later. Developers are looking for platforms that are easy to understand and use. By keeping their needs in mind and providing good documentation, you can attract more developers to adopt your platform.

Check out our blog post on better documentation for better platform developer experience for more insights.

Choosing your platform engineering tools

Backstage? Crossplane? Argo CD? GitLab? Let’s rewind a little here. Each organisation will need different tools that work for them.

Technology and tools are essential for a platform to deliver value to its users. Some choices must be made early, while others can be made along the way. The infrastructure the platform must run on should, of course, also be decided at an early stage. Should it be built on a cloud platform, on-prem, or a hybrid?

Like with all other critical decisions, it should be made with the right stakeholders in mind. That’s why you should involve shared services (finance, procurement, security, etc.) when deciding. 

Here are a couple of things to remember: 

• Avoid tight coupling: Consider utilizing open-source software and tools that offer a good range of 3rd party integrations over a one-size-fits-all approach. This will save you from becoming vendor (or technology) locked in the future.

• Accept that things will change: Whatever your decision, you’ll likely be looking to migrate in 2-3 years. 

Other tool choices are easier and should first be made when you’re ready to adopt them. Avoid making upfront commitments to tools you don’t plan on using in the near future. Because tools and technologies change rapidly, follow the Lean practice to delay commitment until the last responsible moment (as described in the book Lean Software Development). 

It’s also worth considering how many innovation tokens you can afford to spend on new tools. Platform teams are not excluded from being exposed to cognitive overload. As boring as it sounds, sometimes it’s better to start with tools you’re already experienced with and have available and then gradually investigate if they are still fit for purpose.

Most options to assess software development focus on local productivity, quality, and consistency in the delivery process. When it comes to DevOps, there are well-established metrics thanks to the DevOps Research Assessment (DORA) program:

• Deployment frequency
• Lead time for changes
• Mean time to recover
• Change failure rate
• Reliability

These metrics allow us to capture the impact of DevOps culture and practices in quantitative terms related to IT performance and quality. Lately, attention has shifted towards evaluating how developers feel about and value their work by taking a DevX-centric approach to measuring success.

Measuring Developer Experience

Measuring DevEx is a daunting task, though, as the concept itself is very broad. It’s helpful to start with a framework that identifies the three core dimensions of DevEx: feedback loops, cognitive load, and flow state. These dimensions emphasize that DevEx is not only a technical matter—tooling or workflows—but also primarily about developers’ perceptions.

Developers are human, after all, and no single quantitative metric can accurately capture DevEx. For this reason, collecting qualitative feedback from developers through surveys is imperative. This kind of feedback describes the perceived complexity and satisfaction with deploying code and using a platform, among other aspects. For example:

• Easy-to-use tools help developers streamline development and deployment quickly, without hassle.
• Self-service capabilities support developer independence and control.
• High-quality documentation lets developers navigate complex infrastructures. 
• The platform enables collecting diverse metrics related to DevEx.
• The fast setup of a development environment fosters productivity and creativity in realizing minimum viable products.

Ultimately, platform engineering is an effort that goes beyond improving productivity and leading to faster innovation. By improving DevEx, a platform ultimately makes developers happier, improving retention, talent acquisition, and success in realizing business goals.

Watch Nicole Forsgren’s talk "Why even DevOp—making our days better" for more information.