How to earn VCDX-CMA Badge

Published: April 4, 2022 Architecture General vRealize-Suite

Hello Everyone, after a long gap I am back at blogging. One of the reasons of my absence was my VCDX journey. In this blog I will detail the lessons I learned during my journey in the hope this will help others in their journey.

There are several areas which needs separate mentions. In the subsequent areas I am going to cover each such areas.

Please note all the points are valid assuming you qualify for the VCDX exam. Which requires you to procure VCIX certification in the particular stream.

Time Needed

The first and foremost question, how much time should you dedicate for this? Answer varies depending on your expertise and comfort level with the technologies. There are two parts in the documentation aspect, design document and presentation for defense.

Design documentation

Documentation takes most time. Typically, you can finish the documentation singlehandedly within 3 months. Shorter, if you are working in groups. Also, it will take less time if you are using an existing project design for VCDX and can reuse the documentation from it.

Majority of the time goes into/should go into preparing the actual design document. But you need to cover the following documents as well.

Installation, Configurations & Operations Guide
Validations Guide
Project Timeline

Again, you can reuse if you already have such documents from existing projects. You need to dedicate at least a week's time if you need to prepare these documents a fresh.

Presentation preparation

Once you submit the documentation package and provided you covered all the required areas, you can start preparing for the defense presentation. You will get little more than 2 months to prepare for the defense. In most cases you need to go through multiple repetitions, so, start well in advance.

Overall, at minimum it requires 3 months. Depending on the status of your preparedness it may be more. For me, it took more than a year of hard work and multiple repetitions to crack the code.

Design

This certification revolves around checking the candidate's capability to successfully design an effective solution to customer problems/use cases.

Keep the following points in mind while building that design.

To-do

The blueprint is your ultimate doctrine. Read and follow the blueprint thoroughly. Your design needs to cover each aspect from the blueprint. If you miss an area, you are going to lose points on that.
Choose a design which comfortably covers all the areas of the blueprint. In reality, it's hard to find a single project which covers all the areas. In that case, logically club multiple projects to get a single design covering all the areas.
The above point is not valid for a complete fictitious design.
Though there are instances where a complete fictitious design was successfully defended, it becomes difficult to do it. Specifically so, if you do not have extensive architecting background.
Think about the business use cases first. Everything needs to revolve around that. A successful design is not about only technicality, or how clever the solution is. It is all about how you solve the business problems and achieve the defined use cases through your solution. Remember, if there is no requirement, technology cannot be there.

Mine was a fictitious design with few aspects taken from multiple projects and other areas completely made up.

Pitfalls to avoid

While creating a solution try to avoid the following pitfalls. I learned them the hard way. May be you will not make these mistakes, but, still it is best to remind these.

Always remember, elegance in simplicity.
Avoid a very complex design. It bulks up the whole design (not needed) and also it does not get any extra brownie points. The main problem, while defending such solution, is, it will be very hard to explain all the points within the given time. So, while it is important to have a fairly complex design, do not make it extra complex.
Do not make the solution too simple. A too simple design will also not show mastery over the subjects. So, put elements which shows your mastery.
The requirements, assumptions, constraints all need to align with the business use cases. This is specifically true for fictitious designs. For such designs, we take liberties and to make it more interesting, we add points which does not always align with the main use cases. Avoid such traps.
Specifically for CMA, many of the candidates think the design does not need infrastructure details (sizing for hardware, storage, network details etc.). This is wrong. The blueprint mentions and it is expected of you to include those portions. Without it, it will lead to a failure. So, though it is for CMA, you would still need to show the underlying infrastructure details. Not at the detailed level DCV candidates would have, but nevertheless it is required.
Implementation document does need to include installation screenshots and details. A reference to VMware documentation is not suffice.

Design should be simple, cover all the areas in blueprint and revolve around the use cases.

Defense

If you follow the above guidelines, then surely you will sail through the first phase. Easy part is done, next comes the hard part (defense). The defense happens in two segments, design defense and design on-the-fly. I will talk about them this section.

Design defense

This is the part where you defend your design. Note the following points regarding this section.

To-do

