Chapter 2: Software-defined products and architectures

Introduction

This introduction argues that successful platform products need an organization capable of product delivery, architectures designed to evolve, and software-defined engineering practices.

• Organization for product delivery: Explain why adopting platform engineering practices also requires attention to organizational structure, decision-making, and culture, and how to judge whether responsibilities support internal product delivery.
  Why it matters: A platform team’s ability to deliver a product depends on how the organization lets it work and make decisions.
• Evolvable internal product architecture: Explain why evolution must be visible in the architecture of a long-lasting internal product, and describe the section’s test for maintainable domain boundaries.
  Why it matters: A platform product must remain useful as needs and implementation choices change.
• Software-defined platform product: Describe what it means here for the entire engineering platform product to be software-defined and why that matters for maintaining its experience through change.
  Why it matters: Treating the whole platform as software supports consistent delivery and maintenance as it changes.

Key terms: organizational structures, decision-making habits, engineering culture, product delivery model, internal products, evolution, architecture, domain boundary, software-defined, versioned source control

2.1 Product delivery model

This section contrasts one-off technology projects with a product delivery model centered on an engineering platform’s evolving, self-serve developer experience.

• Project versus product delivery: Distinguish a one-off approach to acquiring infrastructure and tools from a product delivery model that continually improves the experience customers use and value.
  Why it matters: It shifts attention from completing a technology purchase to continually improving what developers can actually use.
• Engineering platform self-service: Explain what the section means by an engineering platform’s self-serve experience and why self-serve does not mean developers must handle everything themselves.
  Why it matters: The platform’s value is an easy developer experience that does not discard the organization’s requirements.
• Product delivery readiness: Describe the questions the section suggests asking to judge whether an organization is set up to deliver its platform as a product.
  Why it matters: These questions make the difference between calling a platform a product and organizing to deliver one visible.

Key terms: one-off project, product delivery model, user experience, self-serve, engineering platform, self-serve experience, engineering friction and delays, quality, security, and organizational compliance requirement, technical product ownership, product experience

2.1.1 Technical product ownership

This section explains why an engineering platform needs an empowered technical product owner and what that owner does to keep the product valuable to its internal users.

• Empowered internal product ownership: Explain why an internal engineering platform needs an empowered, accountable product owner rather than being delivered through traditional IT processes.
  Why it matters: Funding a platform is not enough if no one has the authority and accountability to guide it as a product.
• Technical owner and users: Describe why an engineering platform’s product owner may be called a technical product owner and how that role represents its users.
  Why it matters: The owner cannot represent platform users effectively without understanding their particular needs and what they value.
• Roadmap and backlog decisions: Explain how the TPO directs platform work and responds when actual usage or customer experience shows that expected value has not been achieved.
  Why it matters: Roadmap authority lets the TPO adjust platform work when its real-world value differs from expectations.

Key terms: internal product, product owner, traditional IT processes, technical product owner, TPO, voice of the customer, end-users, product roadmap, backlog, stakeholder needs

2.1.2 Customers vs. stakeholders

This section distinguishes platform customers from stakeholders, explains how stakeholders can support self-service delivery without dictating implementation, and uses a stakeholder map to surface delivery risks.

• Customer needs and prioritization: Distinguish customers who use the engineering platform from stakeholders who influence it, and explain why feature priorities should reflect customer use and value.
  Why it matters: Separating users from influencers helps the team prioritize a platform people will actually use.
• Stakeholder outcomes versus control: Explain why stakeholders' legitimate requirements should not give them control over platform implementation, and why retaining legacy silos behind a platform wrapper is insufficient.
  Why it matters: The platform can meet enterprise needs without inheriting processes that make it frustrating to use.
• Self-service stakeholder requirements: Describe the two ways stakeholders can make their capabilities or requirements available to platform teams, including how outcome standards allow another team to implement the service.
  Why it matters: These two routes let teams meet stakeholder requirements without waiting on tickets or imposing high-friction customer experiences.
• Stakeholder map and delivery risk: Describe how to use a stakeholder map to identify and address risks to the platform vision.
  Why it matters: Spotting misalignment early gives the team a chance to resolve constraints before they erode the platform's value.

Key terms: customers, stakeholders, internal customers, product thinking, product delivery, legacy silos, service interface, API, self-serve, well-defined outcome standards

2.1.3 Optimize for a product

The section argues that an engineering platform should be optimized for end-to-end product delivery, built around API-first capabilities, and shaped by real customer use before architectural commitments are finalized.

• End-to-end product delivery: Explain why platform effectiveness should be assessed across the full process of building, delivering, and operating software rather than within individual organizational functions.
  Why it matters: It keeps platform improvements focused on teams’ actual ability to deliver products, not just on local efficiency.
• API-first platform capabilities: Describe how platform features should be delivered as service interfaces first, even when developers also use CLIs or UIs.
  Why it matters: It lets the platform offer different user touchpoints without making any one of them the core capability.
• Evidence-based architecture commitments: Explain when to make final platform architecture or technology decisions and what customer evidence should inform them.
  Why it matters: Testing with real users helps avoid committing to expensive capabilities based on guessed requirements.

