2 Software Defined Products and Architectures

Platform engineering is positioned as the creation of a durable, self-serve internal product that removes friction for software teams while meeting quality, security, and compliance expectations. Success depends as much on organizational design, decision habits, and engineering culture as on technology. The chapter stresses clear differentiation between customers (the developers who use the platform) and stakeholders (influencers such as security, finance, and legal), urging that stakeholder needs be expressed as service interfaces or outcome standards rather than prescribed implementations. Effective domain boundaries, measured through actual internal product usage, and a relentless focus on the developer experience are the primary yardsticks for platform value.

The recommended operating model is product-led: an empowered technical product owner, end-to-end lifecycle optimization from ideation to operations, “service-interface-first” capabilities, and rapid, feedback-driven increments that reach early adopters quickly. Architectural and tooling choices are validated through real experiments before commitments. The platform must be fully software-defined—everything in version control, delivered by automated pipelines—following a disciplined SDLC (plan, design, code, build/test, release, observe, operate). Observability-driven development expands “definition of done” to include instrumentation, dashboards, alerts, and change events so teams can understand behavior, detect regressions, and verify that delivered features create measurable value.

Architecturally, the chapter advocates designing for evolution: API-first patterns, domain-driven platform design, and automated architectural fitness functions that keep coupling in check, protect nonfunctional requirements, and enable portability. Backlog management is value-centric and incremental, informed by real user behavior, stakeholder input framed as outcomes, and market learning. Cloud-native foundations are preferred to reduce undifferentiated heavy lifting; extensible control planes enable policy enforcement, automation, and governance at scale, while serverless trade-offs are weighed when extensibility is limited. Start with a single team and a unified roadmap, expand to domain-aligned teams as demand grows, and preserve self-serve boundaries and cost efficiency throughout.

A Technical Product Owner (TPO, might be referred to as a Product Manager) serves as the voice of the customer, staying deeply connected to what the developers need and their experience in using the solution provided by the platform, while constantly assessing the measurable value being provided.

Internal stakeholders have legitimate concerns. But these outcomes can be achieved without the stakeholders controlling the implementation.

A Stakeholder Map visualizes a stakeholder’s influence over the backlog against their alignment to platform objectives. High-influence stakeholders must be highly aligned for a platform to succeed.

Look at all the activities, from ideation to operations, and assess engineering quality and impacts from organizational or architectural decisions. Yrjö Engeström’s human activity model inspires this Developer Activity model[2].

shows the Progression of an MVP delivery process. A fully functional product does not need to be delivered at the start, but all phases should deliver some incremental value to the customer.

shows the evolutionary path of platform development teams. Often, while an EP starts as an effort driven by a single team, multiple teams spin up over time to handle specific aspects of platform functions, with all development efforts under a top-level product owner.

The software delivery lifecycle (“SDLC”) covers all stages from feature planning through running in production.

With every change you make to the platform, think about the kind of data you will need in order to understand how the new technology, service, or feature is behaving. Alerting from service failure is not enough. When we deploy automatic configuration behavior or control guardrails, even healthy behavior could be interpreted as failure.

New features or changes should go through a Value flow. There will be routine operations and refactoring going on simultaneously, and using this flow will help us stay clear on how our current work fits into the bigger picture.

When we have a DevOps or traditional operations team, developers will be responsible for submitting requests for infrastructure or changes they need. The requests go into the queue.

Ideas, improvements, and sometimes requirements will come from a variety of sources. These four are the most important. And everything needs to successfully make it through the top row of our Value Flow in Figure 2.9, except for production outages…of course.

When a particular service within the API needs to interact with the API database, it calls a Repository function that provides all the normal database methods. The repository function would call the datastore functions for the type of database the API needs to use (relational or unstructured in our case).

Primary domains in an engineering platform. (From chapter 1)

Start by defining the primary boundary experience, which is our platform customers. Then, figure out where the underlying changes or capabilities lay, and when more than one team is involved, does an effective boundary experience exist between them?

The components of a Kubernetes Cluster. Courtesy: https://kubernetes.io/docs/concepts/overview/components/

shows an example of a pod sidecar. This container runs a process alongside the application container to enhance functionality. In this example, a sidecar continuously loads a new secret value from a vault so that the application will always get the latest updates when secrets are requested.

• Successful delivery of a self-serve engineering platform happens through a Product Delivery Model.
• Stakeholders have significantly different success criteria than do customers.
• Shape the experience of using an engineering platform for customers of the platform.
• Stakeholder needs can be met without destroying the customer experience.
• Don’t underestimate the importance of tracking stakeholder impact on platform delivery. It can mean the difference between success and failure for the platform to provide a return on investment.
• Optimize the product team's engineering practices and the organizational support for delivering a product.
• Optimize the engineering process from ideation to platform operation, not around individual teams, technologies, or departments.
• Features and capabilities should be delivered as service interfaces first.
• Make final architecture and technologies decision only after realistic experimentation that measures the expected value.
• Test experiences and implementation with alpha-users early
• Find ways to introduce the fundamental aspects of new features before more complex implementations, using the feedback to influence next steps.
• Try to start with a single engineering platform delivery team, with the initial squad setting the architectural foundations.
• Grow the number of delivery teams within the platform product based on the most needed capabilities.
• Adjacent teams within the organization can provide capabilities to the engineering platform only if they can also provide their service as-a-product and support the product roadmap of the platform.
• The idea of a software-defined platform introduces more rigor into the SDLC process, using software engineering principles to increase the product's stability, scalability, extensibility, and maintainability.
• Observability is an integral part of each story in the product delivery backlog, not something added on afterward.
• Both the healthy and unhealthy behavior of each feature, capability, or technology of the platform should be easily observable.
• Plan for evolutionary change, even in the way you manage the platform product backlog
• Team engineering standards, such as test-driven development, include architecture fitness testing to support easier evolution.

FAQ