Chapter 10: Platform product evolution

Introduction

Introduces platform product evolution by explaining why a platform strategy matters as organizations and their software ecosystems grow more complex.

• Need for platform strategy: Explain why an effective platform strategy becomes important as an organization grows and its software ecosystem becomes more complex, in the context of improving delivery, reliability, and developer experience.
  Why it matters: This is the reason the chapter considers how platform products evolve.

Key terms: platform strategy, developer experience

10.1 Measuring the success of your platform organization

This section explains why measuring progress matters as a platform organization evolves.

• Measurement for platform evolution: Explain why a platform organization should measure its progress after it starts seeing improvements.
  Why it matters: Early improvements alone do not tell you how the platform is progressing or support its next stage of evolution.

Key terms: measure your progress, platform journey

10.1.1 The platform value model

This section explains how a platform value model connects measures of platform use and engineering performance to business outcomes.

• Platform value articulation: Explain how the platform value model connects user adoption, productivity, quality, and business metrics to show value from engineering capabilities through to business outcomes.
  Why it matters: It helps you show not just that a platform is used, but how it contributes to organizational goals.
• Platform improvement indicators: Describe the operational indicators the section suggests tracking over time and how regular analysis helps identify opportunities to improve the platform.
  Why it matters: Tracking these indicators over time helps teams decide where the platform needs improvement.

Key terms: platform value model, user adoption metrics, productivity metrics, quality metrics, business metrics, DORA metrics, waste and friction indicators, product adoption and engagement, buy versus build efficiency gains, system reliability and observability coverage

10.1.2 Epetech’s approach to measurement

Epetech pairs the four DORA outcome metrics with leading indicators to spot delivery and reliability problems early and target platform improvements.

• Leading and lagging metric alignment: Explain why Epetech aligned its platform KPIs with the platform value model and the four DORA metrics, then added leading indicators. Describe how an organization could choose leading metrics and relate them to DORA outcomes.
  Why it matters: Connecting early signals to outcomes makes measurement useful for choosing improvements, not just reporting results.
• Deployment speed indicators: Describe how Epetech used leading indicators to interpret deployment frequency and lead time for changes.
  Why it matters: These indicators help show whether slower delivery stems from deployment practices or a particular pipeline stage.
• Reliability and recovery indicators: Explain how Epetech paired change failure rate and mean time to recovery with earlier signals of quality and incident-response problems.
  Why it matters: Early quality and response signals help teams address reliability problems before or during their effect on users.

Key terms: platform value model, KPIs, DORA, leading metrics, lagging metrics, deployment frequency, lead time for changes, automated deployments, deployment pipeline stages, change failure rate

10.1.3 Implementing feedback loops

Epetech uses surveys, interviews, community forums, and advisory groups to turn developer feedback into platform improvements aligned with user needs and business goals.

• Complementary platform feedback: Explain why Epetech gathers qualitative feedback alongside performance metrics and how regular feedback helps the platform evolve.
  Why it matters: Feedback reveals what platform metrics alone cannot and helps keep improvements relevant to developers.
• Surveys and interview context: Distinguish what Epetech learns from structured surveys and from interviews, and explain why it combines them.
  Why it matters: A score can flag a problem, while a conversation can reveal what is causing it.
• Community forum functions: Describe how Epetech’s community forums support feedback, collaboration, and communication about platform changes.
  Why it matters: A shared forum lets developers help each other while giving the platform team a live view of concerns and requests.
• Cross-functional advisory groups: Explain how Epetech’s advisory groups shape priorities, connect the roadmap to business goals, and support adoption of changes.
  Why it matters: Cross-functional input keeps the roadmap from favoring only the loudest requests and helps teams adopt changes.

Key terms: feedback loops, quantitative metrics, qualitative data, developer experience, surveys, interviews, developer satisfaction scores, usability, community forums, knowledge-sharing

10.2 Platform-as-a-product as the differentiator

This section explains why treating an internal platform as a product means designing it around user problems and value, rather than viewing it as a collection of tools.

• Platform as product mindset: Explain how applying product management principles changes the way a platform is developed and why that can improve adoption and satisfaction.
  Why it matters: Thinking of the platform as a product keeps its development focused on value for the people who use it.

Key terms: platform-as-a-product, user-centric design, continuous improvement, value proposition

