2 Software Defined Products and Architectures

This chapter argues that an effective engineering platform is a software-defined product, not a collection of projects or siloed tools. Success depends on reorienting organizational structures, decision-making, and culture around a product delivery model that prioritizes a self-serve developer experience, continuous evolution, and measurable outcomes. Architectures must be explicitly designed for change, and the entire platform—from infrastructure to policies and controls—should be created and maintained from source-controlled artifacts through automated orchestration.

Delivering the platform as a product means establishing empowered Technical Product Ownership, measuring success by developer experience, and distinguishing customers (daily users such as engineers) from stakeholders (influencers like security or finance). Stakeholders should provide either APIs that enable self-service or clear, testable outcome standards—avoiding implementation mandates that erode usability. The chapter promotes end-to-end optimization across the delivery lifecycle, “service interface first” design, and committing to architecture only after real-world experimentation. It emphasizes shipping a minimal valuable product to early adopters, learning from actual usage, and evolving incrementally—often starting with a single team before scaling under a unified roadmap.

As a software product, the platform follows a disciplined SDLC, dogfoods its own capabilities, and treats observability as part of the definition of done via Observability-Driven Development. It advocates value-focused backlog management, data-informed decisions, Domain-Driven Design with clear domain boundaries that enable loose coupling and self-service, and architectural fitness functions to enforce desired patterns and de-risk change. Cloud-native technologies—especially Kubernetes as an extensible, standardized control plane—accelerate experimentation and governance; the text contrasts this with the trade-offs of serverless control planes. Finally, it recommends favoring managed services where possible to reduce opportunity cost and keep the platform adaptable and focused on strategic differentiation.

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