4.1 Anatomy of the New-Service Value Stream
Key Takeaways
The new-service value stream defines an end-to-end operational journey that converts business demand or opportunity into a live, supported service delivering co-created value.
The stream executes across five Service Value Chain (SVC) activities in six steps: Engage, Plan, Design and Transition, Obtain/Build, a second iteration of Design and Transition, and Deliver and Support.
The Design and Transition activity is traversed twice: first to architect solution blueprints and transition plans, and subsequently to test, validate, package, and pilot the constructed solution.
Cross-functional practices—including Service Design, Software Development, Deployment Management, Release Management, and Service Desk—must contribute capabilities across every phase rather than operating in functional silos.
4.1 Anatomy of the New-Service Value Stream
Quick Summary: In ITIL 4 Create, Deliver and Support (CDS), the new-service value stream models the end-to-end journey from an identified opportunity or demand to a live, operational service. Rather than following a rigid waterfall, this stream orchestrates Service Value Chain (SVC) activities—notably executing 'Design and Transition' both before and after 'Obtain/Build'—while integrating over a dozen ITIL management practices to co-create value.
The new-service value stream is the primary operational mechanism for introducing new digital products, major enhancements, or architectural refactoring. ITIL 4 replaces departmental silos with an integrated value stream where business analysts, software developers, and operations engineers align cross-functional capabilities directly with customer outcomes.
The Six-Step Service Value Chain Journey
To transform business demand into an operational service, the stream executes across five Service Value Chain (SVC) activities in six core steps:
- Engage (Demand Capture & Stakeholder Alignment): Triggered by market opportunities, customer needs, or regulatory mandates. Stakeholder engagement uncovers pain points, defines expected outcomes, and aligns high-level expectations. Key practices: Relationship Management, Business Analysis, Service Desk.
- Plan (Feasibility, Architecture & Resource Allocation): Evaluates initiative feasibility against strategic roadmaps and enterprise architecture. Portfolios are prioritized, budgets authorized, and delivery teams allocated. Key practices: Portfolio Management, Service Financial Management, Architecture Management.
- Design and Transition [Initial Pass] (Architecture, UX/CX & Transition Strategy): Translates requirements into service blueprints across the four dimensions of service management. Architects model user journeys, establish utility/warranty specifications, define Service Acceptance Criteria (SAC), and plan transition milestones. Key practices: Service Design, Service Level Management, Information Security Management.
- Obtain/Build (Component Sourcing, Development & Cloud Provisioning): Teams build or procure required technical components. Squads develop custom software, configure COTS/SaaS packages, and provision cloud infrastructure via Infrastructure as Code (IaC). Key practices: Software Development and Management, Supplier Management, Infrastructure Management.
- Design and Transition [Validation Pass] (Testing, Packaging & Pilot Releases): The stream revisits Design and Transition to validate assembled components. Activities include automated regression testing, security scans, SAC verification, release packaging, and pilot trials. Key practices: Service Validation and Testing, Change Enablement, Release Management.
- Deliver and Support (Production Deployment, Hypercare & Operational Handover): Deploys the validated release to production. Telemetry monitoring is activated, Early Life Support (ELS) hypercare triages teething issues, support teams are trained, and operational stewardship transfers to Business-As-Usual (BAU). Key practices: Deployment Management, Incident Management, Service Desk, Event Management.
Value Stream Step-by-Step Breakdown
| Step & SVC Activity | Operational Focus | Key Inputs | Key Outputs | Participating Practices |
|---|---|---|---|---|
| 1. Engage | Capture business need, validate user demand, and establish stakeholder alignment. | Market trends, customer feedback, regulatory mandates. | High-level requirements, business opportunity statement. | Relationship Management, Business Analysis, Service Desk. |
| 2. Plan | Assess strategic viability, allocate budget, and schedule portfolio priorities. | Opportunity statement, enterprise architecture roadmap. | Approved business case, authorized budget, delivery timeline. | Portfolio Management, Service Financial Management, Architecture Management. |
| 3. Design & Transition (Initial) | Blueprint service components, define utility/warranty, model UX, and set SAC. | Validated requirements, architectural constraints, security policies. | Service Design Package (SDP), Service Acceptance Criteria (SAC), transition plan. | Service Design, Service Level Management, Information Security Management. |
| 4. Obtain/Build | Develop software, configure cloud infrastructure, and procure vendor services. | Technical blueprints, API schemas, IaC templates. | Built code artifacts, provisioned cloud environments, vendor APIs. | Software Development and Management, Supplier Management, Infrastructure Management. |
| 5. Design & Transition (Validation) | Execute integration and UAT tests, assemble release packages, and run pilot trials. | Built components, test cases, SAC checklist, pilot user group. | Validated release package, test evidence, pilot feedback, change record. | Service Validation and Testing, Change Enablement, Release Management. |
| 6. Deliver & Support | Deploy to production, manage hypercare (ELS), and complete operational handover. | Validated release package, operational runbooks, support rosters. | Live operational service, updated CMDB, trained support staff, signed BAU handover. | Deployment Management, Incident Management, Service Desk, Event Management. |
Enterprise Scenario: Apex Global Bank Mobile Remittance
Apex Global Bank modernized its cross-border remittances after analytics revealed a 42% cart-abandonment rate caused by multi-day settlement delays and opaque exchange fees.
- Engage & Plan: Business analysts interviewed retail customers and commercial partners, while the digital banking portfolio committee approved a $1.2M budget for instant international transfers adhering to ISO 20022 messaging standards.
- Design & Transition (Pass 1): Solutions architects designed event-driven microservices on AWS, while UX researchers mapped a three-step mobile transfer flow. The Service Desk Manager co-authored Service Acceptance Criteria (SAC) requiring automated transaction tracing via Correlation IDs, runbooks for failed interbank settlements, and support training.
- Obtain/Build: Engineers developed Go payment microservices and deployed Kafka clusters using Terraform. Simultaneously, Supplier Management integrated partner clearinghouse APIs.
- Design & Transition (Pass 2): Automated pipelines ran 1,200 unit and security tests. A pilot trial with 500 internal bank employees uncovered an unhandled gateway timeout, prompting engineers to add graceful retry logic. Change Enablement approved the release upon validating 100% SAC compliance.
- Deliver & Support: The service was deployed via canary rollout (5% initial traffic). A cross-functional Hypercare team monitored transaction telemetry for 14 days before formally transferring operational maintenance to the 24/7 service desk.
CDS Exam Traps & Practitioner Pitfalls
Warning
Exam Trap: The Linear Waterfall Fallacy
Many candidates mistakenly assume that Service Value Chain activities follow a strict, one-pass waterfall. On the CDS exam, remember that Design and Transition is executed twice: first to architect and plan, and subsequently to test, validate, and package.
Note
Exam Trap: Deferring Support Readiness to Handover
CDS scenarios often tempt candidates to involve support teams only during Deliver and Support. In ITIL 4, operational supportability must be established during Step 3 (Design and Transition) through Service Acceptance Criteria (SAC) and runbook co-authoring.
What is the primary reason why the Service Value Chain activity 'Design and Transition' appears multiple times within the standard new-service value stream?
The initial occurrence establishes the service architecture, blueprints, and transition plans, while the subsequent occurrence validates, tests, packages, and pilots the built solution prior to live release.
The first occurrence is reserved exclusively for hardware procurement, while the second occurrence manages software licensing and financial accounting.
It reflects a mandatory waterfall gate requiring executive project sponsors to re-authorize funding before software development begins.
ITIL 4 requires separate Design and Transition activities for internal staff and third-party outsourced vendors.
In an enterprise rolling out a new mobile payment service, which combination of inputs and outputs characterizes the initial 'Engage' activity of the new-service value stream?
Inputs: Compiled code artifacts; Outputs: Approved production change ticket
Inputs: Customer demand, stakeholder feedback, and market opportunities; Outputs: High-level requirements and validated stakeholder expectations
Inputs: Infrastructure runbooks and monitoring thresholds; Outputs: Service Acceptance Criteria sign-off
Inputs: Vendor SLA penalty reports; Outputs: Sourced commercial off-the-shelf software packages
During the creation of a new digital banking product, which practice primarily collaborates with Service Design during the initial 'Design and Transition' activity to ensure operational supportability?
Portfolio Management, by terminating low-performing legacy applications to fund new initiatives
Supplier Management, by negotiating multi-year enterprise volume license agreements
Service Desk and Incident Management, by defining Service Acceptance Criteria (SAC), support scripts, and escalation procedures
Problem Management, by conducting blameless post-mortems on live production outages
A financial institution launched a high-profile currency exchange feature, but immediately suffered severe customer churn because the tier-1 service desk was unaware of the new feature's error codes and could not assist users. Which breakdown in the new-service value stream led directly to this failure?
The development team used continuous deployment instead of traditional quarterly waterfall cycles.
Cloud engineers failed to provision secondary data center failover clusters during the Obtain/Build phase.
The enterprise omitted the Engage phase by failing to solicit competitive bids from multiple cloud providers.
Operational handover and support readiness were neglected during the transition into Deliver and Support.
Sections you finish are checked off in the contents.