10.2.1 Defining the platform vision and mission

Epetech defines a platform vision and mission to give its platform-as-a-product work a coherent direction and a basis for decisions.

• Platform vision and mission: Distinguish Epetech’s platform vision from its mission: the vision describes the long-term effect the platform should have, while the mission states the outcomes through which it will achieve that vision.
  Why it matters: Separating the desired future from the outcomes that support it makes the platform’s purpose easier to communicate.
• Shared direction for platform decisions: Explain why Epetech established a clear vision and mission before developing the platform, and how the team used them to assess work and align stakeholders.
  Why it matters: A shared purpose gives the team and its stakeholders a reason to choose some platform work over other work.

Key terms: platform vision, mission statement, seamless developer experience, platform-as-a-product mindset, vision, mission, stakeholders

10.2.2 Establishing a product roadmap

This section explains how Epetech turned its platform vision and mission into a prioritized, transparent product roadmap.

• Roadmap prioritization criteria: Explain how Epetech used user research, business objectives, and technical feasibility to decide what belonged on its platform roadmap. Describe how a deployment pain point led to prioritizing automated pipelines and self-service infrastructure.
  Why it matters: These criteria help the platform team focus on work that matters to both its users and the business.
• Roadmap stakeholder communication: Describe how the roadmap communicated priorities, timelines, and progress to stakeholders, and why regular reviews mattered. Explain how that transparency affected trust and ad hoc requests.
  Why it matters: A visible, revisited roadmap helps users understand the team's choices and builds trust while keeping work focused.

Key terms: product roadmap, user research, strategic alignment, technical feasibility, communication tool, roadmap reviews, stakeholder expectations, scope creep

10.2.3 Implementing agile practices

Epetech used short delivery cycles, feedback loops, and cross-functional collaboration to evolve its platform in response to users.

• Incremental platform delivery: Explain how Epetech broke its roadmap into short sprints and released a basic deployment-automation MVP before adding more complex features.
  Why it matters: Incremental releases help a platform provide useful capabilities without waiting for a large, potentially outdated release.
• Sprint feedback and adaptation: Describe how reviews, retrospectives, and user feedback helped Epetech change its plans and improve the platform after each sprint.
  Why it matters: Feedback keeps the platform responsive to real-world use and changing requirements.
• Cross-functional platform collaboration: Explain who collaborated on Epetech’s platform team and why bringing those perspectives together mattered.
  Why it matters: A platform needs more than one function’s perspective to serve users while meeting operational and security needs.

Key terms: iterative development cycles, sprints, minimal viable product (MVP), continuous feedback and adaptation, reviews, retrospectives, cross-functional collaboration, stand-ups, planning sessions

10.2.4 The role of the platform product manager

The section explains how Epetech’s platform product manager connected developer needs, stakeholder priorities, and performance metrics to guide the platform.

• Platform product manager responsibilities: Explain how Alex used user research, stakeholder engagement, and metric tracking to guide Epetech’s platform. Describe how these tasks helped align technical implementation with user needs and business objectives.
  Why it matters: The role helps keep platform decisions grounded in developer experience, organizational priorities, and evidence of value.

Key terms: platform product manager, user research, stakeholder engagement, metric tracking, KPIs

10.2.5 Differentiating through user experience

This section shows how a platform-as-a-product approach improves developer experience, using Epetech’s LaunchPad as an example and an exercise for applying the approach.

• Developer experience differentiation: Explain how simplifying infrastructure, providing self-service, and standardizing configurations made Epetech’s platform more useful to developers and operators.
  Why it matters: These are the concrete ways a platform can improve developers’ day-to-day work.
• Platform product evolution: Describe how the five steps presented in this section connect a platform vision to a developer experience that serves users and organizational goals.
  Why it matters: The sequence shows why a good developer experience depends on continuing product decisions, not just a usable interface.
• LaunchPad experience features: Describe how LaunchPad’s templates, pipelines, portal, and documentation supported adoption and faster feature delivery.
  Why it matters: LaunchPad gives concrete examples of what a user-centered internal platform offered.
• User-centered platform exercise: Apply the exercise’s sequence to propose a platform vision and roadmap grounded in user research, then test a proposed feature with a prototype and feedback.
  Why it matters: The exercise turns the section’s user-centered product approach into a plan readers can try.

