August | 2014 | Data Center Digressions

On Saturday, I was one of the lucky 40 or so attendees of the latest VCDX boot camp organized by John Arrasjid (VCDX #1 – @vcdx001) and graciously hosted at the local EMC office in San Francisco. I had been able to attend a previous boot camp at PEX 2013 which had been a great learning opportunity, but I must say that this one was even better: the more casual atmosphere greatly contributed to better and more organic discussions, and a more interactive experience overall.

John led the boot camp, and was joined by a number of other VCDXs: Mostafa Khalil (VCDX #2 – @MostafaVMW), Matt Vandenbeld (VCDX #107 – @vcloudmatt), Chris McCain (VCDX #79 – @hcmccain), Nathan Raper (VCDX #85 – @nateraper), and Ben Lin (VCDX #45 – @blin23). All were kind enough to spend their Saturday afternoon helping our group of wannabes better understand how to be successful in our VCDX application and defense.

While we did not have enough time to formally introduce ourselves, there were a number of people I know pretty well from Twitter – and in at least one case, the real world – who attended and helped make the discussions as productive as they were. Just a few of the attendees: Bob Elwertowski (@BElwertowski), Dan C. Barber (@dancbarber), Kyle Ruddy (@RuddyVCP), Byron Schaller (@ByronSchaller), Adam Eckerle (@eck79), and @aus_effendi.

We went through the VCDX boot camp presentation (available here) in great detail, answering questions from the attendees as we went along. This covered the overall VCDX program and related VMware certifications tracks, along with the actual design submission and defense, the separate design scenario, and the troubleshooting scenario. Chris McCain talked about the VCDX-NV – how it’s both similar to and different from the other tracks (datacenter virtualization, desktop, and cloud). For example – a valid NV design may not include ESXi or vCenter at all, as NSX can be used with other hypervisors and cloud management platforms (like OpenStack).

Throughout, each of the VCDXs in attendance provided personal insights, recommendations, and reminders. Some of the ones that stuck out most for me:

Design Submission

On required design complexity for a successful submission: can you talk for 75 minutes about this design? While there are no hard & fast rules on environment sizes, feature sets, or complexity, there does need to be enough aspects of the design to cover all of the blueprint areas thoroughly enough to discuss the project at length.

A design must be able to be implemented to be successful. While this seems obvious and intuitive, not all submissions can pass this test. Especially if you are using a fictitious or semi-fictitious design, make sure that it will really work – lab out as much of it as you can.

You have to understand and be able to explain everything in the design, even if you weren’t the original architect. There are no acceptable excuses of “that was someone else’s area.”

You don’t necessarily need to be able to personally implement each portion of the design. For example, you don’t need to be able to perform the storage administration tasks step by step, but you do need to be able to tell the storage admin what configuration needs to be made, and articulate how the configuration (and *other* possible configurations) will impact the design.

A pretty cool feature is not a business requirement. The goal of the design is always to address the business needs, not the “ooh, shiny!” needs of the architect.

Designs are confidential, and individual copies are destroyed after the defense itself. VMware does keep a copy of the design at HQ after the defense, but only for a limited period of time (for legal reasons).

You can (and often should) redact any confidential information from your designs: business names, contact names and information, IP addresses (potentially), etc.

The largest submission was approximately 1,200 pages, with most being several hundred pages. Don’t be that guy (at either extreme) – be thorough but reasonable.

If submitting an existing, or real-world design, you may only need an additional 40 hours or so of work on the application for it to be complete in addressing the submission documentation guidelines. For fictional, semi-fictional, or designs without sufficient existing documentation, applicants can spend 300 or more hours on their submission.

Joint submissions can be successful and co-applicants provide each other built-in sounding boards & reviewers throughout the process. Each individual submission must indicate the other authors and architects who contributed to the complete design. One co-applicant’s successful defense of a joint design doesn’t guarantee success for all co-applicants as a lot still depends on the individual’s performance during their defense.

Design Presentation and Defense

Keep your presentation short, but provide yourself plenty of backup material. You should be able to go through your presentation in about 15 minutes, but you can help yourself out significantly by including as much reference material as possible. When Chris McCain defended, his presentation was around 17 slides but had 70 slides of supporting information.

Keep your presentation as visual as possible – diagrams, diagrams, diagrams, and tables.

Use hot linking as much possible. You can save yourself a lot of time not skipping back & forth between slides if you have quick links on each slide to the table of contents and possibly directly to specific reference slides.

Don’t introduce new material in your design presentation – it should all be taken from your submitted application. You can correct mistakes you may have discovered after submission, but the design itself should not change.

You must know your design in and out, but you must also understand the reasons for each design decision, and the implications of changing those decisions. Your design may be all NFS, but you must be able to demonstrate your knowledge of block storage as well.

During your design defense, panelists act as peers rather than as the customer from your submission. In the design scenario they act as the customer (with varying degrees of displayed technical ability).

There’s no required dress code, so dress appropriately and comfortably. You’re going to be on your feet for 2 hours or more during your defense. Don’t wear anything distracting to the panelists, either – and pants are *not* optional.

You can’t use your own laptop during your presentation; a Windows laptop will be provided for you. Bring your presentation on a USB key (preferably multiples to safeguard against loss, corrupted files, etc.) in both PowerPoint and PDF formats.

Design and Troubleshooting Scenarios

The timer starts when you write on the whiteboard or ask a question that provides additional information.

The first thing most successful candidates do is write down the business requirements on the whiteboard.

Don’t spend time doing math in your head – if needed, calculators are available.

Don’t assume information provided in the scenarios is correct – just as in real world customer interactions, there may be inaccurate information provided.

When asking questions, always explain why you’re asking – let the panelists see what you’re thinking and how you’re approaching the problem.

Identify and prioritize the business requirements, constraints, and risks in the scenario.

Diagram the proposed scenario – don’t just write down words.

The panelists are looking at what questions you ask and the methodology you follow – they need to see how you are tackling the problem at hand and not just randomly attacking it.

The panelists are also looking for how you change your approach, or the prioritization of the business requirements, constraints, and risks, as you adapt to the information you’re given.

Provide “proactive dramatics”. Just as the panelists are playing roles, so too are you playing the role of architect – overplay that role for maximum effect.

Continuously validate and adapt to the information you’re provided.

For the troubleshooting scenario, your first question should be “Did you open a Support ticket?”

Overall

Focus on business requirements first and foremost – not the technologies.

Study groups and mock defenses are highly recommended. One key thing noted is that doing these *before* you submit can be critical as it gives you the opportunity to correct mistakes or gaps ahead of time.

Mock defenses should include non-technical people as they will often ask more questions than highly technical peers (for whom aspects of the technology or design may seem too obvious to question). This was specifically and strongly recommended by both Chris & Nate.

When answering questions, talk out loud. This has been repeated ad nauseam in regards to the defense, but an interesting new point was mentioned: not only does it show the panelists your thought process and allow you to score points, but you may actually answer questions the panelists have in mind but have not yet asked, saving yourself critical time in addition to scoring points.

The more questions you can answer, the more opportunities you have to score points. Don’t provide too little information, but if a question can be answered in a sentence, don’t waste your limited time on an extra paragraph.

How to Fail