UPDATE: The VCDX Program is currently trialing 1 hour telephone defences for Multi-VCDX candidates.
Multi-VCDX combinations that make sense:
- Desktop Double VCDX: DCV and DTM.
- SDDC Triple VCDX: DCV, NV and CMA.
- Elite Quadruple VCDX: DCV, NV, CMA and DTM.
- 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 or VCIX passed (DTM/CMA waiver has now expired).
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 as a VCDX candidate, you can explain any weaknesses in your documentation during the panel defence. With Multi-VCDX, there is no panel defence 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 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 vRA, NV – NSX-v, 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.