There’re a lot of blog posts and videos out there of people describing their path to the VCDX. They’re all good reads/views and you can glean some valuable information out of them. What hasn’t been done enough of is how you shouldn’t do this, where people tripped and what they learned from the process. After all, it’s the “I did it..” posts that make music. This post describes some bits of my journey towards this credential and more importantly, I’ll make an attempt at telling you what I did wrong or not enough of or too much of. Given the VCDX is about real world designs too, this post might be helpful in everyday jobs.
Before anything else, I’ve got immense respect for people who’ve reached this pinnacle of VMware certification and career milestone. This is is NO way taking any credit away from them in how they mentored me and guided me. I’ve got several good mates who are VCDXs or aspiring to be on that list.
Disclaimer: I don’t know the scoring rubric. I work for VMware. I’ve appeared before the VCDX panel three times.
To enhance readability, which also happens to be a key design attribute, I’ll split this up into easier chunks.
Part 1 – Lessons Learned (aka what a mentor assumes the protege already knows)
Part 2 – Where I Messed It Up (aka more detail about Part 1)
Part 3 – Design Scenario Advice (aka don’t overlook this part of the defense)
I’ll cover these 3 posts from a DCV perspective, you can certainly relate it to the other tracks.
First, if you didn’t already fathom, the VCDX certification is expert level validation of architectural/enterprise design skills. Re-read the underlined words. Expert level – you’ve got to able to explain a lot of things in great detail (more on this in a bit). So if you don’t know HA Admission Control, LACP vs LBT, NIOC, NSX Edge LB vs ECMP etc enough to talk about them for a good 5 mins non stop, you don’t know enough. Architectural design skills – The VCDX isn’t how about big you are or in other words how many bells and whistles your submitted design had or how many hosts/clusters/VMs it had or how many things (Commvault, vRA, vRO etc) it had or if it brewed great coffee for you (that’d be a definite plus, wouldn’t it?!). It’s how about your design met those business requirements, about how it met the needs of the business while taking into account the constraints and managing risks and assumptions. Keep things minimalist, less is more.
Second, no one will tell you everything you need to get your number. Right, now, this is a personal one, feel free to comment. When I started working towards this certification and in pursuit of enterprise design skills, I stupidly assumed anyone I’m studying with or being mentored by is going to give me the elixir to get me through to my number. The people mentoring you are there to guide you along, maybe help fill in the gaps and hopefully extend your skills. Thing is, and this hit home during some of the initial mocks and moreso after the first defense, if I was putting my hand up for being grilled by a panel of veterans, I must know the following really well:
- How a design decision could potentially affect the outcome of another design decision.
- In-depth technical detail of a design decision (when asked).
- Risks that were created as a result of design decisions (not as a result of un-validated/un-managed assumptions, which is a significant pitfall)
- How constraints and requirements shaped the solution.
- Justify, succinctly and precisely, how SLA requirements were met.
You may see a pattern developing – all of this revolves back to the enterprise level design skills bit I mentioned above. What I essentially mean here – do not, repeat – do not, expect to be hand-held through the process.
Third, get design experience. Pretty obvious one right? Three of my favourite VCDXs got to this level of certification without a ton of design experience (if you read this post, you know who you are!). When I started on this journey, I was like – if he can, I can too. See, everyone’s different. Everyone has varying levels of experience, conviction, speaking and presentation skills, style and the X-factor. These three people have got the X-factor in spades and a good amount of these other qualities. I lack the X-factor and possess the other qualities to some extent. In order to get the experience I joined ANZ Bank and eventually VMware PSO (the experience has been great), to get the conviction I’ve had to do a ton of mocks, to get the speaking and presentation skills I’ve been whiteboarding solutions for customers (thank you PSO), and to get some of the style I’ve been whiteboarding at a home a whole lot. I’ll probably develop a little amount of the X-factor over the years.
Four, get into a study group and mock with the group and with others too. Ensure some of the people you work with are current VCDXs since they’ve been through that blender of a defense and bender of a journey. They know what it takes. Mock with multiple people to get that breadth of experience. We’re very lucky to be part of a community where just about everyone is willing to give you a hand. Reach out to people like Gregg Robertson who run a Slack study group for the VCDX. The VCDX directory lists a lot of people who’ve kindly agreed to be a mentor (you can filter the directory for mentors).
Five, don’t let anyone tell you – You cannot do it. Or it’s too hard or that you don’t have what it takes. This happened with me. Your family (spouse/partner etc..) may probably be the first to sow that seed in your head, or it might be the person you’ve put on a pedestal or it might even be the voice in your head. Uproot that seedling/seed and throw it away. If you have the drive (not willingness nor motivation because these two impostors come and go) to go the distance, put those hard yards in, fail miserably (hopefully just in the mocks!), learn, fail miserably again, learn, improve. Will Smith says – Skill is only developed by hours and hours of beating on your craft.
Six, I’ll save the best for last (and cover in Part 2). Business requirements and how the solution facilitates reaching those objectives. That’s what it’s all about in both the defense and the design scenario. Don’t throw in NSX when it’s not required. Or vROps when the solution would do just fine with vCenter monitoring. The justification for a design decision shouldn’t say, something integrates with something really well. It’s great two components talk to each other effectively but does the integration satisfy a business need or solve a problem? Does a stretched cluster provide RPO = 0 for a solution which actually could work with DAG-like application clustering? Does the solution you’ve proposed reduce possible objectives such as reducing time-to-market, automate services, reduce capex and opex, satifsy auditing requirements and the like? Point is, all justification MUST relate back to a desired business outcome.
In Part 2 of the blog series, I’ll cover those things where I blew my chances of getting myself on the VCDX directory.
Leave a Reply