FC-0 — Physical & Virtual Substrate

Hardware lifecycle management · score 3, gap opinion, DAPM Delegated vSphere Lifecycle Manager (vLCM) combined with OEM Hardware Support Managers (HSMs) provides firmware and driver lifecycle management in lockstep with VCF software updates through SDDC Manager. Dell, HPE, Lenovo, and other major OEMs publish HSMs for VCF — when an HSM is deployed, SDDC Manager can manage firmware updates through the same lifecycle workflow as VCF software component upgrades. The enterprise retains hardware vendor choice but sheds the manual hardware lifecycle burden for primary OEM hardware. The gap from 4: HSM availability varies by OEM — less common hardware vendors may not have published HSMs, requiring separate management surfaces for those nodes. For primary enterprise OEM hardware (Dell, HPE, Lenovo), the vLCM + HSM integration closes the hardware lifecycle gap to the level of the F3=3 anchor. This is an Opinion gap — the enterprise deploys the appropriate OEM HSM through existing VCF mechanisms, not a new capability acquisition.

Substrate heterogeneity · score 3, gap structural, DAPM Retained VCF runs on Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, Cisco UCS, Supermicro, NEC, Fujitsu, and others through the same vSphere control plane. The enterprise retains hardware vendor choice without changing the management plane above it. VCF 9.1 manages AMD Instinct MI350, NVIDIA Blackwell HGX B200/NVLink Switch, and Intel accelerators through unified vGPU profiles, vmclasses, and DRS policies — the broadest multi-accelerator management of any on-prem control plane assessed. The gap from 4: substrate selection is not fully invisible — the developer or operator specifying a GPU workload must select accelerator type through vmclass configuration. Hardware-agnostic intent declaration remains partial. VCF 9.1 GPU breadth (confirmed): HGX B200/B300 and NVLink Switch support, DirectPath I/O for NVIDIA ConnectX-7 and BlueField-3 SuperNICs with Enhanced DirectPath, Enhanced DirectPath for AMD Instinct MI350, and GPUDirect RDMA across multi-host configurations. Multi-accelerator Model Runtime deploys AI models on both AMD and NVIDIA GPUs without application refactoring. This is the broadest multi-accelerator management set of any on-prem control plane assessed — and it is genuine substrate heterogeneity (AMD + NVIDIA + Intel) rather than NVIDIA-only, distinguishing VCF from the predominantly NVIDIA-locked AI stacks of the other assessed vendors.

Substrate portability · score 3, gap structural, DAPM Ceded VCF runs on on-prem hardware AND public cloud substrate via VMware Cloud on AWS, AND distributed/edge environments via VCF Edge — without architectural changes to the control plane. The same vSphere management plane, the same VCF Automation catalog, and the same operational model apply across all substrate types. This is VCF's most distinctive Fourth Cloud claim: the control plane is genuinely substrate-agnostic. The gap from 4: VMware Cloud on AWS and VCF Edge are separate SKUs with some operational differences from on-prem VCF. True architectural unity across all substrate types is present in principle but requires per-deployment configuration in practice.

FC-1 — Distributed Data & Context Fabric

Data location and gravity awareness · score 2, gap closeable, DAPM Retained VCF Operations provides rich infrastructure telemetry — GPU utilization, model metrics, capacity trending — that reflects where workloads are running. vSAN provides storage topology visibility. What VCF does not provide is a unified, programmatically queryable data catalog that tells FC-2C where enterprise data physically lives — which cluster, which storage system, which geographic location — across all data types. A compliance query ('where is all HIPAA-tagged data and can it be accessed from cluster A?') cannot be answered by the VCF control plane without the enterprise assembling that picture from separate storage management tools. The FC-2C query interface for data location is unconfirmed and structurally absent because FC-2C itself does not exist. Roadmap note (not scored): Native vSAN S3 Object Storage is in tech preview in VCF 9.1.x, with GA expected in an upcoming 9.1 patch release. It brings S3-compatible object storage as a third storage type alongside block and file, with multi-tenancy and S3 buckets-as-a-service through VCF Automation. When GA, this closes part of the FC-1 substrate gap — S3 storage for AI workloads would no longer require a separate Dell/HPE/VAST system. Per methodology, tech preview capability is not scored; this is flagged as Vendor roadmap for the FC-1 substrate story.

