VCDX – Multi-VCDX Success

If you are VCDX certified and considering going for Multi-VCDX (double, triple or quadruple VCDX), this post covers the pre-requisites, requirements and a strategy for Multi-VCDX success.

UPDATE: The VCDX Program has 1 hour telephone defenses for Multi-VCDX candidates.

List of articles in my VCDX Deep-Dive series (more than 70 posts)

Multi-VCDX combinations that make sense:

• Desktop Double VCDX: DCV, and DTM.
• Network Double VCDX: DCV, and NV.
• SDDC Triple VCDX: DCV, NV, and CMA.
• Desktop Triple VCDX: DCV, NV, and DTM.
• Elite Quadruple VCDX: DCV, NV, CMA, and DTM.

Pre-requisites

• Existing VCDX in the VMware eco-system.
• If you are VCDX-NV (NSX-MH) then you will be required to attend a panel defence.
• 2x VCAPs and VCIX passed.

Requirements

Your documentation must be tight and flawless.  If you expect to submit VCDX “candidate-level” documentation (which can vary greatly between people), think again.  Why do you ask?  Because with Multi-VCDX, there is only a 1-hr panel defense and thus your design submission must be exemplary!

This post covers the statistics of my various VCDX and NPX submissions for comparison.  You will not see many differences in my metrics as a VCDX candidate versus Multi-VCDX/NPX, since I am quite OCD about my documentation.  But it gives you an idea of what you should be bringing to the table.

Strategy for Success

• You can team up with a maximum of two other people, which will make a big difference in your time investment.
  • This can be a mix of VCDX candidates or VCDX certified team members, however, you must all submit at the same time.
  • Make sure you all agree upon a documentation standard and follow a strict set of rules regarding document structure, format and change control.
  • One person should be responsible for compiling the master copy and maintaining it until submission.
  • Use a DropBox/OneDrive shared folder for collaboration and each team member has a separate “work folder” with their name on it.
• Use an efficient document structure (files, chapters, references, etc.).
• Check your work for spelling, grammar and the correct use of the English language.  If you are a non-native English speaker, get someone who is to review your work before submission.  Bad English gives me a headache!
• Be very regimented and number every design decision.  Make sure every design decision has a requirements reference, justification, impact and risk field (use tables for best results).
• Avoid the pitfalls of bad design.
• Create a great logical design.
• Use “Solution Metrics” to validate that the business requirements are being met and include it with your submission.
• Extensive and exquisitely detailed supporting documentation.  Make sure you fully cover the implementation, configuration, testing and operation of your solution.
• You do not have to cover every product within the solution, but you must cover the “core product” of the submission and any “core product” touch-points to the rest of the solution (eg. CMA – vCD or Aria Automation, NV – NSX-T, DTM – Horizon View, DCV – vSphere).
• During your documentation review, ask yourself, “Could I give this document pack to a moderately skilled team and would they successfully build and operate this solution without contacting me?” If the answer is yes, then you are ready to go.