My design documentation consumed my time more than anything else for obvious reasons. It was based on a simple migration project for a small customer. We are talking less than 50 VMs. For the most part it was the typical vSphere deployment that I had done many times over.
The size of the environment does not matter. It is the quality of the design because the same conceptual and logical principles should be applied in any deployment regardless of environment size. So focus on design quality. You also do not want waste time looking or waiting for the perfect project to come along. Any environment can and will serve as the foundation for your design documentation.
Everything that was in the VCDX BLUEPRINT must be in the design documentation. Like I did with everything else up to this point I created a checklist in a spreadsheet to make sure I had everything covered…in detail! I reviewed it over and over and over.
During the beginning stages I find myself getting stuck. This is when my mentor Tim Curless (VCDX #114 – @timcurless) helped me get by what seemed to be self-inflicted roadblock. I just kept spinning my wheels and it was getting very frustrating. I would start something and then for some reason get it in my mind that it wasn’t PERFECT enough and then scrap it all together. If you’re experiencing this like I did…get that out of your mind right now. Face the fact that “nothing is perfect” so forget about it. It will drive you crazy.
Once I was back on track I created an outline of my design doc that reflected what I had in the spreadsheet; and my spreadsheet was based on the blueprint. This outline actually ended up serving dual purposes and became my table of contents later when I finalized my documentation. The outline really helped me stay organized throughout the design phase. In the end I typed each section as best I could and kept moving. I made a few notes for myself but I needed to keep moving forward. Once everything was complete I went back and made adjustments wherever I found conflicts or contradictions which easily happens when you have to sprinkle in the “fictional” aspects of the design. I used the fictional parts to do two things. One, fill in gaps to satisfy a requirement on the VCDX blueprint; two, creating talking points for my VCDX defense. (hint hint)
I originally wanted to submit my design docs for the July deadline to defend in September but I did not like how my storage and network design sections flowed. So I scrapped those two sections and rewrote them.
Most important part of the design is ensuring RAMPS is being applied in all areas:
- Virtual Machines
- Virtual Datacenter Management
- Networking
- Storage
- Compute
Don’t forget BCDR. From what I have read and heard from others, some candidates leave that out and end up having their design doc submission declined because they did not have all of the required design criteria. So do not omit something because the actual implementation did not use it or because you do not know something very well.
In the end I had four main documents that I submitted for my VCDX application.
- Architectural Design Doc
- Operational Procedures
- Installation and Configuration Procedures
- Validation and Testing Workbook
All placed into one (1) ZIP file and sent to the mothership! DONE!
The Wifi-Cable 