Prepare a presentation which covers all the aspects of your design within 15-20 slides. Keep the high level points in the main slides. Put the details in the backup slides.
Simon Z. (#VCDX-294) gave me a very good suggestion. He suggested, the presentation to be like a pre-sales presentation. It did help me to sort out my PPT.
Your design will have many uses cases, requirements, assumptions, constraints etc. Pick the top 3 in each category and talk about them.
Thumb of rule, pick those points which covers your design, at the same time points out how the design is different, shows your mastery over the topics.
Risk management is very important. Not only show the risks for the project, but also the risks arising from the decision points and how you handle them.
Availability, manageability, performance, recoverability and security (A.M.P.R.S) are your guiding stars. Everything you talk about should lead to solving the business use cases, but all the while how each point fairs with respect to A.M.P.R.S.
Mind-set, be relaxed. Remember the panelists are there to understand the design and your reasoning behind it. They are not there to judge you.

Pitfalls to avoid

Remember the first rule, this is a pre-salesy presentation. While you need to cover all the aspects and it is inherently technical, but at the same time, at first glance, it should be from 30000 ft view. Upon further questioning in an area go to 20000ft, then 10000ft and finally from ground zero. Point being, do not jump into the deep end of the technology pool. You will not find enough time to cover everything. Plus you will be digging holes for you. While you many know many things, there are three panelists who are experts from different areas. So, there may be areas you want to avoid. Keep that in mind.
If you do not know something, be upfront about it. Do not waste time or try to gaslight them. They are experts and you cannot bluff. So, after going to 10000 ft deep you can say I need to further check or something like that. But that is ok for added questioning in an area. It should not be for an important decision. For example, while selecting storage for an application, you need to know about different RAID levels, write penalties, why you should choose one over another etc. But you can skip about how parity is calculated (if it is ever asked).
Do not be argumentative / confrontational / defensive. You do not need to argue about your choices. Be open about it. Think of it as a discussion where you are trying to explain a solution to a customer. If a panelist asks a question, it is not to challenge you. It is to understand why you made that decision and alternatives if there are any. Be open about the choices. I cannot stress this point enough. I talked to enough people who failed. Most of the times we complain about technical stuff while it is not about technicality. It is because we could not convey those points clearly.

Design scenario

While defending your design is very important. Design scenario is more so. The reason being, this is your last chance to score points. If you miss certain areas or score less in your defense, this is the time to cover that up. In general, you will get a design scenario which will give you a chance to do just that. Remember the following points.

To-do

Practice the structure. A good starting point is to write out the headings for "use cases", A-M-P-R-S, assumptions, constraints and finally risks. If you write the headings/categories, you will remember to ask questions from each area. That would cover the questioning part. Chances are, you will not miss anything. It will also show the panelists about yours systematic approach.
While designing, always refer back to the use cases and requirements and how your design will cater to these points.
Talk about how you will tackle the risks and the mitigation plan.
All the while answering questions from panelists. Pick up where you left and come back to those points.

Pitfalls to avoid

Do not be haphazard, be systematic in your approach.
Expectation from you is to not give a complete solution (conceptual, logical & physical), but to provide a logical solution covering the areas. So, cover till that point and cover well. You should not have gaps in these.
If the panelists are asking questions, pay attention. They are asking questions because they want to score you in that area. So, answer it completely and satisfactorily and then come back to your design.
But avoid going into the technical hole. Remember, you need give a complete logical solution covering all the main areas.
Do not be rigid in your approach. Be flexible.
Show choices / alternatives/ options in every area. Mention the alternatives and the choices you are making and the reasoning behind them. For example, between an on-premises solution vs SaaS solution which one you will choose and why.

Parting thoughts

Be relaxed, I cannot stress this enough. More than technicalities, the ability to have an open discussion is more valued for an architect. Forget about the panel and VCDX defense, present the solutions exactly like you would do to a customer. I was over preparing and going through so many things, it put extra pressure on me. I put myself under a mountain and pigeonholed myself. The moment I was able to relax and be open about it, I cracked the exam. For me, it was never technicalities. I know my stuff and more. But since I was under so much self-inflicted pressure, I panicked and went into auto-pilot mode. Which is a highly technical person but not an architect 😀.

Though it is said many times "the journey teaches many things, rather than the target", for VCDX, it is so much more true. The journey will give you new perspectives. It will change you.

An Architect is not about not making any mistakes, but being able to see the mistake, acknowledging and rectifying it. The moment you will be able to identify your own mistakes and acknowledge it, you are an architect.

VCDX is a certification which tests whether you are an architect or not. It does not teach you to be one (unlike other certifications like TOGAF). But, if you take that journey and pass, then for sure you are an architect.

So, take that up. Be ready for the journey, be ready to learn, to open your mind to new possibilities. The struggle is worth the reward. Best of luck!!!.