I hope you have read our previous article Most Common Errors in VCDX Applications. VMware released this article because we want every qualified individual to achieve VCDX. For the same reason, we give feedback to unsuccessful candidates that identifies the areas of the blueprint in which they performed the least well, along with a few sentences to explain the nature of the shortcomings.
Both the VCDX program's published articles and its candidate feedback statements, however, are not prescriptive. For the most part, we identify shortcomings without giving a recipe for how to fix them. This is because we do not wish the way to achieving VCDX to become "fail it once." Instead, the way to achieve VCDX is to develop your knowledge and skills. We hope that candidate feedback helps guide that career progress, and that your progress will be reflected in your future re-application.
Nevertheless, we will always strive to help candidates avoid avoidable errors. Here is a set of avoidable errors shown in some recent applications.
"CONCEPTUAL, LOGICAL, PHYSICAL." The VCDX program uses these terms in a manner we believe to be industry-standard: John Zachman's system. We assume that all vSphere architects are familiar with this taxonomy; if you are not, please learn about it.
"MONEY IS NO OBJECT." A few candidates have recently submitted applications in which customers (real or fictitious) had essentially unlimited budgets. This allowed the designer to meet customer requirements in a very simple manner: by extravagantly overprovisioning parts of the design.
This approach is not disqualifying for VCDX, even though it's unrealistic. But your rich customer's tolerance for wasteful over-engineering may harm your chance to show that you can architect an adequate but efficient (and cost-efficient) solution.
(This series has already discussed the hazards of another type of design client: one whose requirements are so low that they do not allow you to demonstrate skills.)
"YOU FIGURE IT OUT." Some applications recently have suggested a misunderstanding of VCDX panelists' roles. The applications contained descriptions of customer requirements, followed by logical and physical designs; but whether these designs actually satisfied the customer requirements was left as an exercise for the reviewer.
If you are doing VCDX-caliber work, you are dealing with clients who do not take you at your word. Your clients' vSphere and design knowledge may even rival your own. The clients expect you, not only to submit designs that work, but also to show why they work. "Prove to me," they might say, "that we really can meet a 30-minute RPO for our Tier 1 applications."
Your VCDX application should be written as if it were addressed to just such a client.
Thanks Brian - great information as I am prepping my design for submittal in February -
Great work again Brian! I wish I had resources such as this when I was going through the VCDX process.
Thank you for providing additional tips and useful feedback Brian.