Key terms: developer experience, cognitive load, self-service capabilities, consistency and compliance, platform vision and mission, product roadmap, iterative MVP-driven implementation, platform product manager, LaunchPad, internal developer platform

10.3 Cultural shift from a traditional operations world

The section explains why Epetech needed a cultural transformation alongside technical changes.

• Need for cultural transformation: Explain how the separation between development and operations contributed to Epetech’s challenges and why technology alone could not resolve them.
  Why it matters: It explains why improving the platform required changing how teams worked together, not just changing technology.

Key terms: cultural and organizational silos, cultural transformation

10.3.1 Embracing DevOps cultural principles

This section explains how Epetech used cross-functional teams, automation, and observability to change its delivery culture and improve software delivery.

• Cross-functional team ownership: Explain how Epetech brought developers, operations, QA, and security into teams that shared responsibility for their services, and why this reduced handoffs and sped up problem resolution.
  Why it matters: Shared ownership addresses the silos and slow handoffs that motivated Epetech’s change.
• Automated CI/CD feedback: Trace how Epetech’s CI/CD pipelines built, tested, and deployed code, and explain how automation improved feedback, consistency, and release speed.
  Why it matters: The pipeline connects faster releases with early feedback rather than simply making deployments faster.
• Infrastructure as code benefits: Explain how defining and managing infrastructure in code helped Epetech provision environments consistently, track changes, and recover or scale more efficiently.
  Why it matters: Repeatable infrastructure changes reduce the inconsistencies and manual effort that slow delivery.
• Proactive system visibility: Describe how Epetech used dashboards, alerts, and request tracing to see system health, detect problems early, and investigate failures.
  Why it matters: Fast delivery is more reliable when teams can promptly see and investigate problems.
• DevOps transformation outcomes: Explain how Epetech linked collaboration, automation, testing, and monitoring to faster delivery, fewer production defects, greater developer satisfaction, and responsiveness to customers.
  Why it matters: The reported outcomes show why Epetech treated DevOps as an organizational change rather than a set of tools.

Key terms: cross-functional teams, shared responsibility, handoffs, CI/CD, continuous integration, continuous deployment, rapid feedback loop, infrastructure-as-code, IaC, configuration drift

10.3.2 Breaking down silos with team topologies

Epetech uses team types and explicit interaction modes to improve delivery, then illustrates their use in an inventory project and offers an exercise for applying them.

• Distinct team responsibilities: Describe the roles of Epetech’s stream-aligned, platform, and enabling teams and how those roles help teams deliver value.
  Why it matters: Distinct responsibilities let domain teams focus on customer value while getting shared services and specialist help.
• Explicit team interaction modes: Distinguish collaboration, X-as-a-service, and facilitation by describing when and how Epetech’s teams use each mode.
  Why it matters: Naming the interaction mode makes it clearer whether teams should work together, consume a service, or seek coaching.
• Inventory tracking team coordination: Trace how Epetech combined the team types and interaction modes to deliver real-time inventory tracking.
  Why it matters: The example shows how the three interaction modes can work together on one delivery challenge.
• Team topology transition exercise: Describe the exercise’s proposed sequence for assessing current team interactions, proposing a new topology, and testing it.
  Why it matters: A pilot and feedback make a proposed team structure something an organization can test and refine.

Key terms: stream-aligned teams, platform team, enabling teams, cognitive load, collaboration, X-as-a-service, facilitation, interaction modes, real-time inventory tracking, messaging system

10.3.3 Effects on Epetech’s culture

This section describes how Epetech’s reorganization affected its culture and provides an exercise for planning and measuring a DevOps-oriented cultural shift.

• Epetech’s cultural outcomes: Explain how Epetech’s reorganization changed communication, team ownership, delivery, and morale.
  Why it matters: Epetech’s example connects changes in how teams work to both employee experience and delivery outcomes.
• Cultural shift planning exercise: Describe how the exercise proposes planning and evaluating a shift from traditional operations toward DevOps collaboration.
  Why it matters: The exercise turns a cultural aspiration into a change that teams can pilot, gather feedback on, and evaluate.

Key terms: stream-aligned teams, autonomy, ownership, handoffs, process flow diagrams, feedback loops, CI/CD pipelines, post-implementation metrics

10.4 Site reliability engineering strategy, models, and aligning with organizational needs

