Random thoughts and technical bits

Advice to VCDX candidates from a Double VCDX

“Sometimes it’s the journey that teaches you a lot about your destination.” – Drake

Update: I have updated the wording on the constraints section to reflect a Twitter comment from Martijn Baecke‏ thanks for the fix to wording and reading.

The VMware Certified Design Expert certification (VCDX) represents the highest tier of VMware’s certifications. I recently contributed to a panel of VCDX’s at VMworld. Candidates considering the VCDX certification had the opportunity to ask the panel questions. The questions illustrated that candidates were concerned about the Herculean effort required to achieve the certification. I wanted to take this opportunity to provide some guidance I have learned as a mentor. I believe anyone can become a VCDX. It does require some hard work but it is very achievable.

Requirements, Constraints, Assumptions and Risks

Becoming a VMware certified design expert does not mean you have to be the most technical person in the room. It does mean you have to know how to align technology to business needs. My experience has taught me that I can tell if a proposal for VCDX will be successful right away based upon requirements, constraints, assumptions and risks. The ability to gather business and technical requirements is a key skill for any design expert. Your technical requirements should be aligned to the business requirements. It’s important to understand the difference between business and technical requirements:

Business Requirements – Defines how the delivered product provides value. Other words often used are outcomes, or expected benefits. For example, the solution must meet regulatory compliance.

Technical Requirements – Defines the technical “must haves” to achieve the outcome. For example the solution must be able to fail over and fail back from a disaster and support a RTO of four hours.

Many VCDX documents are solely focused on technical requirements and miss the “why” that drives the design. Understanding the difference between requirements and constraints is another challenge for many candidates:

Requirements – Things the design mustmeet, such as: establish a RTO of four hours or provide capacity for twenty percent growth for the next three years.

Constraints – Things that form limits or boundaries that apply to the design. For example a specific vendor relationship or reuse of current hardware. Constraints should be met by the design unless they are resolved via conflict.

Once you have established your requirements and constraints you are left with assumptions and risks:

Assumptions – things you believe to be true but cannot verify. For example, storage usage will grow at the same rate as compute usage or the sample data provided represents reality.

Risks – are simply risks to the project meeting business requirements. If you identify risks they should be provided in this section. Every project has risks. For example, staff skills or timelines.

Correctly creating requirements and constraints that align with the elements of design are critical to a successful submission. Identification of assumptions and risks provide important protections to the architect. The goal of a VCDX design is to align technology to meet the requirements and constraints not provide the best technology mix.

Elements of Design

When working with infrastructure, VMware has designated five elements that should be considered in each design choice. Each design choice should be evaluated against the elements of design for impact. I personally like to use the acronym RAMPS to help me remember these elements:

Recoverability – Choices effect on disaster recovery

Availability – Choices effect on SLA

Manageability – Choices effect of management cost

Performance – Choices effect on performance

Security – Choices effect on security

It is not uncommon for availability, recoverability, security or performance to have a negative impact on manageability. Not all choices can have a net benefit to all elements of design. The tie breaker with these conflicts should be the requirements. Conflicts between design elements may exist even after evaluating the requirements. This allows for a conflict resolution section. Conflict resolution is where the customer of the solution acknowledges the conflict and mitigates the conflict in some form. Make sure your design has conflicts. Each requirement and constrain should be aligned to an element of design. When gathering business requirement, consider the RAMPS impact of each requirement to help gather a full list of requirements and constraints. Each technical requirement or constraint should be aligned to a single element of RAMPS.

Fun with Formats

Every single candidate struggles with document format. The VCDX requires far more detail than most designs in enterprise. Format paralysis has slowed if not stopped many candidates. My suggestion is identify an outline that aligns with the blueprint.

Overview

Requirements, constraints, assumptions and risks

Conceptual architecture

Logical architecture

Physical architect

Security

Appendix

Each of the different layers of architecture should address the sub elements: compute, storage, networking, applications, recovery, virtual machine, management, etc… You cannot provide lip service to conceptual and logical architecture. They must be developed just like physical architecture. Design choices should be justified against RAMPS, with conflicts identified. The secret is to determine a format and start writing, don’t get stuck on format. In the end, the format is not as important as the content assuming the reviewer can locate the items required in the blueprint.

Time Management

Every candidate struggles with time. We have family, friends, hobbies, faith and work conflicting with the VCDX goal. My advice is to set a goal with a timeline. Agree upon a set time each day. Exercise discipline to work on the VCDX during that time and you will achieve your goal. For me I used 8:00 – 9:00 PM each night. It was after my kids’ bed time and before spending time with my wife. I had to sacrifice computer game time, my guaranteed wins from p4rgaming.com, social media time and blogging time, but after six months I was done. This model has worked for me to achieve two VCDX certifications and put me on the path to my third. I’d like to end where I began. I believe everyone can achieve this certification with hard work. To start get a mentor by visiting vcdx.vmware.com and searching for a mentor including me.

Great article. In the military when we brief our staff, the question “So what?” comes up a lot. The reason is that we are often very good at stating our piece of the pie technically, but we don’t state how that relates to everyone else. I can lay out all of the technical reasons why I made a decision or recommendation, but if I don’t add in the ‘so what’ piece, then a key piece of information has been left out. That is why I liked how you pointed out the business VS technical side. It is essential to point out the value of a choice, or present the customer with the ‘so what,’ so that they can make a choice and be satisfied with the results.

About Author

Joseph Griffiths is a virtualization focused solutions architect who works with complex cloud based solutions. He currently holds many IT certifications including VMware VCDX-DCV and VCDX-CMA #143. This blog represents his random technical notes and thoughts. The thoughts expressed here do not reflect Joseph’s current employer in anyway. You can follow Joseph on Twitter @Gortees