To VCDX with a fictitious design – Part 1

This is the first post as part of my series/guide for the VCDX prep here.

During my time preparing the design for the VCDX application and preparing for the defense I found posts from other people’s experience to be very helpful. Now that I am VCDX 142 I think it is time for me to give back to the community that supported me so much during this time and share my experience.

Becoming a VCDX was always a dream of mine since the day this certification was founded, I always worked with VMware software and practically based my career on it, I had the privilege to be the first VCP in my country Israel, I was a VCI for almost a decade teaching VMware courses in Israel, Turkey and for two years in the US and achieved my VCAP certs very early on, but the VCDX always seemed so elusive and out of reach.

When I moved to NYC to become a performance specialist going after the VCDX suddenly seemed like the next logical step so I plunged head in to the water.

Because I am an SE specialist I do not architect solutions as part of my job anymore, but I have discussions with enterprise customers about many subjects and my knowledge is deep, I also have a lot of customer experience from past positions so I decided to go the whole 9 yards and create a fully fictitious design, a very hard task indeed with 90% fail rate according to John Arrasjid AKA @vcdx001. 

My first design ideas were very complex and included too many unneeded components that I would have had to eventually defend, so I found my self in a need for help. Fortunately, I got contacted by a colleague from Mexico City, Agustin Malanco @agmalanco AKA VCDX #141 asking me to team up and build our fictitious design together, a very smart move as we could bounce ideas against each other and come up with the most ridiculous customer requirements. I am very happy that we also turned out to be a great team and very good friends working nights and weekends together for 7 months.

It took us a whole month to come up with a customer story that we could use for a complex enterprise grade design but still defendable, we started by having design meetings together setting goals and deadlines. I will create additional posts about the lessons learned from creating a fictitious design later on as there are a lot of things to share.

Each of us contributed 50% of the efforts and we continuously pushed each other forward, during this time each of us had some personal issues where we supported each other, there were weeks where one of us could not fulfill his tasks due to his workload so we backed each other up every time. Goose (I call him like that in a kind of homage to the movie “Top gun” 🙂 ) was responsible for network architecture and I for storage and critical apps, the rest was done together. In May we submitted the application, Goose was on vacation with VMware’s prestigious “Presidents club” and then he flew to Palo alto to RADIO conference as a CTO ambassador so I prepared the application documentation for both of us and we submitted the documents, crazy day, we both had the exact same application. More then a 1000 pages of 98% pure original documentation, the other 2% was document structure and inspiration from the VMware design services kit . It is highly important that if you are going with a fully fictitious design that your documentation is top notch.

After submission we stopped working, I dont know why exactly, maybe the exhaustion from the past few months or maybe it was psychological reasons casued by the wait for the results but we waited and didnt start preparing for the defense immediately as many others suggested. I remember thinking that I can never pass this because i dont have the strength to pick myself up again, but we did.

As soon as the results were in and we got accepted to defend we started working like crazy, first step was to preoare the presentation while creating tens of flash cards with questions we might get asked about by the panel. Our biggest concern during all these two months was that we found a few questionable decisions in our design that on hindsight we wanted to change, at the end we either decided to defend them and for those that we couldn’t defend we prepared  an alternate design decision while explaining our initial reasoning as well.

 

As soon as we had a presentation structure ready we started doing defense mocks, first preparing only for the 15 minutes presentation and creating backup slides (we had 76 of those!) Goose flew to NJ a week and a half before the defense and we worked here in my house from dusk till dawn every day doing mock defenses and finishing the presentation (eventually only finished our last version 5 minutes before the defense!).

On the weekend before the defense in Cambridge MA we drove up north to work with a study group for the last few days. This was invaluable for us, Goose and I were practically sharing a brain by then, having that additional feedback gave us the final direction for our defense, we learned that we dont need to focus on the technical side of it,  we had all that covered as we studied vigorously for the past months , now it was time to tie up the business side of things and the story of our project into the presentation, this is a fictitious design  and we were reviewed by the panel as if it was a real project, we had to make it believable as much as possible.

I added a lot of my experience with the customers that this design is based of and Goose did most of the technical research for us, we were a mean slick machine working together, it is extremely fun when you have such a good teammate and a friend beside you, i cant stress it enough how important it is to enjoy this process as you wont have time to enjoy anything else 🙂

Then D-day came, I will leave this story for another post but ill just say I felt I was not good, I really feel that I should call them and ask for a second defense as i know I was a mere shadow of how i performed during the last days to the defense. The night before I couldn’t sleep and was constantly throwing up due to bad food I ate that evening (hint: be careful what you eat the night before) the whole defense day felt like a bad dream including my car braking down completely on the way back to NJ and generally I had a bad feeling that I blew it. You can probably imagine how thrilled I was to find out I passed 🙂 the joy is unbelievable, to achieve success in something you wanted so badly and worked so hard for so long is an exhilarating feeling. I opened the email from Mark Brunstad @MarkBrunstad quickly like a band aid and happily read the I achieved the VCDX and my number is 142!

I learned a lot during this time, for example how to study huge quantities of technical material in a way I a very short time, how to architect a solution in a structured way weighting  all design qualities for every design decision and much more, I apply these skills in my job everyday.

I also got a very good friend, I cant thank you enough Goose!

I know I will definitely move more towards architecture positions in the future, I will help the community and other VCDX aspires to achieve success just like I got help from many other VCDX’s like Travis Wood @vTravWood Jon Kohler @JonKohler, Andrew Nelson @vmWnelson and Johnathan Shannon, I also got one precious advice each from Michael Webster @vcdxnz001 and Mark Achtemichuk @vmMarkA that I will definitely expand on soon.

This is the first post in this fictitious design for VCDX series and the first post in my new blog, hope you’ll find the information  here useful.

See you soon

Niran

To other VCDX posts in my blog:

To VCDX with a fictitious design – Part 2 – some lessons learned

Handling sub-optimal design decisions before the VCDX defense

How to create top notch VCDX application documents

Incorporating business requirements into your VCDX presentation

Important not to burnout while preparing for the VCDX defense

A few tips for the VCDX defense