Home > Articles > Certification

Preparing for the VCDX Panel Defense: The Design

📄 Contents

  1. Assembling Your Design
  2. Summary
This chapter illustrates the steps to developing an architectural design document submission to help prepare for your VCDX panel defense.

Read VCDX Boot Camp: Preparing for the VCDX Panel Defense or more than 24,000 other books and videos on Safari Books Online. Start a free trial today.

This chapter is from the book
  • Good design is good business.
  • —Thomas Watson, Jr.

The proficiency displayed in the application package determines whether a candidate is offered the opportunity to defend. Words and diagrams poured into the design are the first impression made to prospective panelists and the element that you have the most control over. Most critical is the architecture design document, the keystone piece that drives the other components. Invest the time to ensure completeness and accuracy of the submitted design, as this translates into time saved in the design defense. Strive for maximum readability and flow through the submitted material.

Prospective candidates often ask about the required complexity of the submitted design. There is no stated requirement on the number of pages in the design document or the approximate size of the solution. However, common sense dictates that a smaller scale design makes it difficult to demonstrate architectural skills. Enterprise scale is an ideal, a solution that necessitates the participation of numerous stakeholders and architects. Select a design with sufficient complexity that demonstrates the depth and breadth of knowledge and skills relevant to designing a solution.

Assembling Your Design

When starting a design, review the appropriate blueprint areas. Ensure that your design decisions are aligned with the requirements and constraints. A printout and a red pen come in handy here. Multiple reviews help identify areas of accomplishment and areas of deficiencies. If you do not find any weak points, solicit a trusted peer to review your work. Afterward, adjust your design to improve the weak areas. Rinse, repeat.

VCDX Design Defense Blueprint

The Design Defense Blueprint is your guide to the process and requirements to achieve certification. The VMware certification website has a unique blueprint for each VCDX variant.

Blueprint Outline

Here is a summary of the major sections of the blueprint1. Refer to the blueprint for your defense version for details.

  • Purpose and structure of the VCDX certification
  • Intended audience
  • The application and defense
    • Format and structure of the defense
    • Procedures and policies
  • Objectives covered in the design defense
  • VCDX paths and supporting courses
  • Path from customer requirements, to solution architecture, to engineering specifications (see Figure 3.1)
    Figure 3.1

    Figure 3.1. Customer requirements → solution architecture → engineering specifications.

    • Customer requirements (supports the conceptual model)
    • Solution architecture (logical architecture)
    • Engineering specifications (physical architecture)
  • Implementation guidance—includes the following:
    • Deployment plan
    • Installation guide
    • Standard operating procedures
    • Validation and test plan

This blueprint is a starting point that outlines the requirements and provides foundational guidance for maximum scoring potential.

Core components of a submitted design include a design document that presents requirements and an architectural solution. Supporting material includes an installation guide to match the design along with a validation plan. Provide more than just basic items. A simple test plan may miss important validation steps that could result in failure of the implementation.

Those with access to design templates should remember that these are a starting point and do not include a full set of requirements and constraints that determine the final architecture. Use of service delivery templates2 does not guarantee success. Providing a complete design that meets the blueprint areas is what determines your results.

Panelists spend approximately four hours reviewing each application and submitted documents. That potentially adds up to twelve hours of review time per candidate! They inspect all documentation and develop clarifying questions for use during the design defense.

What Panelists Look For

Know why you chose to use a specific option; understand why you did not choose the other available options.

  • —Frank Denneman, VCDX-029

First, panelists look at design requirements, constraints, assumptions, and risks. Subsequently, they review the design, looking for design decisions and patterns that support the requirements and constraints. Aspects such as consistency, accuracy, and supportability of the design are considered.

Include requirements, constraints, assumptions, and risks in a dedicated document or within the architecture design document. One approach is to create an indexed table for each of these categories to simplify referencing.

The submitted design and related documents should include:

  • Compute
  • Networking
  • Storage
  • vCenter Server
  • ESXi server
  • Virtual machines
  • Security
  • Business continuity and disaster recovery
  • Monitoring
  • Upgrades
  • Capacity planning
  • Standard operating procedures
  • Additional management components

