Chapter 3. The Design

“What is to be sought in designs for the display of information is the clear portrayal of complexity. Not the complication of the simple; rather the task of the designer is to give visual access to the subtle and the difficult—that is, revelation of the complex.”

—Edward Tufte

Your entire application package, including your design, is your ticket to defending. The design is the central piece and drives the other package components. It is the first impression that you make to panelists and the element over which you have the most amount of control. Invest the time to ensure completeness and accuracy of your submitted design because this translates into time saved in the design defense. It must be easy to read and to follow through each piece of the submitted material.

Prospective candidates often ask about the required complexity of the submitted design. No requirement governs the number of pages in the design document or the number of hosts in the solution. However, common sense dictates that a small-scale design cannot effectively demonstrate architectural skills. Enterprise scale is an ideal solution that provides the complexity that necessitates the participation of architects or consultants. Select a design with sufficient complexity that demonstrates the depth and breadth of knowledge and skills relevant to designing a solution.

Your VCDX Design

When starting a design, review the appropriate VCDX blueprint areas. Ensure that your design decisions match the requirements and constraints. This is where a printout and a red pen come in handy. A critical review should identify areas of accomplishment and areas that require more work. If you do not find any weak areas, have someone else review your work at that point. When you have completed this review, adjust your design to improve the weak areas, and be sure to list the major highlights within the design.

VCDX Design Defense Blueprint

The VCDX certification recognizes design architects who demonstrate their skills in VMware enterprise-scale deployments for data center virtualization, desktop, and cloud.

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

Blueprint Outline

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

¹ Subject to change and update. See http://vmware.com/certification for the most current information and requirements.

• Purpose and structure of the VCDX certification

• Intended audience

• The VCDX application and defense

• Format and structure of the defense

• Procedures and policies

• Objectives covered in the VCDX 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 a conceptual model)

• Solution architecture (logical architecture)

• Engineering specifications (physical architecture)

• Implementation guidance of submitted design—includes the following:

• Deployment plan

• Installation guide

• Standard operating procedures

• Validation and test plan

The VCDX Design Defense Blueprint provides the areas that are important to the program and should be included in your design for maximum scoring potential.

This blueprint is a starting point that outlines the requirements and provides foundational guidance for a successful design. The blueprint is self-explanatory, but we provide guidelines on using the blueprint as your roadmap for a successful design.

Submitting and defending a design that uses “best practices” requires you to know the background behind the best practice and how it applies to this situation.

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 must justify the implementation, ensuring that it functions as expected. If you have access to default templates for a design, remember that these are a baseline 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; your work in ensuring a complete design that meets the associated VCDX blueprints determines your results.

² Teams use service delivery templates as a starting point for designs.

As the previous chapter explained, panelists spend approximately four hours reviewing each application and submitted documents. That is up to 12 hours of review time per candidate! They look for complete designs, as specified by the requirements and constraints, and develop clarifying questions for use during the design defense.

What Panelists Look for in Your Design

Know why you chose to use a specific option; understand why you did not choose the other available options. —Frank Denneman, VCDX-029

Panelists are trained to first look at the requirements provided by the business, constraints placed upon your design (such as vendor choice), and the assumptions you make. They then review your design, looking for design decisions and patterns that support the requirements and constraints. Finally, they evaluate the design to ensure that it is technically sound.

Panelists review all documents for strengths and weaknesses and develop questions for further discussion during the design defense.

Plan to include requirements, constraints, and assumptions in a dedicated document or within the architecture design document. One approach is to create an indexed table for each of these categories. This makes for easy referencing by your customer and the reviewers.

This book stresses core areas that will drive your success. Core components of a VCDX submitted design include a design document with requirements and an architectural solution. The design should include supporting information for the design choices made. The design should also include an installation guide to match the design and a validation or test plan. Be sure to include more than just basic items. A simple test plan might miss important validation steps, which could result in failure of the implementation. Validation and test plans can include functionality, performance, and utilization considerations.

In the submitted design and related documents, you must cover the core components. These can include the following areas:

• Computing

• Networking

• Storage

• vCenter Server

• ESXi server

• Virtual machines

• Security

• Business continuity and disaster recovery

• Monitoring

• Upgrades

• Capacity planning

• Standard operating procedures

• Additional management components

You must cover all the requirements for the design. Remember to go beyond simple designs that might not demonstrate all your skills. Demonstrating advanced design skills typically leads to interesting defense 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

Validation or test plans typically include testing of the virtualization platform, the management tools, the infrastructure components, and the advanced features used. If you also include design-related material for other VMware technology areas, you should include installation and validation plans for them. Integration considerations and testing must be included.

If you use new design patterns and new best practices in your material, provide the justification and impact. Your presentation during your defense should call out the creative approach you took while creating the design.

Top performers consider extensions to the design to meet all the VCDX blueprint requirements. If you choose this route, it can provide additional scoring opportunities but increase preparation time.

Design documents must meet the requirements defined in the VCDX blueprint and application.

Method

Today no de facto architectural method exists when it comes to virtualization and VMware technologies. Internally, several frameworks have been under development and have continuously evolved. Gradually, these frameworks have de-emphasized technological aspects while bringing over 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. 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 are defined 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 necessary 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 architect’s ability to link 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