Governance and compliance metadata · score 2, gap closeable, DAPM Ceded VCF's governance capabilities are real but narrow. MCP Server Governance (9.1) provides agent-tool access governance enforced through vDefend — which user groups can call which MCP tools. Advanced Cyber Compliance (ACC) provides infrastructure compliance posture management. vSAN provides storage-level encryption and access control. What VCF does not provide is enterprise data governance — compliance tagging of relational databases, file classification by data sensitivity, HIPAA tagging of EHR data in VMs, GDPR residency enforcement at the data layer. Traditional data types require separate governance tooling (Collibra, Informatica, or equivalent). The enterprise must acquire, deploy, and integrate a data governance platform to fill this gap. Closeable but material — a new vendor relationship and a significant integration surface.

Retrieval and context services · score 3, gap opinion, DAPM Ceded Private AI Services Vector Database and Data Indexing/Retrieval are included in the VCF subscription — no separate deployment required. VCF 9.1 adds Google Workspace document support alongside existing Microsoft Office, PDF, and CSV support. The retrieval service is platform-native and managed. The gap from 4: backend options are narrower than purpose-built alternatives (Weaviate, Pinecone, VAST InsightEngine), and retrieval depth for enterprise-specific document formats requires configuration of existing platform primitives. No new capability acquisition required — the enterprise configures what VCF already provides. Opinion gap.

Data pipeline and lineage · score 0, gap closeable, DAPM Retained VCF provides no data pipeline or lineage capability for any data type. No ETL, no CDC from operational databases, no streaming pipeline management, no ML pipeline orchestration, no lineage tracking. The enterprise deploys Airflow, Kubeflow, dbt, Apache NiFi, or a commercial integration platform separately. This is the most consistent gap in VCF's FC-1 profile — it has appeared in every VCF assessment without change and reflects a deliberate scope boundary: VCF is an infrastructure control plane, not a data platform. Closeable but high-cost: a full data pipeline and lineage capability requires a platform acquisition (Databricks, Informatica, or equivalent) with significant lifecycle burden.

FC-2A — Infrastructure Orchestration

Workload universality · score 3, gap structural, DAPM Ceded vSphere Supervisor manages VMs, VKS manages Kubernetes containers, and Private AI Services manages AI inference — all from the same control plane with shared resource pools, shared RBAC, and unified vCenter/VCF Operations visibility. A database VM, a microservices container cluster, and a GPU inference workload on the same cluster are all visible and manageable from one console. This is VCF's foundational Fourth Cloud strength and is unmatched among on-prem control plane vendors. The gap from 4: GPU scheduling intelligence sits primarily with NVIDIA GPU Operator and vGPU Manager rather than vSphere-native policy for AI workloads specifically. For traditional workloads (VMs, containers, batch) the unified surface is complete and mature. Structural gap — the GPU scheduling dependency on NVIDIA is universal across all on-prem vendors.

Resource lifecycle automation · score 2, gap structural, DAPM Ceded VCF automates workload lifecycle within the hardware the enterprise already owns. DRS provides automated load balancing across clusters. vSphere HA provides automatic VM recovery from hardware failures. VKS provides Kubernetes cluster scaling within provisioned node capacity. SDDC Manager provides automated patching and upgrades across VCF software components. What VCF cannot do is provision new physical nodes automatically in response to workload demand — scaling out requires procurement, delivery, and rack integration outside the control plane. This is structural: VCF is a software control plane that does not control the physical supply chain. An enterprise running VCF under HPE GreenLake or Dell APEX as-a-service consumption models would score F2=3 because those models pre-stage capacity that the control plane can activate. VCF on customer-owned hardware is F2=2.

Policy and quota enforcement · score 3, gap opinion, DAPM Ceded vSphere Namespaces provide resource quotas and RBAC across VM and container workloads from a single surface. NSX micro-segmentation enforces network policy across all workload types. MCP Server Governance enforces agent-tool access policy for AI workloads. Advanced Cyber Compliance provides continuous compliance enforcement with drift detection and remediation. The coverage across workload types is genuine and consistent. The gap from 4: policy does not propagate automatically across all enforcement layers — network policy in NSX, quota policy in vSphere Namespaces, and agent policy in MCP Server Governance are configured separately even though they share the same underlying governance surface. The enterprise configures enforcement per layer using existing VCF primitives. Opinion gap — no new capability required, but per-layer configuration is the operator's responsibility.

