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,
- 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 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.