Table 3.2. Categorizing Constraints

Resolving Conflicts

At some point, all architects have conflicts in the pool of requirements, constraints, and assumptions. Let’s look at how these relate to each other and considerations in resolving conflict.

Some candidates take a novel approach. They 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

The customer provides the requirements for the project. We recommend a consistent approach to listing your requirements and a high-level summary. This simplifies the process of identifying and cross-referencing them.

Sometimes requirements conflict. For example, in Request #1 (R001), the customer requires that the disaster recovery site support the same Service Level Agreements (SLAs) as the primary site. Request #2 (R002) must provide an RPO of 5 minutes and an RTO of 1 hour. Address and resolve design conflicts. Requirements can adapt through discussion and negotiation. Documentation on these changes supports traceability and accountability. This information should include the justification and impact of the changes.

As designs evolve, best practices can follow. If you have a customized design best practice, provide the support for this. Where possible, provide examples from past work experience.

Constraints

Constraints typically are immutable. However, exceptions do exist. The easiest example is a preferred vendor or pre-existing technology. Constraints can influence requirements for the project, which could require a 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

Assumptions

Erroneous assumptions can be disastrous. —Peter Drucker

The most serious mistakes are not being made as a result of wrong answers. The truly dangerous thing is asking the wrong questions. —Peter Drucker

Assumptions can pose risks to the relevant design area(s). They are typically implied by the requirements, constraints, standards, experience, and best practices being used. Examples include compatibility requirements and sufficient bandwidth. Confirm assumptions early in the process, to remove it as an assumption.

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 Data Center offering, how do you know how many concurrent users you might get connected 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 overdeploy 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

Longer Is Not Necessarily Better

Panelists have reviewed designs longer than 500 pages in total, provided within multiple documents. We have also reviewed designs of less than 200 pages total. Focus on your design content, not the length. Focus on your customer requirements first!

Although you might have design templates to start from, we expect that you will make an effort to meet the VCDX Blueprint requirements and ensure that you understand all design decisions, design patterns, and technologies used, as well as their impact on other areas of the design. Adding superfluous content to pad a design might not be a wise strategy. The design should contain the necessary information to meet the requirements and constraints and describe the required solution architecture.

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. Provide examples of your skills. 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.

Your design document should 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 VCDX 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 the 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 program area, as illustrated in Figure 3.3. They must manifest themselves in your design.

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 program

• Computing resources

• Storage resources

• Networking resources

• Virtual machines and vApps

Logical Design

The logical design focuses on the abstract layer without going into the details of a vendor, product, or configuration. When creating your design, it is important to recognize that “logical” does not mean “physical” where the details of vendor, product, and configuration are included. In the case of the VCDX defense, we have accepted a hybrid approach with known constraints, including the use of VMware vSphere as an underlying component. This is acceptable. If you instead specify 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. The architect focuses on the conceptual and logical levels first, to ensure that the final physical design will meet the requirements for expected functional results. Many designs take a hybrid approach. This does not result in penalties as long as the candidate understands that this is a mixture of logical with some physical design elements. Usually this happens when a specific technology component is known and is required for use.

Most successful VCDX candidates include both the logical and 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 is ready for implementation.

Physical Design

The physical design includes the implementation details, including choice of vendors and technologies. This is the place where the logical design turns into a design specification for implementation. We recommend including a “Bill of Material”, listing the software and hardware components required and specifying any training necessary for understanding, implementing, and operating the resulting solution.

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. Best practices for a majority might not be the best practice for some. Adapting a best practice to a specific use case for a specific project is valid.

Panelists can ask for clarification on the best practice and details on why it is a best practice for the specific project it covers. Be prepared for some deep-dive questions from the panelists if you take this route. Think first! 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. Poor design decisions influenced by poor requirements can lead to lower scoring. To score higher, provide details on conflicting requirements. Call out the choices 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 due to the decision.

Localization

Currently, only English-based applications are allowed. 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.

Validate your design 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

[•] Includes content beyond a basic template

[•] Reviewed by others to identify strengths and weaknesses

Summary

We have covered a lot in this section on the details of the panel defense, including recommendations for developing a complete design to present. The following is a checklist to use as you prepare for your defense. Several of these items are covered in more detail in their relevant chapters.

[•] Understand the timing and flow of the Panel Defense.

[•] Understand the requirements for the design defense (Chapter 5).

[•] Understand the requirements for the design scenario (Chapter 6).

[•] Understand the requirements for the troubleshooting scenario (Chapter 7).

[•] Know all aspects of your design.

There are three phases that a VCDX looks at for design. The first phase is the development of a conceptual model that maps the requirements and constraints used to influence the logical design. The logical design provides the platform to make technology choices. The physical design includes the implementation details with specific vendor, product, and configuration information.

Within a design, consider the justification and impact of a design choice. Justification supports a decision. Impact is the result of a decision. Justification can result in either a positive or a negative impact. Impact of a design choice occurs in other areas than the decision point. Impact can affect budget, technology, training, and other decisions.

Consider each of the items above when developing your design for submission. The panel looks at how you address these phases in your design, and how each design choice is justified.