Substrate lifecycle integration · score 3, gap opinion, DAPM Ceded VCF provides strong workload-lifecycle integration with hardware events across all workload types. vSphere maintenance mode automatically drains all workload types — VMs, VKS containers, and AI workloads — from a node before planned maintenance windows with no operator coordination required per workload. vSphere HA detects hardware failures and automatically restarts workloads on healthy nodes across all workload types. DRS continuously rebalances workloads in response to hardware resource changes. vLCM with OEM HSMs integrates firmware update scheduling with workload lifecycle — firmware updates flow through the same SDDC Manager lifecycle plane as software updates, and maintenance mode drains workloads automatically before firmware is applied. The gap from 4: accelerator-specific hardware events (GPU failures, NVLink topology changes) are not fully integrated into VCF's workload scheduling decisions — GPU failure recovery depends on NVIDIA GPU Operator rather than vSphere HA natively. This is an Opinion gap for GPU-specific lifecycle integration — the enterprise configures NVIDIA GPU Operator integration with existing VCF primitives.

Accelerator and GPU management · score 3, gap opinion, DAPM Ceded VCF 9.1 provides strong platform-integrated accelerator management. vGPU profiles and vmclasses deliver multi-tenant GPU isolation with memory strictly partitioned per tenant and zero side-channel risk across GPU framebuffer. Multi-Instance GPU (MIG) isolation is supported for fine-grained GPU partitioning. DRS policies incorporate GPU resource dimensions for automated workload balancing across accelerator capacity. DirectPath I/O for NVIDIA Blackwell HGX B200, NVLink Switch, and AMD MI350 provides high-performance dedicated GPU access. vSphere Namespaces expose GPU resource quotas through the same Kubernetes RBAC surface as CPU and memory quotas — the operator configures GPU capacity through familiar vSphere primitives. The gap from 4: deep GPU scheduling intelligence — which workload gets which GPU tier under dynamic cost, compliance, and performance policy conditions — sits with NVIDIA GPU Operator rather than vSphere-native scheduling logic. This matches the F3=3 anchor: 'strong accelerator management through platform-integrated GPU operator, scheduling intelligence partially held by accelerator vendor.' This is an Opinion gap — the enterprise configures NVIDIA GPU Operator integration through existing VCF Supervisor primitives.

FC-2B — Execution & Runtime

Runtime universality · score 3, gap structural, DAPM Ceded VCF 9.0 introduced VM Service — a Kubernetes-native execution surface for VMs exposed as Custom Resource Definitions (CRDs) through the vSphere Supervisor. VMs and containers are exposed through the same Supervisor/Kubernetes control surface, with VMs represented as Kubernetes custom resources rather than as a separate vCenter-only workflow. A developer deploys a VirtualMachine resource using standard kubectl and Kubernetes YAML manifests, in the same namespace, with the same RBAC, and through the same toolchain as a container workload. VKS adds Kubernetes clusters as a third workload type through the same Supervisor API. Private AI Services Model Runtime adds AI inference as a fourth workload type through a platform-managed service. All four types are managed through the same vSphere Supervisor control plane with shared resource pools, shared quota enforcement through vSphere Namespaces, and unified visibility through VCF Operations. The gap from 4: AI inference workloads through Model Runtime use a different API surface than kubectl — developers call Model Runtime APIs rather than deploying Kubernetes resources. This is the 'some workload types expose substrate-specific interfaces' exception at F3=3, not a reason to score 2. The bimodal concern raised by two other models — that VMs and containers require different toolchains — is resolved by VM Service CRDs in VCF 9.x. That assessment was based on the pre-9.0 vSphere operational model.

