Foundational platform engineering practices

This blog about delivering an engineering platform using the principles of product management covers:

• Adopting the platform engineering mindset
• How platform engineering is an exercise in software development
• Product delivery model
• Technical product ownership

Building an engineering platform without changing organizational structures, decision-making habits, and engineering culture is a strategy destined for failure. However, simultaneously shifting an entire organization’s mindset, structures, and culture is a complex and challenging task that requires careful planning.

As your team is forming and defining the goals of your platform, you will start to think about how you can enable yourselves to build a successful engineering platform in an efficient and well-designed way. Some of your teammates may wonder if there should be certain linters — a set of tools required to improve the quality of the code — in place for the infrastructure-as-code you will write.

Others argue about using Git as a truth source for deployments, or if some form of artifact registry is needed. In another meeting, you debate the merits of CI/CD systems — with some preferring a more traditional system like Jenkins and others who want to go full cloud native with modern Kubernetes-enabled delivery tools.

Your team starts to wonder if you’ll ever get started on doing any actual work because you’re too busy arguing about the semantics of how to do the job.

When a platform team has disagreements, one way to sort them out is to remember a key point: platform engineering is an exercise in software development. You should use the same methods to develop platforms you would use for building any other application, and the team should run and test their software using a special version of the same platform tooling as everyone else.

This practice is often called “dogfooding,” which means using our own platform to help improve and build it.

In this blog, we’ll talk about what it means to build a software-defined platform in the product mindset we introduced in a previous blog.  And we talk about using principles from evolutionary architecture — like how to design and write software that is easy to change and scale — and applying them to our software design.

Let us also define what a platform product is. A platform product, first introduced in that previous blog, is a technology solution designed to serve as a foundational layer or a “platform” upon which other products, services, or systems are built, extended, or integrated.

We’ll also talk about how we can use these principles to draw circles around the types of people that operate with our platform and use this to make decisions about the APIs and services we build. Some of the questions we will answer are:

• What is the model for delivering a platform product?
• How are the advances in cloud native technologies helping platform engineering?
• How do we use the platform to help us build and evolve the platform?
• What are the domains and boundaries of the systems and services in an engineering platform?
• How do we evolve and iterate on the platform using a software-defined approach?
• What are the differences between a software-defined platform and an off-the- shelf platform?

In this section, you will understand the foundational concepts of infrastructure, developer tools, and product delivery approaches. These are essential for effectively creating and managing an engineering platform, which continuously evolves to meet customer needs and organizational goals.

This foundation is crucial as we delve into the roles, strategies, and practices necessary for successful platform engineering.

In many enterprises, not all, when it comes to infrastructure, developer tools, and other technologies needed to create and operate custom software, they will treat these as separate, one-off projects. Usually, someone who isn’t a software developer decides which tool or technology to get and which vendor to buy it from. They negotiate the purchase like it’s a typical capital investment, expecting it will be used as-is for years to come, and then pass it off to another non-user to set up, all accompanied by a detailed project plan that comes complete with a Gantt-style project plan of weekly milestones.

To do platform engineering right, you need a product delivery approach. For product delivery to really work, we must move away from the old-school IT delivery methods.

An engineering platform is a product designed to empower software developers to independently (self-serve) create, test, launch, manage, and monitor custom software solutions in an ongoing improvement cycle.

Products are meant to last a long time, constantly improving and evolving to keep up with new conditions, technologies, and the features customers want. Change isn’t just a one-time project; it’s how software operates. A product delivery model is all about the continuous, ongoing development of the product.

Adding features that aren’t self-serve messes up the product delivery model. Building or implementing technologies in a way that makes change too expensive also breaks the product delivery model. Things you need to know to be effective as a platform engineer working with the engineering platform product team include:

• Is there actual Technical Product Ownership of the Platform?
• Is the experience of using the platform being targeted to the customer or merely to meet stakeholder concerns?
• Are the architecture and engineering practices optimized for building a product?
• Is the platform being delivered in rapid incremental steps, starting from a minimum valuable set of capabilities?

Figure 2.1 shows the relationship between various entities while establishing the platform product ownership. A Technical Product team, led by a Product Owner, delivers unique capabilities, focuses on the relevance of the product capabilities for the skilled technologists, and adapts feedback approaches for internal users.

A true product team takes full ownership of what it delivers. It’s the only team in the organization providing a specific set of capabilities, and it’s led by a Product Owner who has the responsibility and authority to set the team’s product roadmap.

The product owner is often called a Technical Product Owner (TPO) for an Engineering Platform. This can be a helpful distinction as it clarifies within the organization that an engineering product’s users are skilled technologists with very different needs and expectations from general consumer products. The users are internal, with different approaches needed for developing effective feedback loops. However, many of the fundamental activities remain the same regardless of the complexity or technical nature of the product.

They are the voice of the customer. They deeply understand why customers use the product and what provides value. You might want to think of the customers in this scenario as your end-users.
They find ways of meeting stakeholder needs without impairing the customer experience.

They are responsible to know and understand where the marketplace is heading. They prioritize the backlog, deciding on the order of release for platform capabilities, engineering improvements, or the refactoring of Platform technical debt.

They change the product roadmap when observations of actual usage or customer experiences indicate the expected value is not obtained.

Most organizations initially misunderstand the importance of the TPO role and assume traditional IT processes can be used to deliver an engineering platform product.

This assumption is destined to fail. Whether you are shipping skateboards or an engineering platform, a lack of actual, empowered product ownership will produce a product far different from the initial vision with significantly reduced value.

In the next blog, we’ll discuss customers vs stakeholders and how an engineering platform will achieve its potential when everyone involved agrees on how we think about and deliver products.