Lab: RCAR Analysis for VCF 9.0 Migration

VCF 9.0Intermediatevcdx-distinguished⏱ 120 min

Objectives

Document RCAR for customer VCF 4.5 → VCF 9.0 upgrade (brownfield).

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for VCDX Defense Preparation

Tasks

Task 1 Lab: RCAR Analysis for VCF 9.0 Migration

Document RCAR for customer VCF 4.5 → VCF 9.0 upgrade (brownfield).

Step 1

Define 5+ Requirements (functional, non-functional, business): Uptime SLA, performance targets, feature adoption, cost reduction targets.

Step 2

Document 5+ Constraints: Budget, timeline, existing infrastructure (vSAN version, NSX version), staffing, regulatory.

Step 3

List 5+ Assumptions: Vendor support availability, network stability, skill ramp-up timeline, customer commitment, risk appetite.

Step 4

Identify 5+ Risks: Upgrade failure (rollback scenario), performance regression post-upgrade, compatibility issues (custom vSAN policies), schedule slip, budget overrun.

Step 5

For each Risk, document: likelihood (high/medium/low), impact (high/medium/low), mitigation strategy, residual risk.

Step 6

Create decision traceability: For each requirement, trace to design decisions + constraints. Example: REQ-001 (support 5000 VMs) → chose 3-node vSAN cluster with FTT=2 (constraint: CapEx budget) → risk (single node failure reduces throughput).

Step 7

Write 2-3 panelist Q&A scenarios: "What if requirement X changes?" or "What if constraint Y is violated?"

Step 8

Submit as structured document: RCAR matrix (table format) + narrative (2-3 pages per major RCAR item).

Validation Gate

Check: Verify lab completion

Expected: Lab exercise completed successfully

Common Errors

Requirements written as solutions instead of business needs

Fix: BAD: 'Deploy vSAN with RAID-5'. GOOD: 'Storage must provide 99.99% availability with 60TB usable capacity at <5ms latency for clinical workloads.' Requirements define WHAT is needed; the design defines HOW. Let the requirements drive the technology choice.

Assumptions not documented or validated with the customer

Fix: Every unvalidated assumption is a risk. Document each assumption with: source (who stated it), validation plan (how to confirm), and impact if wrong (what changes in the design). Present assumptions to the customer for sign-off before finalizing the design.

Risk register without mitigation strategies

Fix: A risk without a mitigation is just worry. For each risk: describe the impact (what breaks), probability (likely/unlikely), mitigation (how to prevent), and contingency (what to do if it happens). VCDX panelists specifically look for risk-to-mitigation-to-contingency chains.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

RCAR is THE framework for VCDX defense. Every design decision must trace back to a requirement. Every constraint must be challenged or accepted with justification. Every assumption must be documented. Every risk must have mitigation.

⚠ Known Pitfalls (from Community KB)

Writing requirements as technology choices — this is the most common VCDX design document flaw.

Documenting risks without mitigation or contingency — shows awareness without planning.

Mark complete