Persona abstraction at execution · score 2, gap opinion, DAPM Ceded The primitives for persona separation exist across all major workload types but their depth is uneven. Kubernetes and AI workloads expose strong developer abstraction — Tanzu's intent-based deployment and Model Runtime's API gateway shield developers from substrate details effectively. VM workloads still expose substrate-specific details at the developer layer: vCenter tooling, VMDK selection, network adapter type, datastore placement. Operator visibility is consistently strong across all workload types — vSphere provides full substrate detail with override controls. Security audit surfaces exist through vDefend, ACC, and MCP Server Governance. The gradient definition at F2=2 — 'developer abstraction strong for some types, substrate-exposed for others' — more accurately describes VCF's actual state than the F2=3 anchor. The gap is Opinion: extending consistent developer abstraction to VM workloads uses existing VCF Automation blueprint primitives and does not require new capability acquisition. Note: VCF 9.x improves administrator identity continuity through the VCF Identity Broker, supporting Entra ID, Okta, Active Directory, OpenLDAP, Ping Identity, and generic SAML — this strengthens the administrative persona experience but does not change the workload developer abstraction finding.

Execution lifecycle and observability · score 3, gap mixed, DAPM Ceded VCF Operations provides native cross-workload correlation for VCF-managed workload types — VMs, containers, GPU workloads, and AI service metrics appear in the same VCF Operations dashboard with correlated visibility. VCF Operations for Networks extends this to network telemetry. Fleet management and integrated telemetry provide strong lifecycle primitives across the VMware estate. Live patching in 9.1 reduces maintenance disruption across all workload types. This is partial native correlation — the F3=3 anchor — not an absent correlation layer. The gap from 4: correlation breaks at the boundaries of VCF-managed workloads. Non-VMware services, application-layer telemetry, data governance events, and AI runtime events that originate outside VCF-managed components require cross-platform correlation the enterprise must assemble. For enterprises with existing observability platforms (Datadog, Dynatrace, Splunk): extending correlation to non-VCF telemetry is an Opinion gap — configure existing tools against VCF's OpenTelemetry-compatible telemetry streams. For enterprises without existing observability tooling: the non-VCF correlation gap is Closeable — a material new capability acquisition.

AI inference and agent execution · score 3, gap opinion, DAPM Ceded Private AI Services Model Runtime is a platform-native managed inference service included in the VCF subscription. Multi-tenant isolation through vGPU profiles. API gateway for inference endpoint management. Agent Builder provides platform-native agent construction using Model Runtime models and Vector Database knowledge bases. MCP Server Governance provides agent-tool access control. The remaining gap is breadth and automation depth rather than absent capability: backend options are narrower than hyperscaler AI platforms, inference auto-scaling is less cloud-like, and NVIDIA AI Enterprise remains a load-bearing dependency. Enterprises configure and operate within the Private AI Services model rather than receiving hyperscaler-equivalent managed inference. No new capability acquisition is required to close the gap — the enterprise operates within existing platform primitives and accepts the narrower backend and automation ceiling.

FC-2C — The Reasoning Plane

Autonomous placement reasoning · score 0, gap structural, DAPM Retained Applying the integration vs. coexistence test: VCF 9.1 has no component that makes autonomous placement decisions by consuming live FC-1 metadata simultaneously with FC-2A state. VCF Operations has GPU and model telemetry. MCP Server Governance has agent access policy. vSAN has storage governance metadata. vDefend has security posture. vSphere Supervisor has workload scheduling authority. All of these exist inside the same control plane. None are wired to a placement engine that derives placement from first principles when a new constraint arrives. Applying the workload universality test: there is no unified reasoning plane for VMs, containers, AI inference, and databases. Applying the first-principles derivation test: when a new GDPR residency requirement arrives, an operator must manually update NSX network policy, vSphere DRS affinity rules, and vSAN storage policy independently. The system derives nothing. VCF Intelligent Assist (tech preview) is agentic IT operations automation — it diagnoses and resolves infrastructure issues. This is a sophisticated FC-2A capability, not FC-2C reasoning. Gap ownership is Structural: Broadcom has made no specific product announcement for FC-2C capability with a confirmed timeline. The methodology is explicit — a structural gap becomes a vendor roadmap gap only when a specific product with a confirmed timeline exists. Intention is not a roadmap. The architectural prerequisites are present inside VCF, which means when Broadcom does ship FC-2C the migration cost will be lower than any other on-prem vendor — but the absence of a product announcement requires the Structural classification today.

FC-3 — Application Distribution and Governance

