05 Jan 2022 by Simon Greaves
A few weeks ago, in late 2021, I sat and passed the VMware Certified Design Expert on Datacenter Virtualization (VCDX-DCV). The purpose of this post is to serve as an overview of what specific actions and tactical steps I took that I believe helped me pass the defence stage of the process.
To pass the VCDX, regardless of technology track you need to complete some specific steps. They are:-
Working on the assumption that you have already produced a design, submitted it and been invited to defend, the next stage is the defence.
Here is your opportunity to Succiently present your design in a series of slides, covering the key areas of the design. As per the blueprint, this should provide an summary of the design, covering the company background, key business requirements, conceptual, logical and physical design for the key items of Virtual Datacenter Management, Virtual Machine, Compute, Storage, Network & BCDR.
The best advice I can offer when preparing the slides is to ensure that in each slide you include enough information for you to be able to mentally recall the key decisions that made up that part. As an example, if you are discussing the network elements, ensure you know enough details to prompt yourself to discuss each design principal (Availability, Manageability, Performance, Security and Recoverability) without having to bring up other slides to back up this information.
Really focus on the key decisions, my design included lots and lots of different design decisions, but not all were really specific to the key business requirements. They partly met the requirement, or acted as additional decisions to support another decision (such as priorities set for vMotion Traffic when using Network IO Control). These key items (using Network IO Control) I made sure to cover off when on this slide. My thoughts were if I reduced the unprompted information I could save some time for any questions where I hadn’t prepared an answer.
Try and provide a summary of the decisions, rather than the specific details. Say “I chose this network design decision to meet requirement X, and to meet the performance & availability SLA, whilst remaining within the constraints”, rather than “I chose 10Gb networks because they offer better throughput”.
Every design decision must map to a requirement, if you can’t justify every single design decision it shouldn’t be in your design.
This is a common theme amongst fellow VCDX blog posts, knowing your design is crucial to passing the VCDX.
You might see this and think, “of course I know my design, I wrote it!” but I know from first hand experience this is easier said then done. My design alone was over 200 pages, with 180+ design decisions, not including supporting documents! That’s a lot of information to be able to recall off the top of your head!
My suggestion here is to consider re-reading your design the day before your defence so its fresh in your head, and focus in on the justifications for each design and associated risks and alternatives. This way when you are challenged on your design choices, you will fully understand why you went with that choice and not an alternative.
Beyond the main slides that cover the key design pillars, you will want to include some backup slides with additional information in case you are pressed on a particular subject and can’t cover it in the main slides. Areas such as lifecycle management or further information on performance analysis and platform sizing to meet the performance SLA. Knowing these slides is just as crucial as knowing the design, you don’t want to waste time in your defence trying to find the correct slide. As before keep it succient and easy to understand.
The whiteboard can prove useful during the presentation defence, depending on the questioning from the panelists. The whiteboard is your opportunity to showcase your design skills, perhaps down to the physical layer which you wouldn’t cover in the scenario defence. The whiteboard will not typically form part of your presentation (although I think it would be interesting to see one that did), but you may need it to cover areas in a bit more detail.
Listen for clues from the panelists such as “tell me more about how you would do that?”, or “show me how you would do it if that constraint wasn’t in your design?”.
Mock defences against mock panelists are really useful to help you practice working through your presentation to ensure you have covered all the key areas of the blueprint, address any items you may have forgotten from your presentation, and get some real world practice talking through the slides and navigating to backup slides.
Apart from mock panelists, I made sure to practice going through my main slides uninterrupted. I repeated this every few weeks and a couple of times a day just before the exam so that my presentation flowed a lot more naturally. This helped me ensure I knew my presentation well and could easily jump to any slide and talk through it in a few minutes.
For me, this was the worst part! I was unable to leave the room and was buzzing with adrenaline by this point which made settling into the scenario harder. I think I would have preferred to go straight into the scenario. That said I think the break is important because it helps you take a few minutes to put the presentation behind you, because if you feel you performed strongly or not, there is nothing you can do about it now. For any areas you think of that didn’t go as planned, (think Availability, Manageability, Performance, Security and Recoverability (or AMRPS) try and cover those in the scenario defence after the break.
If you feel stressed just focus on your breathing, close your eyes and take deep breaths to relax.
Working through a scenario in 45 minutes requires practice. Practice areas such as time management, requirements gathering, risk and constraint identification, and whiteboarding conceptual and logical designs. The scenario you will work through will likely be different for everyone, something that involves a ‘Swiss Army Knife’ way of thinking. As the scenarios can vary significantly its not something you get good at by asking the same questions over and over again, its challenges you to think on your feet and be prepared to modify your design on the fly as the customer requirements given by the panelists change your proposed design. Just like with real customers, this modification can change part way through the scenario defence, forcing you to revisit some key elements of your design and forcing you to change it, possibly with only a few minutes left in the defence.
I found it useful to divide my whiteboad into columns where I captured Requirements, Constraints and Risks. I also added a Parking area for any information that was incomplete. This isn’t in the blueprint but I think it worked well for me. Be careful with this that you don’t park too much as the panelists might suprise you with the information which modifies some of the key elements of your design. I also included a space for assumptions, but ideally you want to keep those to a minimum, as time management is crucial you might be able to use some temporary assumptions to help you start a conceptual and logical design and then, just like in the real world, modify the design if those assumptions turn out to be incorrect.
Ensure you gather sufficient requirements to cover all the design principals (AMPRS).
The requirements gathering is about showing your ability to gather enough requirements to form the foundations of a solution design. There are no right/wrong ways to do this, it really depends on the situation. The way I would design a solution with no compliance constraints and no budget restrictions are significantly different to how I would design it for a highly constrained budget that must comply with strict compliancy standards.
A key suggestion I picked up on time management was to be direct in my questioning when gathering requirements, ask directly for the SLA used to measure availability and performance, even if you don’t get a direct answer, you will save valuable seconds getting to the point of the question.
There are some requirements given to you by the panelists that might not be key requirements, they also may withhold some key requirements or constraints which can signicantly change the trajectory of your design. Areas such as compliance is one, if you have been given a scenario and then discover it requires PCI compliance, this will dictate how you design the management plane, encryption, two-factor authentication etc. I found it useful to read up on some key compliance types before the defence, PCI, HIPPA, SOX, GDPR. By reading up on these I knew how I needed to design encryption etc. If you are unsure you can always ask the panelists if they require storage encryption in transit etc. or use a working assumption if its not clear. Hopefully by doing this you can spend less time asking questions on security or managability etc. for each design pillar (e.g., compute, storage networking), and instead focus on other areas you haven’t addressed.
It takes up to 10 business days to get your result, use this time to make lots of notes on areas where you could have made improvements and any questions that you were unable to answer in case you don’t pass and require another attempt.
When you have the result, remember, what you have learned along the way has made you a better Architect, regardless of outcome. You are better all round as this process has taught you to really focus on why decisions must be made, something which will benefit you and every customer you work with in the future.
I hope you pass, and I will look forward to seeing you in the club soon!
Good luck!
Tagged with: vSphere
Keep the conversation going on Twitter!
Reply with Twitter