The vRealize AI team implements ML-powered features to solve problems across the whole vRealize Suite.
Over-provisioning was a perennial customer problem with some estimating that as much as 50% of their provisioned private cloud to be under-utilized.
Our data science team believed AI could solve this through accurate sizing predictions. Initial tests were promising. However, no one knew how to introduce this capability into the platform.
I connected with two designers working on vRA and we began by reviewing previous user research and interviewing internal SMEs to understand the provisioning context.
Cloud Admin (Jason)
Jason uses vRA to design, build, and manage a private cloud catalog.
Developer (Scott)
Request infrastructure resources through the catalog for the development work he is doing.
Jason designs templates for their private cloud catalog. He has lot of flexibility but provisioning size is primarily determined by a concept called Flavors. Most users create t-shirt size flavors to simplify the process of making requests for the developer.
Scott is generally less interested in the infrastructure details but he uses vRA to get what he needs for his project. He comes in contact with flavors when he makes a request from the catalog.
I documented the provisioning flow to capture what we learned and identify where the key problems existed.
Catch 22
Jason wants to make deployments as efficient as possible but he also understands that there is a range of needs so he usually offers a lot of choice to Scott.
Resource reclamation
Both Scott and Jason dread resource reclamation. It is time consuming with a lot of back and forth negotiating. As a result even when there are issues reclamation never happens.
“Better safe than sorry”
Scott isn’t always familiar with the sizing that Jason is using or how that translates to what his workloads need. Most of the time to avoid work in the future he chooses one of the larger available options.
I brought together the core members of both vRA and vRAI teams, presented our findings, and facilitated a brainstorm around how we might augment the current experience to solve for the problems we identified.
My PM came up with big idea that the team decided to test. It was inspired by address verification in e-commerce products, but applied to sizing and utilization.
I augmented the provisioning flow to illustrate the way this concept would impact the existing flow.
We presented our project and a mockup of our concept to a panel of users in our Design Partner Program for early validation.
Our users were excited that we were trying to solve the provisioning problem, but our approach in this concept didn't meet their needs for a solution.
After receiving the user's feedback, we came back to an idea from the workshop for a “wild card flavor.” This “Smart Flavor” could be used in a variety of ways just like existing flavors are. It would also seamlessly integrate with the UI and the API.
This new approach also simplified the workflow.
80% of deployments in early testing benefited
This evidence is starting to prove out the initial hypothesis that not only is sizing currently not efficient for our customers but also that our solution was effective.
Gaining initial trust is essential Something we started to see with all the customers adopting the feature was that after a short while of gaining trust they were much more likely to roll it out widely and didn’t feel the need to investigate as frequently.