Preparing for the VCDX Panel Defense: The Design

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 blueprint¹. 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. 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 templates² 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.

Method

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.

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.

Traceability

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

#	Title	Description
R101	Portal	The consumer has the ability to deploy services from a catalog.
R102	Portal	Expose an API for end users.
R103	Service Tiers	The system provides two tiers of service: tier 1 for production workloads and tier 2 for development/test.
R104	Networking	Provide each tenant with a direct network connection and the capability to provision multiple isolated networks.
R105	Catalog	Provide a global catalog of templates and ISO media.

Table 3.2. Categorizing Constraints

#	Title	Description
C101	Server	The target host is a blade server (16 cores, 64 GB memory,2 CNAs1).
C102	Cluster	The total number of hosts is 16 (4 per chassis).
C103	Storage	The target storage array is FC (gold) and iSCSI (silver) storage.
C104	Networking	Available network bandwidth is 10 Gbps.
C105	Billing	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

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

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?

Assumptions

• 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

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.

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.

Justification

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.

Impact

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.

Localization

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

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