Introduces why Epetech turned to site reliability engineering as its engineering platform increased delivery velocity.

• Reliability and engineering velocity: Explain why reliability became more important at Epetech as its engineering platform accelerated engineering velocity, and describe SRE as an engineering-first approach to traditional operations.
  Why it matters: This explains why SRE became relevant to Epetech’s evolving platform.

Key terms: engineering velocity, system reliability, site reliability engineering (SRE), engineering-first approach

10.4.1 Understanding SRE

This section explains how SRE helps Epetech balance faster deployment with reliability through SLOs, SLIs, and error budgets.

• SRE reliability tradeoffs: Explain why Epetech adopted SRE as deployment frequency increased, and distinguish the roles of SLOs, SLIs, and error budgets in balancing change with reliability.
  Why it matters: These concepts give teams a shared way to discuss whether faster delivery is affecting the reliability users expect.

Key terms: SRE, service level objectives (SLOs), service level indicators (SLIs), error budgets

10.4.2 Implementing SRE at Epetech

The section describes how Epetech used service objectives, monitoring, and automated remediation to improve reliability without stifling innovation.

• Priority Based Service Objectives: Explain how Epetech set SLOs and SLIs for critical services and used them to guide engineering priorities.
  Why it matters: Clear, priority-based objectives help teams focus reliability work where it matters most.
• Proactive Detection and Recovery: Describe how Epetech combined monitoring, alerting, and automated remediation to improve reliability.
  Why it matters: Detecting issues early and automating routine recovery can reduce their impact on users.

Key terms: SLOs, SLIs, critical services, user needs, business priorities, monitoring and alerting, Prometheus, Grafana, automated remediation, resilience

10.4.3 Aligning SRE with organizational goals

This section explains how Epetech aligned SRE practices with business goals through customer-facing reliability, error-budget decisions, and continuous improvement.

• Reliability and customer outcomes: Explain how high availability and performance supported Epetech’s customer and business goals.
  Why it matters: It connects SRE reliability work to outcomes customers and the business value.
• Error budgets for tradeoffs: Explain how Epetech used error budgets to balance new features against reliability improvements.
  Why it matters: It shows how teams could keep delivering features without treating reliability as an afterthought.
• SLO reviews and improvement: Describe how reviewing performance against SLOs and SLIs supported continuous improvement at Epetech.
  Why it matters: It makes reliability an ongoing learning practice rather than a one-time target.

Key terms: reliability metrics, high availability, optimal performance, error budgets, feature development, reliability improvements, system stability, SLOs, SLIs, continuous improvement

10.4.4 Outcomes of implementing SRE

This section describes how SRE improved Epetech’s service reliability, incident response, and operational decision-making.

• Reliability and recovery outcomes: Explain how SRE reduced incidents at Epetech and helped teams recover faster when incidents did occur.
  Why it matters: SRE improved both the quality of everyday service and Epetech’s ability to handle failures.
• Data-driven operational decisions: Explain how Epetech used SRE metrics to guide decisions and connect reliable service delivery with business objectives.
  Why it matters: The section presents SRE as a way to direct effort toward measurable priorities without sacrificing dependable service.

Key terms: proactively monitoring, recovery processes, automated rollbacks, self-healing mechanisms, metrics, performance data, KPIs, data-driven decision-making

10.5 Using intelligent assistants to help enhance engineering platforms

This section introduces intelligent assistants as a way to enhance engineering platforms, using EpetechBot’s reported benefits as an example.

• Intelligent assistant platform benefits: Explain the benefits this section attributes to intelligent assistants, using EpetechBot as the example: greater platform flexibility, less developer cognitive load, and organic growth as business requirements changed.
  Why it matters: It connects the use of assistants to platform adaptability and developers’ day-to-day experience.

Key terms: intelligent assistants, AI-driven automation, EpetechBot, platform flexibility, cognitive load

10.5.1 The role of intelligent assistants

This section explains three ways AI can improve engineering platforms: automating routine work, drawing insights from data, and helping teams interact with tools.

• Routine work automation: Explain how generative and agentic AI can automate routine platform tasks, reducing manual effort and errors while giving teams more time for complex work.
  Why it matters: This is a central reason the section gives for adding AI to an engineering platform.
