So, in addition to launching (more news on that later), I also have successfully passed my VMware Certified Design Expert certification. My VCDX number is #101, and I am over the moon with the result.

It wasn’t smooth sailing from the start, though.

The preparation

I’ve been considering going for VCDX since the VI3 days; but even reading through the blueprint was something I dreaded for a very long time. Seriously, I had that file on my desktop in multiple versions for over two years. So obviously, I thought I wasn’t ready yet.

Things changed as I designed larger and more complex environments. In the days of vSphere 4.1, I designed and implemented a stretched cluster based on HP’s LeftHand P4000 storage systems. In the end days of 4.1 (nearing 5.0), I designed for large virtualized Citrix XenApp farms, and I maintained several forked and iterations of reference architectures for SMB-sized environments. All in all, I began to feel I had the required experience under my belt to finally go down the VCDX road.

My journey accelerated quickly after that realization. Somewhere in the Spring of 2011, I attended a VMware PEX on Tour in the Netherlands. During the reception, I had a discussion with a couple of peers about VCDX. During the next couple of months, a VCDX study group was formed. Besides myself, Duco Jaspars, Arjan Timmerman and Marco Broeken took seat in this study group. During a preliminary meeting, we discussed methods of preparation, exchanged some study materials and drafted a rough planning. We agreed to meet every month or two to monitor progress and motivate each other.

Tip: make sure you don’t go through the process on your own. You need your peers for review. Everyone takes a different approach and has a different angle, and you’ll need that fresh lookout on your design. Secondly, make sure you plan very conservatively. You might run into a writers-block or otherwise. The peer pressure of the study group might make the difference.

The application

I kept postponing creating the actual design. I lost a whole lot of time pretending to work on VCDX but I was actually watching funny cat and faceplant compilations on YouTube. Just a month or two before the application deadline, I started to make progress on the design. I decided to combine two separate real-world designs into a single fictional design. That meant I spent about 100 hours of going through both designs with a fine comb in an effort to integrate the designs in the best way possible. Had I known that even combining two real-world designs was this much work (I can’t imagine the work you’d have to put in for a wholly fictitious design!), I would have either waited for a new project or had taken my changes with just one of the designs.
Much of the 100 hours of work on the design itself was the reverse engineering of each decision made. I am proud of the end result; it contains design rationale for each pesky little detail, which made re-tracing my steps when necessary really easy. I forked this way of thinking and designing to my regular work, where I use the design patterns from the VMware Design workshop extensively. It has made the quality of my work as a consultant and that of others much better.
Tip: make sure your partner and employer are on board. You’ll need their support during the whole process! Thankfully, my employer (OGD ict-diensten) agreed to freeing up some time (about one day a week in the last month-and-a-half) to focus on VCDX.

With the designs combined, I felt I had completed them enough to move on to the supporting documents. Thankfully, I had been working on standardizing implementation guides and documentation into frameworks and templates, so my implementation documents were already extensive and complete. I just had to /s/$realworldcustomer/$dummycorp to anonymize the documents and make some other small changes to be consistent with the fictitious design. Same goes for the standard operating procedures; I already had a library of SOPs, including a couple of very specific ones for these designs. I didn’t need as much time on the supporting documents, about 30 to 40 hours. Be careful when using boilerplate material though: it has to be specifically suited for your design and should match the specific elements and characteristics of your design in every way, especially in diagrams and screenshots.

Tip: I wouldn’t take this path again. I would have started either source projects or any future project with VCDX in mind. Having all the required documents alongside when you’re actually designing an environment makes all the difference. Taking each step with the VCDX blueprint in mind gives you the chance to actually align with all the requirements of the application, and is way easier than having to accommodate those application requirements post facto. I effectively did a post-mortem on two designs while integrating the two.

My complete application package weighed in at approx. 220 pages. That includes the design and all supporting documents. I feel that this is on the upper side of the scale and is obviously not representative of other VCDX candidates.

The defense

The best tip I have for anyone thinking about the VCDX certification: attend a VCDX Boot Camp. I attended three sessions (VMworld Las Vegas 2011, VMworld Copenhagen 2011 and one in Frankfurt in 2012). I feel this might have been a little too much (since I did take up a spot during the second and third session that could’ve been used by some-one else), but it certainly was very helpful. John Arrasjid’s tips and tricks are an amazing resource to utilize in the preparation for the defense. If you have access to VMworld sessions, be sure to listen / watch the break-out session from 2011. I’ve listened to VSP1708 – VCDX Panel Defense Preparation multiple times.