Application catalog and distribution · score 3, gap opinion, DAPM Ceded VCF Automation provides a governed self-service catalog with pre-built AI workload templates, infrastructure blueprints, and Live Application Stack Blueprints for versioned, redeployable application topologies. Tanzu Marketplace provides a curated path to certified middleware, data services, and AI tooling. AI agents and containers are well-covered with platform-native governance. Traditional enterprise applications and middleware are partially covered — VCF Automation can deploy and govern them, but the catalog depth for enterprise middleware (databases, messaging systems, integration platforms) is narrower than OperatorHub on OpenShift. The gap from 4 is Opinion: the enterprise configures VCF Automation catalog entries for additional application types using existing blueprint primitives. No new capability acquisition required.

Application lifecycle governance · score 2, gap mixed, DAPM Ceded VCF provides meaningful lifecycle governance for its primary application types. Kubernetes admission controllers enforce container policy. MCP Server Governance provides agent lifecycle controls including version access and tool authorization. Advanced Cyber Compliance provides infrastructure compliance posture tracking with drift detection. The gap: there is no unified audit trail across all application types. Container audit trails live in Kubernetes audit logs, VM lifecycle events in vCenter, agent governance in MCP Server Governance, and infrastructure compliance in ACC. For enterprises with existing SIEM deployments (Splunk, Microsoft Sentinel): correlating these streams is an Opinion gap — the enterprise configures existing tools against VCF's audit surfaces. For enterprises without SIEM: this is a Closeable gap requiring a material new capability acquisition.

Developer experience and self-service · score 3, gap opinion, DAPM Ceded Tanzu provides strong developer self-service for containerized and AI workloads — developers publish code and receive production-ready deployments with governance applied by the platform. VCF Automation provides self-service infrastructure deployments for VM and AI workload blueprints. Model Runtime provides an API-based inference interface that shields developers from GPU infrastructure details. The gap from 4: traditional enterprise application developers — those deploying ERP extensions, legacy Java applications, or database-backed services — still interact with more substrate-specific tooling than Kubernetes or AI developers do. Extending self-service uniformly to traditional application types uses existing VCF Automation primitives. Opinion gap — configuration activity, not capability acquisition.

AI application and agent distribution · score 3, gap opinion, DAPM Ceded Private AI Services Agent Builder provides platform-native agent construction. MCP Server Governance provides governed distribution of MCP servers with agent tool authorization enforced through vDefend. Tanzu enables developer self-publication of agents and MCP servers to the enterprise via governed marketplace. Model Store provides curated LLM access with RBAC. The gap from 4: prompt injection controls and output audit trails at the platform level require enterprise configuration of existing vDefend and audit primitives rather than being platform-default behaviors. This is an Opinion gap — the primitives exist in vDefend's security enforcement and VCF's audit surfaces; the enterprise configures AI-specific policies using what already exists. Tanzu Platform Agent Foundations (confirmed GA, April 2026) strengthens this position: developers get governed access to models, MCP servers, and marketplace services pre-curated by IT, through a centralized AI gateway controlling tool/model availability, usage, cost, and safety filters. The Tanzu service publisher (Tanzu Platform 10.3) publishes any MCP server to the Cloud Foundry Marketplace as a discoverable, governed service — turning the marketplace into an AI capability distribution channel with Spring Cloud Gateway enforcement and network-policy isolation per published service. This supports the existing score: VCF provides platform-native AI application and agent distribution with governance. The gap from 4 remains the managed-service ceiling — the enterprise operates the Tanzu distribution surface rather than consuming it as a fully managed hyperscaler service.

FC-4 — Integration Fabric

Event fabric and messaging · score 0, gap closeable, DAPM Retained VCF provides no managed event fabric or messaging infrastructure. NSX provides network-level event visibility for security and connectivity purposes — this is not an application-level event bus. There is no schema enforcement, fan-out delivery, event filtering, replay capability, or protocol support (JMS, AMQP, MQTT, STOMP) at the platform level. An enterprise deploying VCF as a Fourth Cloud control plane must acquire and operate a separate messaging platform — Apache Kafka, Red Hat AMQ, AWS EventBridge, or equivalent. This is a Closeable gap but a material one: a full enterprise event fabric is a significant platform acquisition with its own lifecycle burden. Every application integration that requires event-driven connectivity is a point-to-point integration the enterprise builds and maintains independently.

