Sean Crookston

Knowledge

• Identify appropriate best practices related to a proposed design.

• Associate a role to the information that needs to be collected.

• Differentiate between the general concepts of a risk, a requirement, a constraint, and an assumption.

Skills and Abilities

• Given a business ask or request, determine whether it is a risk, a requirement, a constraint, or an assumption.

• Given an organization, evaluate and respond to common inherent risks, constraints, and/or assumptions.

Tools

• Developing Your Virtualization Strategy and Deployment Plan

This objective focuses on risks, assumptions, and constraints. The topic is fairly straight forward and short and the recommended reading from the Tools section of the blueprint is a great overview or these topics.

Looking at risks, requirements, constraints, and assumptions it is important to make sure you know what the differences are amongst them.

A risk is an implication that may occur as result of a design decision. Risks also put the design at risk of reaching its goals. Some smaller companies may choose to not use vCenter, and maybe even deploy on just a single host. This leaves a management risk in the case of vCenter or a redundancy/HA risk when using just a single host. Larger companies may choose not to or not be able to financially back redundant network solutions for their virtualization solution. This of course leaves a single point of failure in the design and should be identified as a risk.

A requirement is a necessary outcome from the design. A requirement may be to repurpose existing hardware into the solution or to provide a disaster recovery solution using Site Recovery Manager to allow a recovery in less than one hour in the event of a failure.

A constraint is a limitation to the design. A project may have certain time constraints or there may be certain monetary constraints to the overall design. Perhaps even the implementation in question is for a business that has regulations requiring federal or other governmental approval.

An assumption is a set of assumed information about a particular aspect of the project. Going into a client it may be stated that there is network redundancy or that there is the necessary network bandwidth to support the virtualization solution. Since this may not be provable by the implementer this should be stated in the list of assumptions for the design. Another example of an assumption may be that all workloads (production/dev/test) will reside on the same cluster of hosts. Assumptions should be listed for a range of things from cost of goods and services for the project to configuration of infrastructure items. You may even list assumptions that the existing staff will receive a certain training to support the infrastructure ongoing or perform certain parts of the implementation.

Another item mentioned for this objective has to do with roles. Roles should be dictated which can be thought of in terms of responsibilities. Roles are created so that certain tasks for the project can be assigned and completed. Some example roles might be Storage Engineer, VMware Engineer, or Database Administrator.

The recommended reading for this objective in the tools section is a good start to going through the items mentioned within this objective.

• VCAP-DCD Tips and Exam Experience
• To Wait or Not ? : The vSphere 5 Certification Debate
• VCAP-DCD VCDX Discussion or Study Group?
• Objective 2.3 – Define Logical Storage Design
• VCAP-DCD Objective 2.2 – Map Service Dependencies
• VCAP-DCD Objective 2.1 –Map Business Requirements to the Logical Design
• VCAP-DCD Objective 1.2 – Gather and analyze application requirements
• VCAP-DCD Objective 1.1 – Gather and analyze business requirements
• VMware vSphere Design Workshop Review
• VMware vSphere Design Workshop Preview