• Data-driven platform insights: Describe how AI analysis of large amounts of data can produce recommendations and reveal patterns that help teams improve their work.
  Why it matters: The section presents insights, not just task automation, as a source of platform value.
• Team and tool interfaces: Explain how intelligent assistants can help teams communicate and access tools and resources.
  Why it matters: This explains the assistant-specific role highlighted by the section.

Key terms: generative and agentic AI, automated testing and deployment pipelines, AI-driven insights, recommendations, intelligent assistants, interfaces between teams and tools

10.5.2 Epetech’s EpetechBot

This section describes how EpetechBot supports developers through platform-integrated assistance and the benefits Epetech attributes to it.

• EpetechBot platform capabilities: Describe how EpetechBot helps developers deploy, respond to problems, find platform guidance, and improve code.
  Why it matters: These capabilities show what the assistant contributes to developers’ everyday work on the platform.
• Developer and team benefits: Explain how EpetechBot’s assistance improved efficiency, application quality, and learning within Epetech.
  Why it matters: The value of the bot lies not just in its features but in the time, quality, and learning gains they support.

Key terms: EpetechBot, deployment assistance, monitoring alerts, knowledge base access, code analysis, increased efficiency, improved quality, onboarding, continuous skill development

10.5.3 Exploring advanced tools

This section describes how three advanced tools can simplify Epetech’s platform and gives an exercise for integrating an intelligent assistant.

• Crossplane resource orchestration: Explain how Crossplane lets Epetech define infrastructure requirements as code and manage resources consistently across cloud and on-premises environments.
  Why it matters: A shared way to define resources reduces manual work when the platform spans different environments.
• CNOE environment standardization: Explain why Epetech explored a cloud native operating environment and what standardization would do for application deployment.
  Why it matters: Standardization lets a platform offer developers a more consistent experience without tying the organization to one provider.
• Humanitec self-service orchestration: Describe how Humanitec could help Epetech provide developers with a flexible, self-service internal developer platform.
  Why it matters: Orchestration can give developers self-service access without making them handle every infrastructure detail.
• Intelligent assistant integration exercise: Describe the exercise’s recommended path from selecting assistant use cases to delivering and assessing an integrated MVP.
  Why it matters: The exercise turns the idea of an intelligent assistant into a scoped, testable integration project.

Key terms: Crossplane, declarative API, infrastructure requirements as code, unified configuration, cloud native operating environment, CNOE, portability, vendor lock-in, cognitive load, Humanitec

10.6 Comparing IDPs and developer portals

Introduces the distinct roles of IDPs and developer portals and explains why organizations often integrate them.

• IDP and portal roles: Distinguish an IDP’s focus on self-service operations from a developer portal’s focus on finding and understanding platform capabilities.
  Why it matters: The distinction helps you avoid treating two complementary components as interchangeable.
• Value of combining components: Explain why organizations such as Epetech integrate IDPs and developer portals.
  Why it matters: Integration can make the platform easier for developers to work with without erasing the components’ distinct roles.

Key terms: IDPs, developer portals, self-serve deployments, discoverability, unified interface, context switching, collaboration

10.6.1 Understanding IDPs

This section explains how internal developer platforms (IDPs) simplify development and deployment, and how their scope differs from that of broader engineering platforms.

• IDP self-service abstraction: Explain how an IDP lets developers manage applications and environments without handling the intricacies of the underlying infrastructure.
  Why it matters: This is the central way an IDP reduces developers’ dependence on other teams and infrastructure details.
• Standardized automated workflows: Describe how IDP templates, policies, and automation simplify development and deployment workflows.
  Why it matters: Self-service remains useful at scale when routine work is also consistent and automated.
• IDP and engineering platform scope: Distinguish an IDP’s focus on infrastructure abstraction and self-service development and deployment from an engineering platform’s broader software-lifecycle scope.
  Why it matters: The scope distinction prevents treating an IDP as a complete description of every engineering-platform capability.

Key terms: IDP, self-service, layer of abstraction, templates, policies, CI/CD integration, automated provisioning, engineering platform, software development lifecycle

10.6.2 Understanding developer portals

This section explains how developer portals give developers a central place to find resources and how integrations can extend the portal as organizational needs grow.

• Centralized developer resources: Explain how a developer portal brings documentation, APIs, services, and tooling into a discoverable hub that helps developers find and use internal resources, share knowledge, and collaborate.
  Why it matters: This is the main benefit the section attributes to developer portals.
