Pitfalls of Fictitious VCDX Designs & How to Avoid Them

Submitted VCDX designs may be fictitious, either partially or wholly.  But VCDX candidates must defend all parts of their designs as if they were real. VCDX panelists do not ease their questioning on fictitious parts: if they did, candidates could evade questioning on weaker parts of their designs by claiming, truly or falsely, that they were fictitious.

Over time, the program has found that candidates defending largely fictitious designs succeed much less often than do candidates with wholly or mostly real designs. This article explains common problems with fictitious designs and gives suggestions for avoiding them.
Fictitious designs are associated with failure for three reasons:
  1. Fictitious designs are typically submitted by persons with less direct experience in the field of vSphere design.
  2. Historically, fictitious designs received by the program have been weaker than real designs.
  3. Sustaining a complex, internally consistent fiction is more cognitively difficult than describing a set of facts.
Why do these factors apply?
The VCDX program typically receives fictitious designs from candidates who have worked, not as vSphere architects, but in an allied vSphere-related career: as a system administrator, support engineer, technical trainer, IT business analyst, or other non-architect role. Such candidates want to expand their careers into new scopes by achieving the VCDX credential.
However, the VCDX credential is, by design, not structured to cater to career changers. Instead, it aims primarily to recognize in-career achievement. This choice is reflected in the VCDX blueprint. The blueprint lists qualities a successful design and defense must show, but it does not specify how those qualities are to be achieved.  Candidates must reveal that they know how to achieve the qualities without being prompted: neither by the blueprint nor by defense panelists.
Candidates who have been closely involved with many vSphere design projects will have learned from experience how to achieve the desired qualities. Candidates who lack this experience must acculturate themselves in other ways, or else they will fail. Self-study will rarely suffice. We urge career-changers to shadow real design projects whenever possible, starting as early in the process as possible: ideally, during the requirements-discovery phase.
Success is more cognitively difficult with a fictitious design. At defense, all candidates should expect to be challenged on matters including (but not limited to) these:
  • Internal inconsistencies in the submitted design
  • Discrepancies between the submitted design and remarks made orally
  • The rationale for decisions made
All these challenges are more difficult with fictitious designs. When a design itself is a fiction, inconsistencies and discrepancies are a greater risk, simply because the design has not had exposure to the quality-assurance features of reality: exposure to peers, attempts to implement, and challenges from competition. Composing a fictitious rationale for a fictitious decision is much more difficult than relating the real rationale for a real decision, especially on one's feet in front of a panel.
Candidates should also expect to be asked counterfactual questions by panelists: "What if your client's requirement had been X rather than Y? How would your design have changed?"  Answering this type of question will be particularly difficult for anyone whose concept of his or her fictitious client's needs is poorly fleshed out.
Let's set aside the simple mental burden of fictitiousness. Candidates tend to submit comparatively simple fictitious designs, based on the belief that these will be easier to defend. This belief is false. Simpler designs allow the candidate to demonstrate a narrower range of skills.
Most of the program's fictitious designs have come from technical personnel who are non-architects. These people tend to compose fictitious requirements that are technical rather than business-oriented. This choice is an error because it allows the candidate only to display skills on the physical-design portion of the blueprint. Technical personnel's key barrier to success more commonly lies in the logical-design portion.
For example, a candidate might include this "requirement" in a fictitious design: "Servers used must be blades, due to internal political factors." But this stipulation--really a constraint--allows the display of no skills in any area other than the physical design.  An example of a requirement that would serve a candidate better: "Rack space must be aggressively conserved, because datacenter space is rented per rack, and customer's rental contract is up for renegotiation shortly after the project's conclusion."
To sum up: candidates considering the submission of a fictitious design should consider these strong suggestions.
  • Associate yourself with as many real-world design projects as possible. Carefully study all phases of these projects, especially the requirements-gathering, the validation phase, and the management of the implementation.
  • Strive to acculturate yourself in the mental world of the vSphere architects. Ask architects about their career progression. How long did it take? What was their biggest failure? Read the same blogs architects read. Be acquainted with the products (not just VMware products) architects choose among.
  • Before you begin a design, compose a detailed narrative of your fictitious design customer. Name it, specify its business and how it achieves profit, and anticipate the risks and pressures it faces. Document these fictions and commit them to memory. You might not include them all in your design submission, but you will doubtlessly need to call them to mind at defense.
  • Seek review of your work by others whose strengths balance yours. A sysadmin's fictitious design would be profitably reviewed by an IT business analyst, and vice versa.
  • Seek review of your work by more experienced architects. Ask them to flag inconsistencies and weakly justified decisions. Also ask them to flag anything that seems contrived or unrealistic for any reason. Repair and replace the flagged sections before you submit your design.
Attention to these suggestions will maximize your chance of success.
0 Kudos
2 Replies
VMware Employee
VMware Employee

I'd like to echo and support Brian's comments here. I've had discussions on this topic with several people considering the VCDX defense.  I find it much easier to defend a real or mostly-real design due to the simple fact that you probably had to go through many of the discussion/questiion points along the way.  For a fictional design, the work usually springs from your head fully formed, lacking the the realness that makes an implemented design defensible. Or, as Brian so eloquently states, "Sustaining a complex, internally consistent fiction is more cognitively difficult than describing a set of facts."

If you plan to defend a made-up design, remember that "because that's the best practice" is a terrible answer to any question regarding why you designed something a certain way.  You must understand each decision point and why you chose a certain path over the other(s).  In my opinion, that is much easier when the design was created with a customer who has to own the solution once it is implemented.  They tend to understand what is required to have something supportable.

As Brian mentions, and a lot of candidates fail to realize, the VCDX is as much about business requirements as technical solutions.  In my opinion, the the defense leans more towards the business than the technical.  Sure, a VCDX must understand the technologies, but the why behind the technology is arguably more important.  If you've made it to the defense, you've already shown your technical understanding via the DCA and DCD exams.  Now is the time to show that you can apply that to solving business challenges and present that solution in an effective manner.

Definitely run your design by co-workers -- they will probably ask some of the questions that the panel will ask.  When the design is in your head, you think you've covered everything, and believe you have all the answers.  Unless you are a truly unique individual, you have probably missed something.  It is better to be prepared than to get caught off guard.  Odds are you'll be nervous, and being prepared is the best way to handle that, IMO.

Brian, fantastic suggestions and great guidance!


Doug Baer, Staff Architect, Sr. Manager of vPod Architecture team for the VMware Hands-on Labs | VCDX #019, vExpert 2012-20 | @dobaer
0 Kudos

Brian, you are churning out a nice series of helpful tips for candidates.  Nicely done.

VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
0 Kudos