Since my application was on the hefty side, I had a hard time creating a slide deck that covered all areas of the blueprint and other relevant topics. I ended up with a boatload of back-up slides, with about 25 slides for the first part of the defense. I ended up only showing like 5 slides before the inquisition sorry questioning sorry questions started. The panel kept asking questions, but every moment they don’t talk or ask anything, you should mention a part of your design you’re particularly proud of. Prepare accordingly. Each second not spent discussing your design is time wasted. The 70 minutes for the first part of the defense were over in a flash. I remember looking at the iPad timer, it had only like 15 minutes left. Swoooosh, where’d the time go? Try to manage your time effectively during the defense! I found it very, very hard to do so, but I felt I did explain the weakest and most interesting areas of my design in the alloted time.

You know how people tell you you need to know your design by hard? That’s true. Very, very true. I have some references to a Microsoft Exchange Server Database Availability Group (DAG), and got asked more about Exchange than I’d expected. Just so you know: your panel might not stop asking questions outside of the VMware-box. Know your design in-and-out, out-and-in. Let peers review your design and have them write-up a list of weak points or otherwise point out parts of your design that grabs their attention. You’ll want to dedicate extra time to those areas.

I felt I didn’t whiteboard enough. I had a whole list of diagrams in my head that I wanted to whiteboard, but I simply blacked out: I had a hard time coming up with that list once I stood there. I decided not to worry, and to just wing it. I should have practiced diagramming out various specific parts of the design more. I believe a study group is of immense value here: whiteboarding out parts of your design for the study group trains your muscle memory to be ready for the real deal. Tip: practice whiteboarding specific diagrams in a mock defense session.

I had a black-out during one of the tougher questions on recovering from a split brain scenario and VMware HA. I just couldn’t explain the how and why, although I did know the answer and had dedicated a whole section of the testing plan to this specific area. I could only say “I don’t know, but I know I have documented this specific part in such and such document”. Tip: if you don’t know, say so. Don’t fool yourself, be honest and concentrate your effort on the next question.

Despite some of the shortcomings, I never felt really nervous. I was confident with my design, all rationale and all decisions made. I knew I was comfortable presenting and standing before a customer (or defense panel, as it turns out). The first thirty seconds inside the room where the defense was held were comfortable enough for me to actually think “hey, I’m not nervous. I think I’ll have a blast. Let’s do it!”.


I felt confident about the second part of the defense: the two scenarios. I knew I had to concentrate on touching all areas of the blueprint during these scenarios. Don’t dive into the design scenario head first, but keep the conversation focussed on the conceptual model: collect all relevant business requirements, constraints, assumptions first. Make sure you’ve discussed all areas of the blueprint. Then move on to a logical design, while keeping the requirements, constraints and assumptions in mind. Explain your considerations in each design rationale so the panel (acting as clients) knows where you’re going and what you’re thinking. Use the whiteboard to diagram the relation between the conceptual model and the logical design.

Similarly, keep a high level overview during the troubleshooting scenario; you need to ask questions first. Again, blueprint blueprint blueprint. Use the whiteboard to make the process visual, in order to rule out areas of the blueprint before you move on. Explain your suspicions moving forward and explain your train of thought to the panel.

The waiting

I had the worst nightmares in the two-week waiting period after my defense. I dreamt the same thing every single night: I dreamt I had received the defense results. In my dream, I read the e-mail (which doesn’t give away any information in the message body, by the way) and opened the attachment. I told myself that it was real rather than a dream, since I managed to open the attachment and pictured the PDF in my head. Then I’d begin to doubt myself: was I still dreaming or was it real? It was maddening and exhausting to have this dream each night. I wasn’t of much use at work or at home during this period.

I did make sure I had some fun stuff planned to take my mind off the waiting. Since the hard work was behind me, I felt I deserved some time off to horse around. I have completely re-built the home media centers (Raspberry Pis with XBMC with a central MySQL library database), the central media server (Microserver with Windows Server 2012), re-organized the eBook collection using Calibre (since I won a Kindle at VMworld Barcelona!) and spent lots of time with family and friends, whom I had neglected in the months prior. Tip: make sure you plan a cooling down period with lot’s of fun activities with friends, family and hobbies.