Submit a sufficiently complex design that demonstrates architectural skill. Doing so often leads to interesting conversations that can lead to higher levels of success.

  • The more you can include in your design, the better conversations can be had with the panelists. Your goal isn’t necessarily to wow the panel with your documented solution as much as demonstrate your ability to take requirements and generate a solution.
  • —Doug Baer, VCDX-019

Using “best practices” requires you to know the background behind the best practice and how it applies to this situation. This is not a knock on best practices since they are a useful pattern in designing large infrastructures. As designs evolve, best practices may follow. If you have a customized design best practice, provide the support (that is, examples from past work experience).

  • The answer to a question can never be ‘because it is a best practice’—know why this is a best practice, and know why it met the requirements of your customer!
  • —Duncan Epping (VCDX-007)

Validation and test plans justify the implementation, ensuring it functions as expected. These typically include testing of the virtualization platform, management tools, infrastructure components, and advanced features used. If you add design-related material for other VMware technology areas, include installation and validation plans for them. Validation plans can include functional, performance, and utilization considerations.

If using unique design patterns and best practices, provide the justification and impact. Call out the creative approach during the defense overview presentation. Top performers consider extensions to the design to meet additional blueprint requirements. This can be a slippery slope, as you are responsible for justifying all content in the application.


Today, there is no published standard architectural method when it comes to virtualization and VMware technologies. Internally, there are several frameworks under continuous development. Gradually these frameworks have de-emphasized technological aspects while adopting elements of software design and enterprise architecture. The method in Figure 3.2 describes a framework that has proven helpful in developing an architecture specific to a customer’s needs.

Figure 3.2

Figure 3.2. Phases for developing customer-specific architecture.

At the outset, the Vision phase outlines the overall business goals, architecture scope, and key stakeholders. The baseline and target states for the architecture may be described here.

In the Architecture phase, the logical design is constructed through analysis of requirements and constraints collected from various stakeholders.

The Plan phase covers the physical implementation details for deploying the architecture. Depending on the scope of the project, the architecture is built and validated in one or more Transition phases.

Finally, the Manage phase covers proactive monitoring and management of the deployed architecture.

In all phases, there is periodic validation of project outputs to requirements. New requirements or technology might necessitate a design change. Architecture design is an iterative process, over the entire method in one or more transition phases.


A signature of good designs is the linkage of design choices back to high-level goals. The first step is categorizing and prioritizing various customer inputs. After capturing the inputs, map design decisions to business requirements, technical requirements, or constraints. Document assumptions and risks, especially if they will have a significant impact on a design. Good organization is essential when developing a complex and thorough design. Tables 3.1 and 3.2 provide examples of categorizing requirements and constraints.

Table 3.1. Categorizing Requirements






The consumer has the ability to deploy services from a catalog.



Expose an API for end users.


Service Tiers

The system provides two tiers of service: tier 1 for production workloads and tier 2 for development/test.



Provide each tenant with a direct network connection and the capability to provision multiple isolated networks.



Provide a global catalog of templates and ISO media.

Table 3.2. Categorizing Constraints






The target host is a blade server (16 cores, 64 GB memory,2 CNAs1).



The total number of hosts is 16 (4 per chassis).



The target storage array is FC (gold) and iSCSI (silver) storage.



Available network bandwidth is 10 Gbps.



An existing internal billing system is used.

Resolving Conflicts

At some point, conflicts in the pool of requirements, constraints, assumptions, and risks may exist. Let’s look at how these relate to each other and consider how to resolve conflict.

Some candidates create a table of all major design decisions that reference the section and page in the submitted material that contains further details. This approach offers multiple benefits. It is easier for a customer, a reviewer, and the panelists to identify the decisions made and locate the supporting material. Remember, a table does not replace documentation. Other reference information can include tables of figures, diagrams, and data tables.


Requirements describe, in business or technical terms, the necessary properties, qualities, and characteristics of a solution. Customers provide requirements that form the basis for the design. If particular requirements cannot be met, they are marked accordingly in the appropriate section of the following table and further in the documentation. Use a consistent approach for documenting requirements. This simplifies identification and cross referencing.