Key terms: end-to-end engineering effectiveness, developer activity model, functional silos, domain-focused development teams, service interfaces, APIs, CLIs, UIs, user touchpoints, commitment

2.1.4 The importance of a minimal valuable product and early adopters

The section explains how to start an engineering platform with a small, valuable offering, test it with early adopters, and expand its capabilities and delivery teams without losing a unified product vision.

• Evidence-led platform MVP: Explain how early adopters help determine whether an initial platform offering is valuable and what to build next. Describe why each added capability should be tested before full implementation.
  Why it matters: Testing value early helps the team avoid spending months on capabilities developers barely use.
• Unified ownership as teams grow: Describe why platform delivery can begin with one team and how ownership should remain unified if dedicated teams emerge.
  Why it matters: The platform can gain delivery capacity without becoming a collection of disconnected products.

Key terms: minimal valuable product, MVP, early adopters, proof-of-concept, single team, unified product (and architectural) roadmap, TPO, subdomain product owner

2.2 Software-defined platform

This section frames platform engineering as software engineering, warns against carrying manual operations habits into platform work, and recommends shared standards and dogfooding.

• Software engineering for platforms: Explain why building a software-defined platform requires treating the infrastructure lifecycle like software development rather than relying on manual operations habits.
  Why it matters: This distinction helps a team avoid automating old manual habits without changing how it develops the platform.
• Shared team engineering standards: Describe how an agreed team document helps establish consistent engineering practices and onboard new platform team members.
  Why it matters: Shared standards make the intended engineering approach easier to follow as the team grows.
• Platform team dogfooding: Explain what dogfooding means for the platform team and which development practices it should use.
  Why it matters: Using the platform's intended development approach keeps the team's own work aligned with what it offers users.

Key terms: software-defined, infrastructure lifecycle, anti-pattern, team charter, standards, dogfooding, supporting development tools and technologies

2.2.1 The platform software delivery lifecycle

This section defines a repeatable, automated platform delivery lifecycle that plans and tests changes, releases them through a fixed path, and uses production feedback to improve the platform.

• Incremental planning and design: Explain how planning and design prepare platform changes for incremental delivery and how experiments can test the value of a new capability.
  Why it matters: Small, measurable changes let the team learn before committing to a large implementation.
• Tests before implementation: Justify writing automated tests before the main code development begins.
  Why it matters: Test-first work can expose a mistaken interpretation of the task before it shapes the implementation.
• Automated build and release path: Trace how a platform change moves through testing environments and into production while preserving a consistent deployment workflow.
  Why it matters: A consistent pipeline makes the change tested along the release path the change that reaches production.
• Observation and operational learning: Distinguish observing a new change from the platform team's continuing responsibility to operate and improve what it deploys.
  Why it matters: Delivery continues after release: the team must see the change's effects and improve the running platform.
• Observability configuration as code: Explain when dashboards, monitors, and alerts should be configured for a platform change and how that work fits its definition of done.
  Why it matters: A change needs its observability in place when the team starts assessing its effects.

Key terms: platform roadmap, acceptance criteria, experiments, incremental change, automated tests, confirmation bias, automated pipeline, commit SHA or tag, release candidate, preview testing environment

2.2.2 Observability-driven development

This section explains how observability-driven development makes evidence of a platform feature’s behavior and value part of its design and acceptance criteria.

• Observability as acceptance criteria: Explain how observability-driven development (ODD) extends testing by requiring the data and alerting needed to understand what new platform software is doing, whether it works as expected, and whether it delivers value.
  Why it matters: Building in observability makes it easier to verify a feature after release and diagnose unexpected behavior.
• Throttling control observability: Describe what data and checks the section calls for when designing the example traffic-throttling control, and how that data would help expose an incorrect throttle.
  Why it matters: A control can pass its trigger test yet still block the wrong traffic; contextual events make that mistake visible.
• Deployment change event logs: Explain why the section says every platform deployment pipeline should log change events.
  Why it matters: Change records give engineers a concrete place to start when behavior shifts after a deployment.

Key terms: observability-driven development, ODD, acceptance criterion, observability data, throttling events, internal source, acceptance criteria, alerting, event logs, deployment pipeline

2.3 Evolutionary platform architecture

This section explains why platform architecture must remain flexible as needs and available technologies change.

• Evolutionary design decisions: Explain why choices about platform tools and infrastructure should account for future change rather than assume today’s reasons for choosing them will remain valid.
  Why it matters: A choice that fits today may become costly to keep when the platform’s needs or available tools change.

Key terms: evolutionary flexibility, architectural requirements, design choices

2.3.1 Backlog management for incremental design

This section shows how to turn platform feature requests into incremental changes by testing assumptions, defining the valuable capability, and measuring whether it delivers enough value to sustain.

• Evidence-led backlog decisions: Explain why platform teams should capture ideas without turning them into an exhaustive, fixed feature plan, and should test the assumptions behind requests against actual user needs.
  Why it matters: Testing an idea before committing to it helps the platform evolve around real demand rather than plausible-sounding assumptions.
