frankdenneman Frank Denneman is the Chief Technologist for AI at VMware by Broadcom. He is an author of the vSphere host and clustering deep dive series, as well as a podcast host for the Unexplored Territory podcast. You can follow him on Twitter @frankdenneman

My thought on 800 page VCDX designs

1 min read

Although I’m not participating in the VCDX program any more, I still hold it dear to my heart. Many aspiring VCDX’es approach me and seek guidance on how to successfully pass the last part of the VCDX process, the defense.
Typically this starts with the discussion on the design itself and particularly how many pages the design should be comprised off. I heard stories about people advocating 800 page designs. And that makes me laugh, but mostly cry.
Let’s go back to the essence of the program and understand that the VCDX program has been erected with the idea to validate that someone is a skilled architect. That they can assist IT-organizations into building a successful vSphere architecture. In short, it’s just a stamp of approval of your skill as an architect.
Now with that in mind, how many skilled architects hand in an 800 page vSphere design document to a customer? How many customers would accept that? We are not in the business of writing the next Lord of the Rings novel. I worked on complex and massive architectures and most designs didn’t touch 150 pages.
When reviewing such 800 page designs, I noticed it’s more a cut and paste of official documentation on how a certain features work. It’s imperative that you know the inner workings of the pillars and foundation of your architecture. But your design should not be a thesis or a showcase of your knowledge of the products.
A design should highlight the requirements, the constraints and the chosen direction and technology. It should explain the workings of the used technology in a short and concise manner. Explain how this technology meet the customer requirements and if certain constraints require you to deviate from the default settings. Document thoroughly the effect the chose design on the service levels of the applications and architecture.
I feel that some people try to portray the defense as this herculean feat. And to be honest, if you haven’t operated as an architect for multiple customers, it might feel that way. But if you are the architect that has worked on multiple designs, that recognizes the risk-awareness culture differences between companies and how to cater to this need. That can drill down to the essence and explain why a certain requirement impacts a design decision and what effect this has on service levels or other requirements you should be fine!
Try to not to see it as the Mount Everest of your career, see it passing the defense as ceremony that validates your upward path of being a great architect. Do what you’ve always have been doing. If you provided your customers with 100 to 200 page designs, keep on doing that and submit such a design for your VCDX defense.

frankdenneman Frank Denneman is the Chief Technologist for AI at VMware by Broadcom. He is an author of the vSphere host and clustering deep dive series, as well as a podcast host for the Unexplored Territory podcast. You can follow him on Twitter @frankdenneman

VCDX- You cannot abstract your way out of things…

The amount of abstraction in IT is amazing. Every level in the software and hardware stack attempts to abstract operations and details. And the...
3 min read

VCDX Defence: Are you planning to use a fictitious…

This week the following tweet caught my eye: “@wonder_nerd Fictitious designs in a #VCDX defense have a failure rate of 90%. #VMwarePEX” < interesting...
1 min read

VCDX defend clinic: Choosing between Multi-NIC vMotion and LBT

A new round of VCDX defenses will kickoff soon and I want to wish everyone that participates in the panel session good luck. Usually...
4 min read

4 Replies to “My thought on 800 page VCDX designs”

  1. Very well written Frank! Fully agree.
    Architecture design must be holistic and coherent but as simple as possible. KISS approach applies here. As a design reviewer, I would refuse anything larger then 200 pages. And in complex design I would expect pictures (figures, diagrams, schemas) because “A picture is worth a thousand words”.
    I strongly recommend your readers to read Greg Ferro’s “Eleven Rules of Design Documentation” at
    BTW: Greg’s Rule 11 is “A Big Document is a Failure” 😉

  2. Hi,
    I agree only partially. Like you said, you’re not participating in the program anymore, so it seems you’ve forgotten its requirements  My application had 450+ pages. 120 of them was related to the design part (separate documents for networking, compute, monitoring). The rest was installation guide and other support docs. I defended a product not a single deployment, so the guides were VERY detailed with lots of screenshots even though they were automated in many areas. You can give them to someone with only basic vSphere skills and he/she’ll be able to deploy the product. The customer doesn’t have to read the support docs but they need to be there.
    I cannot believe that in the quoted application the design part was 800 pages in size, that would be stupid, but I can believe the whole application was that big.

  3. Hi Krzystof. Interesting assumption you make. Although Im not participating in the program it does not mean that I don’t interact with a lot of the program participants and staff members. But anyways. my article is about the design document, if I would I meant the collection of documents that must contain in submission, I would have stated it like that.

  4. The idea of handing someone with minimal skills a document that will allow them to produce a masterpiece never actually works out when all you’ve included is installation guides and whatnot. A 450+/800+ page design better have the EXACT settings for every single detail of the environment.
    I also hate having multiple copies of information, because it eventually will get out of sync with reality. Omitting 700+ pages and instead providing links to the vendor documentation to augment the design guide is a better idea. That way the documentation will match the software that is currently shipping.
    You’d be better off with a 50 page design and a USB drive with the particular software and a ton of automation on it, in my opinion. Cut the humans completely out.

Comments are closed.