There's a particular silence that descends after a VCF Automation deployment goes live. The portal works. VMs provision. The team that built it moves on. And then, six or eight months later, someone asks why the infrastructure team is still managing VM lifecycle manually when there's supposedly an automation platform running.
The answer is almost always the same: the platform was deployed. The automation wasn't. Those are different things, and the gap between them is where most organizations find themselves after a deployment that felt like a success at the time.
The Scaffolding Is Not the Platform
VCF Automation — Aria Automation, vRealize Automation, whatever it's called this quarter — requires a foundation layer before it does anything useful: cloud accounts wired to vCenter, cloud zones defined within those accounts, flavor mappings that translate "small/medium/large" into actual VM sizing parameters, image mappings that point to the right templates in the right compute regions, network and storage profiles that govern where workloads are allowed to land.
This scaffolding is what most deployments actually deliver. It takes real effort to get right, and when it's working, the demo is genuinely compelling. You pick a size, pick an image, click Deploy, and a VM materializes in the correct datacenter on the correct network segment. The project sponsors see it and consider the engagement successful.
What the demo doesn't show is anything that happens to that VM between the moment it provisions and the moment someone eventually deletes it.
Day 2: Where the Operational Value Actually Lives
Day 2 actions are the lifecycle management layer of VCF Automation — the workflows attached to deployments that allow users to resize a VM through the same portal they used to request it, extend a lease, trigger a snapshot via an ITSM request, scale a component up or down, or decommission a deployment cleanly with resource reclamation tracked back to the catalog. When Day 2 is built out correctly, the automation platform manages the workload through its entire life. When it isn't, the platform provisioned the VM and then lost track of it.
I worked with an organization that had been running VCF Automation for fourteen months when I got involved. Solid deployment — 300 VMs provisioned through the catalog, a good template library, request forms with reasonable input validation. The team was proud of it, and reasonably so. Then I asked how decommission was handled.
There was no decommission action on any deployment. Not a broken one — just none. VMs got provisioned through the catalog and then fell out of the platform's management scope the moment they appeared in vCenter. Cleanup happened manually whenever the ops team got around to it. Of the 300 VMs that had been provisioned through the portal, somewhere around 180 were still running. Nobody could tell me with confidence which ones were still needed, because the system that knew about them — VCF Automation — had no record of their current state, and the system that actually had them — vCenter — didn't know they'd come from the catalog in the first place.
That's not an automation success story. That's a VM factory with a nicer front end than a ticket queue.
The decommission workflow is the most visible gap, but it's not the only one. A resize action that runs through an approval chain and documents the resource change. A snapshot workflow that gets triggered from the ITSM system rather than someone logging into vCenter at midnight. A lease expiration that sends a notification and then cleans up the deployment if nobody responds. These are the Day 2 capabilities that turn VCF Automation from a provisioning tool into an infrastructure platform — and they're almost always the scope items that get cut when a deployment runs over schedule or budget.
RBAC: The Governance Model That Defaults to Open
Projects in VCF Automation define the scope of what users can do — which cloud zones they have access to, what resource limits apply to their deployments, which catalog items are available to them. Project roles (Administrator, Member, Viewer) determine what operations each person can perform within that scope. In principle, this is a complete governance model. In practice, most deployments use it as a mechanism for making the initial demo work rather than as a real access control system.
The pattern is consistent enough that I recognize it immediately: everyone involved in standing up the deployment was made a Project Administrator at some point because it was faster than debugging a permission issue during deployment testing. That temporary state never got cleaned up. Now the "project" that was supposed to represent a specific team or business unit contains a mix of people who should be there and people who were added to fix a problem two months ago and were never removed.
The consequence is usually invisible until it isn't. A developer in the wrong group provisions into a production zone because nothing in the platform prevented it. A member deletes a deployment that belongs to another team's application. Resource limits that were supposed to cap consumption per business unit were set to unlimited during initial configuration and never revisited, so the cluster fills up and nobody knows who consumed what until someone runs a report that everyone agrees is probably inaccurate.
- Project membership tied to AD groups, not individuals. Anything else requires manual maintenance as people change roles — and that maintenance doesn't happen. A project whose membership is defined by Active Directory group sync stays accurate automatically.
- Cloud zone access reflecting real business boundaries. A developer team's project should not have access to the production cloud zone. That sounds obvious. It's frequently not enforced because it creates friction during initial testing that nobody fixed afterward.
- Resource limits set before the catalog goes live. Limits configured after the first compliance question arrives are configured under pressure, with incomplete information about what's already running. The conversation is much easier before anyone has provisioned anything in anger.
- Viewer roles for consumers who should only be requesting, not administering. Most users don't need to see the cloud template YAML or modify flavor mappings. Giving them Administrator access because it's simpler is how configuration drift becomes a support problem.
ServiceNow: The Integration That Always Becomes Phase 2
The VCF Automation ServiceNow plugin publishes catalog items from Service Broker directly into the ServiceNow Service Catalog. A user logs into the ServiceNow portal they already use for everything else, requests a VM, the request flows through whatever change approval chain ServiceNow has configured, and VCF Automation provisions the resource on approval. vRO workflows on the backend sync the provisioned CI back into CMDB, link it to the change record, and keep the configuration data current through the VM's lifecycle.
When this works, infrastructure provisioning is governed, auditable, and part of the same service delivery model as everything else IT manages. The security team can find every provisioned resource in CMDB. The change management team can see what was approved and when. Chargeback pulls from a system that actually knows what's running rather than from a quarterly vCenter export that someone normalizes in a spreadsheet.
When it doesn't exist, VCF Automation runs as a parallel portal next to ServiceNow. It's faster to use than opening a ticket, which is exactly why people use it — and exactly why it creates a governance gap. Infrastructure gets provisioned outside the change process. The CMDB doesn't know about it. The compliance team discovers it during an audit. The integration was "planned for Phase 2" and Phase 2 never happened because the catalog was already working and the urgency had evaporated.
This isn't a criticism of the teams that make that call. Projects have budgets and timelines, and a working catalog without ServiceNow integration is genuinely more useful than a broken catalog with it. The problem is that "we'll add ServiceNow later" has a poor completion rate, and the cost of not having it is invisible until someone starts asking questions the platform can't answer.
One operational note for VCF 9 environments: the ServiceNow plugin is only supported with VM Apps organizations, not All Apps. If the VCF 9 deployment is using the All Apps org structure, the standard plugin path isn't available and the integration has to be built through the API or a custom connector. Worth verifying before the integration is scoped, not after someone has spent a week trying to make the plugin work in an org type it doesn't support.
Ansible, PowerCLI, and What They're Actually For
Somewhere in most VCF Automation environments there's a collection of Ansible playbooks or PowerCLI scripts that handle things the platform doesn't do natively — post-provisioning guest configuration, package installation, integration with monitoring agents, whatever operational task the platform couldn't absorb when the project was running out of time. This is fine. The extension layer is supposed to exist.
Where it becomes a problem is when the extension layer starts carrying weight the platform should be carrying. A PowerCLI script that runs weekly to identify and clean up orphaned VMs is a workaround for the missing decommission workflow. An Ansible playbook that queries vCenter and sends a report of VMs with no catalog record is compensating for the fact that provisioning happens outside the platform as often as inside it. The scripts work, they're well-intentioned, and they accumulate until someone realizes the "automation platform" is mostly a collection of compensating controls for the parts of the actual platform that were never built out.
The question worth asking periodically isn't whether the scripts work. It's whether the scripts are solving problems the platform should be solving directly — and if so, what it would take to move that logic where it belongs.