Knowing Your VCDX Design

While I was studying for the VCDX, pretty much every successful and unsuccessful VCDX experience blog post or workshop conversation has these words as advice.   “Know your design!”

What does this advice actually mean to a VCDX  candidate ?  Should you sit there and memorise your documents.  Keep reading it over and over again?

Personally I think not.So, in my opinion  “knowing your design is….”

“Presenting evidence to the panel that you know your  project  from a business and technical perspective and  how it illustrates you as an architect”.

The aim is to  Illustrate knowledge  in each of the areas from the blueprint so you achieve  VCDX.   A potential mistake here is to assume a working  real life solution will hit all areas and pass, yeah it works, but will it make the certification review.

How do you prep for this and study your own design.    Personally, I dedicated a week or so purely to below  process prior to my successful defense. It helped me find areas of weakness and identified technical areas I needed to review / brush up on.

Knowing your design objectives

  • Know the main design requirements that drove key logical decisions.
  • Understand how the  physical design decisions were implemented technically.
  • If it’s an unique implementation choice  that differs from common  reference documentation know why  it was chosen  and what would  be done if things were different.
  • Show the impact of the choices.
  • Discuss the submission risks and risk mitigation approaches for key risks.
  • Understand alternative approaches to physical implementation.

Where to start?  Personally, I created an excel spreadsheet listing,

  • Requirements
  • Constraints
  • Assumptions
  • Risks
  • Design decisions
  • Logical list
  • Physical list
  • Mapping each physical choice to the logical design decision.

From here, I  came up with a list of weaknesses and questions.    A lot of people use quizlet for some of this.  I didn’t really get on with it, but I do see the potential for others.

Once I gathered this information and identified questions I prepped standard answers  and ensured I had both business and technical elements.

This technique consolidated my design into a set of decision  thoughts and configuration elements  I could work on studying, and memorising.

I also used this list and example questions to identify subjects that technically I needed  to study and increase my understanding of ( i.e. shared fate concepts, STP and availability  impact with dVS configurations).

In my opinion a  VCDX  candidate going into a defense is aiming to illustrate how they are capable of being the lead architect of a project,  although the panel are  architects, you are the lead in your  submitted  project.

As lead architect you  set your presentation approach and provide opportunities to score.  You need to  try to remain in control of the presentation and cover  all areas in blueprint.

While prepping for this  I created presentation note cards to discuss the key areas and created / practiced some standard logical and physical diagrams for the whiteboard that matched the content.

I used a minimum of one diagram   per level (MVCNS) and covered  the major silos (AMPRS) with practiced annotations on the whiteboard.

It nice having a PowerPoint, but in my opinion displaying you are capable  of a  flowing explanation and  whiteboard drawing at the same time is essential.   it really helped my confidence level and in the real world it is expected daily as an architect.

  • Practice explaining the submitted  design and key technology’s for each area.
  • Be critical  of knowledge and the submission – plug the gaps for the defense day
  • Create potential  questions and  standard answers.

One useful approach I used that really helped  was to ensure  I  could  display  expert level physical knowledge for each area I  referred to  at a relevant time, rather than waiting \ hoping for a panelist to question me.  I  found this can be  blended into the conversation with ease.  i.e.

  • Use cases
  • Max  and mins
  • Restrictions and impacts
  • Design choices
  • Submitted  project  hardware with  main vendor alternative examples.

Whatever I  studied  here,   i ensured I had some deep dive detail and justification  in case of probing from the panel.

One final aspect of knowing you design is confidence.  I found this  is similar  to prepping to teach a  course.

Preparing yourself for the potential of the panellists / audience  agreeing or not agreeing with you,

Sticking   to your guns with evidence.  It’s your design, but confidence with technical understanding.

I.e.

“I understand your point of view however consider  X, Y , and Z ”

“Understood, I   Considered  X.   It is   listed  as a risk, mitigated using  y and road mapped to be potentially  removed or automated using  scripting or solution in Z

The panellists  are architects too, not full time examiners.  They will have personal thoughts on approaches and why things are better or not.  There will be reasonable and friendly, but allow no  bluffing – it won’t help scoring just waste time and decrease scoring opportunities.

Summary of my approach  for “knowing your design”

 

  • Learn the main   design decisions from submission – I made  charts, mind maps. lists
  • Identify  the weaknesses in the design   submitted and how to improve it (evidence),
  • Know key  risks  and how   mitigation worked  –  just accepted by the business is not mitigation (A daily standard check using powerCLI, or a vROPs alert with specific badge reference maybe easier to justify).
  • Practice  standard drawings that illustrate the submission – blend into conversation  for evidence.
  • Practice and study to create  detailed explanations of  key areas from blueprint using submitted  project implementation as the example.

This process worked for me in my successful defense.  Hopefully this is useful to others.

Leave a Reply

Your email address will not be published.