• Extensible portal functionality: Describe how plugin ecosystems and integrations let organizations extend a developer portal and adapt it as their needs grow.
  Why it matters: A portal can evolve with an organization rather than remain a fixed collection of resources.

Key terms: developer portals, discoverability, documentation and knowledge sharing, developer experience, plugin ecosystems, integrations

10.6.3 Comparing and contrasting IDPs and developer portals

This section distinguishes internal developer platforms from developer portals, shows why integrating them improves developer experience, and proposes an exercise for planning and testing that integration.

• IDP and portal roles: Distinguish an internal developer platform from a developer portal by describing their respective backend and frontend roles.
  Why it matters: Keeping their roles distinct makes it easier to see why a team might use both.
• Benefits of integrated systems: Explain how Epetech’s integration of its LaunchPad IDP with a developer portal improved developers’ access to resources, collaboration, and workflows.
  Why it matters: The Epetech example connects integration to concrete improvements in developers’ day-to-day work.
• Integration exercise approach: Describe the exercise’s approach to investigating an IDP–portal integration, from comparing existing capabilities and finding gaps to prototyping an integration and gathering developer feedback.
  Why it matters: Testing an integration against current tools and developer feedback makes the proposed plan more grounded.

Key terms: internal developer platforms, developer portals, backend, frontend, LaunchPad IDP, developer portal, unified interface, context switching, cognitive load, gaps and overlaps

10.7 Outcomes from building the platform products

Introduces a forthcoming discussion of the engineering and business benefits of Epetech’s platform journey.

10.7.1 Key takeaways from Epetech’s journey

Epetech’s journey illustrates six ways a platform organization improved developer experience, delivery, and reliability.

• Platform as a product mindset: Explain how treating Epetech’s platform as a product shaped its priorities and improved developer satisfaction.
  Why it matters: A platform earns adoption by solving its users’ problems, not merely by providing tools.
• Metrics guiding platform investment: Describe how Epetech used measurements to assess its platform and direct improvement efforts.
  Why it matters: Measurements help the team distinguish valuable platform improvements from assumed ones.
• Cultural change across teams: Explain why Epetech changed how teams worked together as well as changing technology.
  Why it matters: Better tools cannot remove friction when teams remain isolated from one another.
• SRE reliability tradeoffs: Describe how Epetech used SRE practices to balance new features with dependable service.
  Why it matters: Reliability becomes part of delivery decisions rather than an afterthought.
• Intelligent tools and automation: Explain how automation and AI-based tools changed Epetech’s delivery work.
  Why it matters: Reducing routine work gives teams more capacity to improve products.
• Integrated developer self-service: Distinguish what Epetech’s IDP and developer portal provided and explain the benefit of combining them.
  Why it matters: Combining actions and information makes the developer experience less fragmented.

Key terms: platform-as-a-product, user-centric design, developer experience, KPIs, lagging and leading metrics, DORA, developer satisfaction scores, DevOps principles, team topologies, cross-functional teams

10.7.2 Benefits realized by Epetech

The section connects Epetech’s platform improvements to faster delivery, greater reliability, better employee retention, and sustained business gains.

• Accelerated time to market: Explain how Epetech’s move from periodic releases to continuous deployment shortened delivery time and helped it respond to customers and market opportunities.
  Why it matters: The business benefit is not just more frequent releases, but a quicker response to customers and opportunities.
• Reliability and customer trust: Describe how SRE practices and improved monitoring affected Epetech’s outages, recovery, costs, and customer relationships.
  Why it matters: Reliability benefits both operations and the lasting customer relationship.
• Developer experience and retention: Explain how better tooling, streamlined processes, self-service, and automation affected developers’ work and employee retention.
  Why it matters: The platform’s effect on day-to-day work also contributes to keeping engineers.
• Platform gains as business outcomes: Explain how Epetech’s delivery, reliability, and developer-experience improvements combined to produce competitive and financial benefits, and why continued evolution matters.
  Why it matters: Epetech judges its platform’s success by lasting outcomes for the whole business, not engineering improvements alone.

Key terms: continuous deployment, lead time, time-to-market, SRE practices, monitoring, service availability, operational resilience, developer experience, self-service capabilities, automation

10.8 Summary