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?
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?
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?
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?