Sometimes requirements conflict. For example, a customer requirement may state that the disaster recovery site support the same Service Level Agreements (SLAs) as the primary site. Another requirement stipulates an RPO of five minutes and an RTO of one hour. Address and resolve design conflicts. Requirements can evolve through discussion and negotiation. Documentation on these changes supports traceability and accountability. Include the justification and impact of the changes.


Constraints can limit the design features and the implementation of the design. The most common example is a customer sticking with a preferred vendor or preexisting technology. Constraints influence requirements for the project, requiring compromise.

  • Think about the constraints in your current design and which changes you would have made if these constraints were lifted.
  • —Frank Denneman, VCDX-029

Without constraints, design would be easier but also much less interesting. Think of constraints as challenges, rather than barriers. How distinctive would Twitter be without the 140 character limit?


  • Erroneous assumptions can be disastrous.
  • —Peter Drucker

Assumptions are expectations made during the design phase about the implementation and use of a system. Since assumptions cannot be confirmed initially, they pose risks to the design if left unaddressed. They are implied by the requirements, constraints, standards, experience, and best practices used. Examples include hardware/software compatibility requirements or sufficient network bandwidth needed to support an expected performance level.

  • In the absence of factual information, you may need to make an assumption. This should be an educated guess and preferably based upon other available factual information or evidence. For example, if you are building a new vCloud Datacenter offering, how do you know how many concurrent users might connect to each vCloud Director cell? You don’t! So you have to make an educated guess (assumption) based on experience, add it to a risk register, and have a mitigation plan in place for if your guess proves incorrect. In this case, the mitigating action(s) could be that you over deploy the number of vCloud Director cells or that you simply monitor the concurrent users and deploy when load exceeds the desired threshold. It then falls into the operational/capacity planning activities to manage this moving forward. Not all assumptions need to be validated in order to complete a design, but they do need to be managed.
  • —Aidan Dalgleish, VCDX-010


Risks may negatively impact the reliability of the design. This can include people, process, or technology risk. For instance, lack of training may hinder day-to-day operations, whereas a single point of failure in the solution stack impacts SLAs. Document risks to the project along with the appropriate mitigations.

Sizes Matters Not

Some submitted designs have exceeded 500 pages; others consist of less than 200 pages. Again, there is no minimum or maximum page requirement. Reflect on your experience and surmise what an enterprise customer expects from a fully fledged plan and design service engagement.

If using pre-existing design templates, we expect customization of templates to meet the blueprint requirements and ensure that all design decisions, patterns, and impacts are captured. Adding superfluous content to pad a design document is not always a wise strategy. The design should provide a solution architecture that meets the customer’s requirements and constraints.

Design Artifacts

The text and diagrams that accompany your design serve to elaborate on core design principles and decisions. Simplicity and purity are favored over glitz. What matters is being able to convey the rationale behind a decision, not a fancy diagram that detracts from readability. Useful diagrams are unobtrusive, self-explanatory ways to clarify structure.

What Makes for a Good Design?

A good design meets requirements with the appropriate technology and operational guidance to match a schedule, staffing requirements, and budget. Understanding and documenting the reasons for each decision must factor in the requirements, the constraints, and the technology influencing the solution.

When developing design decisions and design patterns, consider those that go beyond simplistic and standard choices. One example is to extend basic NIC redundancy by providing details on the use of load-based teaming, network I/O control, or Link Aggregation (LACP) on a distributed switch.

Include the conceptual model, logical design, and physical design. Successful candidates include all three in their design. The conceptual model maps the requirements and constraints used to influence the logical design. The logical design provides the platform to make technology choices. The physical design provides the details and configurations of the technologies used.

Although candidates have passed without demonstrating a formal progression from conceptual models to logical and physical designs, we recommend that you include all three to provide better insight into your design strategy and progression in developing the solution.

Conceptual Model

The conceptual model of the design includes customer requirements and constraints. It also includes assumptions that are implied and relevant to the design.

