VCDX – Learn to speak “VCDXese”

When you first start participating in Mock defences it will take you some time to learn “VCDXese”.  In “Think like a Panelist”, I briefly touched on the types of questions that you will be asked. This post expands on that and focuses on the meaning behind the “syntax” of the questions; a “VCDXese” dictionary if you will.

List of articles in my VCDX Deep-Dive series (more than 70 posts)

The panelists will deliberately phrase their questions in “VCDXese” to avoid giving any answers away and to also verify that you can communicate at “C-level”.  “VCDXese” is really a business language; it is what a CEO, CIO or CTO speaks.  So your task is to learn the language and translate it to the technical world and be able to respond in kind.  You have to consider each question and formulate your responses based upon your understanding of your design and the possible areas you are being queried about.  For example:

1. “VCDXese”: How does that design choice relate to the conceptual model? – Plain English: Tell me how that physical or logical design decision relates back to the business requirement of the customer.  Does it conflict with any other customer requirements, constraints or assumptions? If yes, how did you resolve that conflict?
2. “VCDXese”: How did that constraint impact your design? – Plain English: Your customer had a constraint or limitation that restricted the choices you had in designing the solution. What were the trade-offs you made in your design to meet that limitation?  If the constraint was removed, how would that change your design?
3. “VCDXese”: What are some of the risks associated with that design choice? – Plain English: Tell me about the pros and cons related to that design decision.  If the risks are that great, what is the benefit?  Did you consider any alternatives?
4. “VCDXese”: How did you mitigate that risk? – Plain English: What did you do to reduce the likelihood of that problem impacting your customer?  Did you provide detailed standard operational procedures, training or knowledge transfer?  Maybe you could have tried another method that would have removed or minimised that risk?
5. “VCDXese”: How did you validate that design decision? – Plain English: What information did you collect? How did you analyse the data to decide on that engineering specification?  Justify your decision.  What tests did you execute to prove that your design decision was correct?
6. “VCDXese”: What are some of the operational complexities? – Plain English: By making your design more complicated, did it make the job of the operations and administration staff more difficult?  Will they curse your name into eternity?
7. “VCDXese”: How did you resolve that requirements conflict? – Plain English: Explain why you made this design decision when it clearly conflicted with a customer requirement or constraint.  Which requirement was more important to the customer?  Why was it more important?  Could you have modified the design in some other way to accommodate both?  What capability or functionality did the customer lose by selecting one requirement over the other?
8. “VCDXese”: How did you achieve that SLA? – Plain English: Where did that SLA come from?  Explain how you translated that SLA into an RPO and RTO.  How did that translate into your design?  How did you verify that it could be achieved?  After your design was implemented, how did the operations staff measure that the SLA was being met?  How many outages can the customer tolerate per year?
9. “VCDXese”: How did you meet that security requirement? – Plain English: Explain what features of vSphere and the associated security products you used to provide compliance with that security requirement from the customer.  Did you consider the end-to-end requirements of that requirement or did you get stuck in your silo of expertise?  Did your security design impact the performance requirements of the solution?  Did it make it operationally complex?
10. “VCDXese”: So how does that work? – Plain English: Please give me a detailed break down of that particular feature.  In particular, I am looking for subtleties that prove you have an expert understanding of the subject.  It would be good if you have some use-cases that you can use to provide contrast and the pros/cons of how and when to deploy it.

This is where “Practice makes perfect”, you have to participate in as many VCDX mock defences as you can with VCDX-level people to really hone your skills, otherwise you will crash and burn on D-Day.  By not being proficient in “VCDXese”, you will not understand the underlying question and then waste time blathering about parts of the solution that the panelists are not interested in.