This post covers my approach to writing my VCDX-DCV Architecture Guide. I’ve been debating in my mind for a while whether I should write this post or not. I hesitated for a few reasons. First, I’m just a regular guy that happened to jump through the VCDX hoops and have no “insider” information on how they score. Those that do know the scoring rubric can’t disclose it anyway. Second, there are 1000 different ways to write your VCDX-DCV architecture document. Third, there’s no “magic template” or “sure fire” outline that ensures your design gets accepted. Do not view this post as shortcut or cheat sheet.
What matters is your content, how it aligns to the VCDX blueprint, and that you convey expert level knowledge to the reader. It’s NOT about speeds and feeds, but rather the full traceability of customer requirements, constraints, assumptions and risks throughout your design. Who cares if you’ve thrown every VMware product and feature at a solution if you haven’t met the business requirements? #Fail
So why did I publish this article? I know when I started the VCDX process it was a bit daunting to read the DCV blueprint and try to come up with an architecture guide that hit all the areas in a logical manner. I’ve heard from other candidates they experienced the same “VCDX writer’s block.” In fact several of us have scrapped our first attempts, and started over. Bottom line is you need to do what feels right to YOU, and what works for YOUR design while covering all the blueprint areas. You may not like my methodology or outline, which is perfectly fine and a valid way to feel.
I’ve also heard comments from VMware customers (like myself when I went through the process) that think since they aren’t a partner and don’t have access to the VMware SET templates that they are at a disadvantage. That’s not true, IMHO. Yes the VMware SET docs are structured and may help you, but they aren’t directly aligned to the VCDX blueprint and need augmentation.
With all those caveats, I wanted to share my DCV architecture guide outline. Maybe it will help someone with writer’s block, or enable you to see some the areas that a VCDX design could cover. Your design may need additional areas, or less coverage. This is certainly not all inclusive, and it’s guaranteed your outline will be different. It is your responsibility to ensure your documents cover all blueprint areas, makes sense for your design, and something you feel comfortable with. Own your documentation.
Before I go any further, let me state that how I chose to incorporate the specific VCDX bootcamp book recommendations is somewhat unique to my style. Of the submissions I’ve seen none did it exactly this way, which proves that there is no “magic” template or style for VCDX submissions. I just felt it gave a better overall flow to the document.
You will see some common sub-sections in all design areas (e.g. cluster, storage, compute, etc.). For example, in most areas I had specific conceptual, logical and physical sections. This helped me show the traceability of customer input through the entire design process. Each major section also concludes with a Design Justification which is a summary of how I met the customer requirements and sites all of the applicable requirements, assumptions, constraints, and risks.
At the end of the Design Justification section I had two tables to help distill down the critical information. First, I had a summary table, shown below. All of the design quality items (e.g. C02) were referenced elsewhere in that section as applicable. Possibly overkill, but I liked the compact summary.
The second table was that of the applicable design decisions, each with the decision, impact, decision risks (after all, nearly every decision has a risk), and risk mitigation. A sample design decision is below.
WordPress was not cooperating with me for a clean outline format, so I’ve inserted a series of screen captures to maintain formatting.