When creating the design, map requirements, constraints, and assumptions into one or more of the following design qualities.

  1. Availability

    Requirement: Deliver highly available operation, as measured by percent uptime of relevant components.

  2. Manageability

    Requirement: Provide ease of managing the environment and maintaining normal operations. Subqualities may include scalability and flexibility.

  3. Performance

    Requirement: Deliver the standards of responsiveness of components of the desired environment to meet the application workloads deployed and SLAs specified.

  4. Recoverability

    Requirement: Provide the capability to recover from an unexpected incident that affects the availability of an environment.

  5. Security

    Requirement: Provide overall data control, confidentiality, integrity, accessibility, governance, and risk management, often including the capability to demonstrate or achieve compliance with regulation.

These five design qualities apply to each VCDX track, as illustrated in Figure 3.3.

Figure 3.3

Figure 3.3. Relationship models.

The panel looks for your ability to build relationship models among the design components to create solutions based on these mappings. The models include, but are not limited to, components involving the following:

  • Cloud, desktop, and/or virtual datacenter management technologies based on the intended VCDX track
  • Computing resources
  • Storage resources
  • Networking resources
  • Virtual machines and vApps

Logical Design

Recognize that “logical” does not mean “physical” where the physical implementation details are included. For VCDX, we have acknowledged a hybrid approach with known constraints, including the use of VMware vSphere as an underlying component. This is acceptable. If you specify versioning information (that is, VMware vSphere 5.1), you are now providing configuration and versioning details that constitute a physical design. Understand that the progression from conceptual, to logical, to physical demonstrates the journey you take from the abstract vision to the specific details. Focus on the conceptual and logical levels first to ensure that the final physical design meets the requirements for expected functional results. A hybrid approach will not result in deductions as long as the candidate understands that this is a mixture of logical with some physical design elements.

Most successful candidates include both the logical and the physical design components.

  • They provide guidance on how the logical design relates to the requirements.
  • They address the selection of the physical components to meet the logical design.
  • They provide a physical design that guides the implementation process.

Physical Design

The physical design includes the implementation details, including choice of vendors and technologies. This is where the logical design turns into a design specification for implementation. We recommend including a “Bill of Material” that lists the software and hardware components along with any necessary training necessary.


What compelling requirement, constraint, assumption, or risk mitigation drove your decisions?

“Just because” or “it is a best practice” opens the door to questioning your abilities as an architect. Best practices are not set in stone—nor are they the only option. Best practices evolve over time to meet specific use cases but may not be the best practice for all.

Panelists can ask for clarification on the best practice and details on why it is a best practice for the specific project. Validate the modified best practice, and show the impact of the change. Your justifications demonstrate support of the requirement and value of the solution.

Ensure that the decisions made concerning conflicts include justification, approval, and impact to other areas of the design. Incorrect design decisions influenced by weak requirements can lead to lower scoring. To score higher, provide details on conflicting requirements. Call out the choices made for each requirement. Provide details and merits of an alternative set of requirements that resolve the conflict.


How did the decision affect other areas of the design with respect to technology, risk, schedule, skills, budget, or other critical areas?

Justification does not equal impact. Impact can be both positive and negative. A higher cost might provide a more resilient solution and reduce risk. The return on investment (ROI) demonstrates the positive versus the negative. It includes financial, technical, and other components that could be affected by the decision.


Currently, application documents must be submitted in English. If you translate from another language to English, consider adding English reviewers to ensure correct translation of concepts. Translators and translation programs could differ in their final wording.

Perform design validation before submitting. This could include peer review, running a mock panel defense, or practicing with others by defending your design in English.

Checklist: Design Selection and Content

  • squ1.jpg Aligned with VCDX Blueprint
  • squ1.jpg Includes design considerations
  • squ1.jpg Includes design patterns
  • squ1.jpg Includes justifications
  • squ1.jpg Includes impact of design choices on other areas
  • squ1.jpg Includes risk analysis and mitigations
  • squ1.jpg Includes content beyond a basic template
  • squ1.jpg Reviewed by others to identify strengths and weaknesses

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020