Its time again for some hopefuls to go through to defending their design.First of all, Congrats. Give yourself a pat of the back and a vH5 (virtual High 5). You’ve just reached base camp. The hike gets harder from here. From here on its all about how well you’re prepare to weather the storm. It can be a great day with sunshine and chirping birds or all hell might break loose. Its all dependent on you.
Being there a year or so ago myself, I feel the need to address how one should prepare for VCDX defence. There are plenty of blogs which tell you what to do and what not to do. Plenty of videos on youtube / vBrownbag etc. This list is something that I had with me originally. Its not a lot but it something that got me started.
- Know your design better than anything you ever knew or will know. I can, to this day go and defend my design again.
- Know your white papers / blogs / reference articles/. Do some research on how to use a best practises document and not follow any of it. Make your own best practises out of it, which suit your requirements.
- Identify your weakest areas in the design and speak to someone who is a guru in it. A lot of us know storage, but not everyone is good with security or networking.
- Buy a white board and white board every single design aspect. Conceptual, Logical and Physical. This is especially important if you don’t do this everyday; for example you might be involved in the admin side of things more than design. This is especially true for people who work for customers and not vendors/partners.
- Honeypots. Always have HoneyPot Answers. Josh Odgers (@josh_odgers) loves talking about honey pots for a VCDX Defense. These are things which make your design, well ‘your design’. You need to know everything about these. The answers you give for the questions about this should invite more questions. 🙂 .
- Know how your design would change if you didn’t have certain constraints (have appendix slides for these).
- Prepare well for your design scenario. If you don’t speak to customers often or never, you need to know what kind of questions to ask to get the right information. The panelists will help you but you still have to ask the right questions. Practise Design and TS scenarios.
- Some of us are very eloquent and natural speaking before an audience (thats what you gotta think the panelists are), some of us aren’t. For those of us who aren’t, your wife/GF/partner/friends/colleagues are your guinea pigs. Practise with them and Unleash the fury .
- For those of us with an accent (including me), speak slowly and clearly. Practise in front of a mirror.
- Participate in at-least 2 mocks. One as a presenter and one as a panelist.
- You’d be surprised how easy it is to ask questions as a panelist. Surprisingly for a VCDX defence you learn just as much being a mock panelist as you’re a presenter.
- Time your defence and Design and TS scenarios.
- Always have time left over for a feedback. If you are in a rush, ask your mock panelists to send you some feedback via email. Better yet give one of them a call to speak to them.
- Mocks via WebEx are fine but for an actual environment feel do it in person. There is a reason why defences aren’t done via WebEx.
- Make a mental note of what questions you answered and the way you answered them. Make flash cards out of it.
- Break down your design document into no more than 20 slides
- The slides should cover Compute, Network, Storage, Virtualisation/Cloud/Desktop or 2 or more of each, Availability, Recoverability, Manageability, Security and Performance very broadly.
- Now prepare a backup or appendix slide with the decisions for each of those sections.
- If there are important things ( adv setting on hosts, storage replication , # physical links, QoS Values, etc) have them on supporting slides. They might help you remember other important things that you probably forgot to add in an answer.
- Make sure you can whiteboard all the conceptual, logical and physical design aspects for Compute, Network and Storage etc.
- For VCDX Cloud, make sure you have the business objectives -> technical requirements mapping in a slide. They will always come in handy. I usually have this in all the presentations whenever I see a client.
- There are many ways to skin a cat, you don’t have to have a million slides but don’t skimp on them either.
If anyone has anymore please feel free to add them in comments.