• Value-based feature boundaries: Describe how to frame a request around the larger capability that delivers value rather than treating one interface or requirement as an isolated feature.
  Why it matters: The boundary chosen for a feature changes whether its costs and benefits can be judged fairly.
• Measured feature value: Explain how the team would use data to estimate a proposed change’s value and compare the delivered result with that estimate, using the repository-integration GUI as an example.
  Why it matters: A usable interface is not proof of value unless people adopt it and it produces the expected benefit.
• Ongoing feature economics: Justify keeping or removing a feature by comparing its actual benefit with implementation and ongoing operation costs.
  Why it matters: A feature’s continuing cost makes low use and disappointing outcomes important even after it has been built.

Key terms: backlog, epics, minimum viable usability, proving value, feature, modeling scope, nonfunctional requirement, graphical interface, model the opportunity, define

2.3.2 Capturing user, stakeholder, and market feedback

This section explains how a platform product team gathers ideas from several sources and evaluates them as shared product capabilities rather than treating them as individual service tickets.

• Shared capabilities versus tickets: Distinguish platform feature requests from traditional infrastructure tickets: the platform team builds capabilities for development teams broadly rather than committing to fulfill each team's request.
  Why it matters: This distinction prevents an idea queue from becoming another ticket queue with an implied promise of delivery.
• Sources and qualification of ideas: Describe the main sources of platform ideas and explain what must happen before an idea moves into delivery.
  Why it matters: Looking beyond past tickets helps the team find opportunities without assuming every idea is ready to build.
• Observed use and outside learning: Explain why feedback on existing capabilities includes observing actual usage, and describe how the wider platform community can contribute ideas.
  Why it matters: What people actually do and what others have tried can reveal improvements that direct requests alone miss.

Key terms: product requests, capabilities, platform idea queue, Feature Request board, legacy work queues, stakeholders, industry trends, developers, platform usage, value flow

2.3.3 Architectural fitness functions

The section shows how database abstractions and architectural fitness functions can make platform changes safer and more predictable.

• Database abstraction for portability: Explain how the service, repository, and datastore layers let a platform API change supported database technology or cloud provider without rewriting its service logic.
  Why it matters: The abstraction gives the platform a way to change database implementations without making every API change its business logic.
• Architectural fitness function checks: Describe what the proposed fitness functions check and how those checks help preserve the database abstraction as the platform evolves.
  Why it matters: These checks make an architectural decision testable, helping teams spot violations before a database change undermines the intended separation.

Key terms: repository pattern, repository layer, datastore layer, datastore interface, service layer, architectural fitness functions, standard datastore interface, contract tests

2.3.4 Domain-driven platform design

This section uses domain boundaries and self-service experiences to guide platform decisions, illustrated by a cost-control ADR and an exception for rarely used capabilities.

• Domain boundaries and self-service: Explain how a platform domain boundary is defined by the consumer’s experience and how it helps identify an effective domain for a team.
  Why it matters: The boundary makes independent use and delivery a practical test for platform design.
• Real costs of expediency: Explain why platform decisions need a consistent way to assess their effects rather than defaulting to the cheapest immediate solution.
  Why it matters: An apparently inexpensive decision can be costly when it leaves developers waiting or adds recurring work.
• Boundary-focused cost decisions: Describe how the Epetech cost-control example turns a broad cost concern into outcomes and capabilities at platform domain boundaries.
  Why it matters: It shows how to pursue cost efficiency without making the platform harder for teams to use.
• Rare manual capability exceptions: Explain when a rarely used capability might remain manual and why its support should sit outside the platform product delivery team.
  Why it matters: A seemingly small manual exception can quietly consume product-team capacity as the platform scales.

Key terms: domain boundary, domains and subdomains, loosely coupled, self-serve, expediency, real cost, product thinking, ADR, platform user teams, cost efficiency

2.3.5 Evolutionary impact of cloud-native technologies

Explains how cloud-native services and Kubernetes make engineering platforms easier to evolve, while showing why extensibility matters when choosing a control plane.

• API-first capability sourcing: Explain why the section favors accessing platform capabilities through cloud-vendor APIs and considering vendor-supported offerings before operating them yourself.
  Why it matters: Choosing how to source a capability determines how much effort remains available to improve the platform product.
• Kubernetes control plane standardization: Describe what Kubernetes standardizes for an engineering platform and how its basic cluster components support running applications.
  Why it matters: A standard control plane gives platform teams a common foundation for running and extending services.
• Governance through extensible APIs: Explain how Kubernetes extensions can apply organization-specific capabilities and checks to deployed services.
  Why it matters: Extensibility makes shared platform requirements enforceable without placing every implementation task on developers.
• Serverless control plane tradeoff: Distinguish the convenience of serverless deployment from the governed extensibility available with managed Kubernetes, and explain the consequence for platform requirements.
  Why it matters: An easy deployment path does not remove the need to meet observability, compliance, and quality requirements.

Key terms: API-first, cloud native, total cost of ownership, opportunity costs, Kubernetes, control plane, worker nodes, orchestration, APIs, mutating admission controller API

2.4 Summary