After the VCDX defenses last week in Munich and the defense sessions we had during VMware PEX I want to stress the following from my VCDX Defense blog article:
Next two are role-play based. The panel is the customer and you are the architect. By asking questions, white boarding, discussions you will need to solve an issue or come to a specific solution for the customer. This is something you can not really prepare. Although you may think you will have more than enough time, you will not have time enough. Time flies when the pressure is on. Keep in mind that it’s not the end result that counts for these scenarios, it’s your thought process! (source)
Please read the underlined section several times, it is about showing your skills as an architect/consultant. We do not expect you to to craft a full design in 30 minutes, we expect you to gather requirements and based on the info start crafting a high level overview/design. Or as John stated in his VCDX tips:
- Scenarios for VCDX defenses test journey to solution, not necessarily the final answer. Whiteboard, talk and ask questions.
- Troubleshooting scenarios – think of the architecture and implementation approach to resolution. Logs, design, SC commands.
Keep in mind that during the scenarios the panellists are working through a scoring rubric, and have prescreened apps and have specific questions that they need answered in order to score effectively. So ask questions and LISTEN to the answers!
The only thing I can add is: Ask Ask Ask, then tell what you are doing and why you are doing that. Just like you do with normal customers.
Those who do not ask questions would be fortunate to have customers who provide all the information that is needed to put together a solution.
You guys should record the defense sessions and publish them it would be great to see a good example of what is expected.
I wouldn’t say recording a defense session and publishing it would be all that helpful.
I approached my defense like this:
I assume that I have a couple customer directors in the room with me and maybe a technical resource from the customer side. I present my design exactly like I would present to a customer, fielding questions etc. It just so happens that this “customer” is more educated and seems to know the exact right questions to keep me “honest.” Think of it as a document review session with the customer.
Once we move into the design session, again treat this like your typical requirements gathering session. You’ve got 3 stakeholders (the panel) in the room who are “paying” you to conduct requirements workshops/design sessions. The trick is squeezing it into the 30 minute time allotment.
On the troubleshooting piece, I just decided to “think out loud” and throw a lot of questions to get clarity on the issue. “How is this configured right now? what is this here for? do you have X? Do you have Y?” And then I talk about things I would look at then ask them “out of character”
‘what am I seeing here?’
That said I am approaching this from a “this is what I do for a living” standpoint. If you’re not in the professional services line of work it may seem more daunting.
Simple but great article.