API management and gateway · score 0, gap closeable, DAPM Retained VCF does not ship a full API lifecycle management platform. Avi Load Balancer is a network-layer load balancer — it provides SSL termination, load balancing, and basic rate limiting. These are network-layer gateway functions, not API lifecycle management. Full API management — publication workflow, versioning governance, developer portal, transformation layer, API-level audit trails, and identity propagation from caller to backend — requires a separate platform acquisition. The distinction matters: Avi is a network appliance that can proxy API traffic; an API management platform governs the lifecycle of APIs as first-class assets. VCF provides the former; Fourth Cloud FC-4 F2 requires the latter. Closeable through acquiring an API management platform (Red Hat 3scale, Kong, Apigee, MuleSoft). Enterprises that already own an API management platform can integrate it behind Avi, reducing incremental acquisition cost, but VCF itself does not provide the capability.

Workflow and process orchestration · score 0, gap closeable, DAPM Retained VCF provides no managed workflow orchestration for enterprise business processes. Tanzu provides GitOps-based deployment pipelines — this is infrastructure pipeline automation, not business process orchestration. There is no managed equivalent to Step Functions, Airflow DAGs for business workflows, or BPMN process engines at the platform level. An enterprise deploying VCF for Fourth Cloud must acquire and operate separate workflow orchestration tooling for both traditional business processes (SAP workflow, ServiceNow orchestration integration) and AI agent chains (separate from Tanzu's deployment pipelines). The two workflow concerns — traditional and AI — require separate tooling with no platform-native unification. Closeable but high-cost: each workflow type requires a separate acquisition.

SaaS and enterprise system integration · score 0, gap closeable, DAPM Retained VCF provides no pre-built, maintained connectors to enterprise systems of record. There are no maintained SAP, Salesforce, ServiceNow, Oracle, Workday, or mainframe connectors in VCF. The MCP Server Governance capability in 9.1 provides MCP tool connections to Oracle, Microsoft SQL Server, ServiceNow, GitHub, Slack, and PostgreSQL — but these are AI agent tool connections governed through MCP protocol, not enterprise system integration connectors with lifecycle management, transformation, and lineage. Every system-of-record integration the enterprise needs is a point-to-point connection the enterprise builds and maintains independently using VCF's infrastructure as the deployment substrate. The Townsend Section 2.6 gap lifecycle cost applies to every system connection: initial build, ongoing maintenance as both sides evolve, and lifecycle coordination. For an enterprise with 10 system-of-record connections, this represents $10–20M in 5-year gap lifecycle cost if no integration platform is acquired. Closeable through acquiring an integration platform (Red Hat Camel K, MuleSoft, Boomi) — itself a material investment.

AI-native integration · score 2, gap closeable, DAPM Ceded VCF 9.1 MCP Server Governance (GA) provides RBAC access control over MCP tool connections — which user groups can access which MCP tools across Oracle, Microsoft SQL Server, ServiceNow, GitHub, Slack, and PostgreSQL without building custom connectors — with enforcement through vDefend and Avi Load Balancer. VCF 9.1 additionally ships a centralized Audit Trail in VCF Operations providing a time-sliced, standardized-format view of user activity across all components including VKS, allowing operators to trace the full event chain across the stack. Together these provide two of the three capabilities that define managed MCP access governance: RBAC access control and centralized call-level audit. This clears the same bar as the strongest on-prem peer at this function — access governance with audit is stronger than basic access control (F5=1) and below full managed connection infrastructure (F5=3). Score 2. The remaining gap from 3 is the managed AI integration fabric: no managed MCP tool discovery, no connection lifecycle management, no dynamic semantic routing, and no platform-native agent-to-agent identity propagation. A within-band distinction from the peer at this score: VCF governs access at the group-to-tool level rather than providing per-tool read/write capability filtering — a narrower capability difference, not a full gradient step. Gap ownership Closeable — acquiring a managed AI integration platform (Red Hat Application Foundations with Connectivity Link, or a dedicated MCP gateway) provides the missing managed connection infrastructure. Score corrected from v2.3 F5=1 following VCF 9.1 GA verification: the v2.3 score predated confirmation of the VCF Operations centralized Audit Trail, which is the capability that moves this from access-control-only (1) to access-control-plus-audit (2). This correction also resolves a cross-vendor calibration inconsistency — the comparable on-prem MCP governance peer scored 2 for the same capability class.