VCAP6-DCV Design – Objective 1.1: Gather and analyze business requirements

Associate a stakeholder with the information that needs to be collected

Stakeholders should include representatives for all groups that are affected by the design, including the following:

  • A project sponsor (for example, the CIO, VP Infrastructure, or IT Director)
  • Virtualization architects
  • Business decision makers
  • Core technical teams, such as product development, server, storage, networking, security, and backup and recovery.

You interview stakeholders and conduct workshops to gather requirements and build consensus:

  • Asking the right questions is vital
  • Gathering requirements is an iterative process, which might require multiple rounds of interviews.

Utilize inventory and assessment data from a current environment to define a baseline state

Assuming one of the objectives of the design is the migration of workloads from an existing environment, one of your first engagements is to analyze its current state.

  • Use tools and automation to gather environment data.
  • This will reduce the data collection time and minimize the possibility of errors in the data you might otherwise collect manually or from people.
  • Leverage available tools such as:
    • VMware Capacity Planner
    • Windows Performance Monitor
    • VMware vSphere Performance Counters
    • Third-party assessment tools for storage and networking
  • You may also need to gather realistic estimates for future workloads that the design needs to cater for.

Analyze customer interview data to explicitly define customer objectives for a conceptual design

  • Conceptual design has a focus on achieving goals and meeting or exceeding the requirements.
  • Leverage the information from SME/Stakeholder interviews (Scope / Goals / Requirements / Assumptions / Constraints) and from information gathered in current state analysis.
  • Document the entities affected by area of the project (teams, users, applications, processes, physical machine, etc.)
  • Determine how the goals map to each entity.
  • Create an infrastructure design that meets and/or exceeds each entity’s goals and requirements, but stay within constraints – i.e. where do you need availability, scalability, performance, security, and manageability (AMPRS).
  • Document everything! e.g. diagrams, tables, and text.

Customer Information

  • Goals
    • Why are we doing this?
    • When do we need this done by?
  • Scope
    • Clearly include what is included and what is not included (In/Out of Scope)
      • (e.g. Disaster Recovery effort is out of the scope of the project)
  • Requirements
    • Business requirements (e.g. cost saving musts)
    • Technical requirements (e.g. consolidation, DR, VDI)
    • Legislative framework requirements (e.g. compliance)
  • Assumptions (Accepted as true but not tested / Not validated expectations)
    • Power and cooling for hardware is adequate
    • Foundation infrastructure such as DNS, Active Directory, and Time Services is in place and working reliably
  • Constraints (Limiting factors related to the design. Customer says that things must be done)
    • Reuse of hardware
    • Budget
  • Risks (May prevent project completion)
    • Not enough executive sponsorship
    • Has the budget been approved?
    • Is there a dependency on other projects?

Determine customer priorities for defined objectives

During the interview process focus on:

  • Asking project priorities
  • What are the drivers
  • Challenges
  • Ensure these are detailed in your requirements
  • Opportunity to remove anything from the project that is not required.

Ensure that Availability, Manageability, Performance, Recoverability, and Security (AMPRS) considerations are applied during the requirements gathering process

First of all, some definitions – taken from the VCDX5-DVC Blueprint, v. 2.6

  • Availability: requirements to deliver highly available operation in compliance with SLAs, as measured by percent uptime of relevant components.
  • Manageability: requirements for ease of managing the environment and maintaining normal operations. Sub-qualities may include scalability and flexibility.
  • Performance: required standards of responsiveness of components of the designed environment.
  • Recoverability: requirements for the ability to recover from an unexpected incident that affects the availability of an environment.
  • Security: requirements for overall data control, confidentiality, integrity, accessibility, governance, and risk management, often including the ability to demonstrate or achieve compliance with regulation.

Ensure the following design considerations are discussed on almost every conversation:

  • Availability (N+x)
  • Manageability (Reporting and alerting requirements)
  • Performance (Compute, storage, and network)
  • Recoverability (Backup, Replication, Restores)
  • Security (External and internal threats, encryption and permissions)

Requirements will be either functional or non-functional.

Given results of the requirements gathering process, identify requirements for a conceptual design

  • Use the current state analysis and requirements from interviews to contribute to the high-level design.
  • Once you have categorized business and technical requirements, go back to the stakeholders with a conceptual design.
  • Remember this is an iterative process. Make it count! Be inclusive!
  • Once the conceptual design is approved, you can move onto the logical design.

Categorize requirements by infrastructure qualities to prepare for logical design requirements

Gather all the requirements together and put into the correct category:

  • Availability: “Is website up and running?”
  • Manageability: “How expensive is it to keep the system up?”
  • Performance: “How fast does the webserver respond?”
  • Recoverability: “If a system crashes, how quickly comes online?”
  • Security: “Are the customers data safe?”

This will make creating the logical design a simplified and easier process.


Some of these are the official tools that appear in the Blueprint, the rest are resources gathered somewhere else.

VCAP6-DCV Design – Study Notes

I’ve been mostly a systems administrator for the last 10 years or so, and my (brief) experience with infrastructure consulting and design is far away in time. While it is true that, before that, my day to day job dealt with software consulting, customer’s requirements gathering and (mostly) programming, design requires a different skill set than the one I am now used to.

So now, after having some months ago passed VCAP5-DCA, I’m now in the mood for a challenge and I’m going for the design part of VMware’s datacenter certification portfolio: let’s do VCAP6-DCV Design!

From now on, I will be publishing here my study notes and links to resources, mostly for my own use but you are welcome to use them. Please take into account: this is a work in progress, and I will probably be editing some of the pages in a daily basis.

The Blueprint

I will be following VMware’s official blueprint.

  • Section 1 – Create a vSphere Conceptual Design
    • Objective 1.1 – Gather and analyze business requirements
    • Objective 1.2 – Gather and analyze application requirements
    • Objective 1.3 – Determine Risks, Requirements, Constraints, and Assumptions
  • Section 2 – Create a vSphere 6.x Logical Design from an Existing Conceptual Design
    • Objective 2.1 – Map Business Requirements to a vSphere 6.x Logical Design
    • Objective 2.2 – Map Service Dependencies
    • Objective 2.3 – Build Availability Requirements into a vSphere 6.x Logical Design
    • Objective 2.4 – Build Manageability Requirements into a vSphere 6.x Logical Design
    • Objective 2.5 – Build Performance Requirements into a vSphere 6.x Logical Design
    • Objective 2.6 – Build Recoverability Requirements into a vSphere 6.x Logical Design
    • Objective 2.7 – Build Security Requirements into a vSphere 6.x Logical Design
  • Section 3 – Create a vSphere 6.x Physical Design from an Existing Logical Design
    • Objective 3.1 – Transition from a Logical Design to a vSphere 6.x Physical Design
    • Objective 3.2 – Create a vSphere 6.x Physical Network Design from an Existing Logical Design
    • Objective 3.3 – Create a vSphere 6.x Physical Storage Design from an Existing Logical Design
    • Objective 3.4 – Determine Appropriate Compute Resources for a vSphere 6.x Physical Design
    • Objective 3.5 – Determine Virtual Machine Configuration for a vSphere 6.x Physical Design
    • Objective 3.6 – Determine Data Center Management Options for a vSphere 6.x Physical Design


This exam has been available for just 4 months or so and while, as of yet, there’s not much specific content available in the internet or elsewhere, you can still find some guides and books for VCAP5-DCD. The thing with this exam is, at least in my opinion, that is not so much about the technology but about the methodology. This means that most of the resources used for preparation of previous versions of the exam are still relevant for version 6. As Paul McSharry puts it,

As VMware develops more exciting functionality, the blueprint will also change with respect to technology, but the overall theme of and feeling behind this certification should not. After all, platform design processes and thoughts do not change, the technologies do.

In each objective I will be including links to relevant posts or documents but, generally speaking, these are some of the resources I intend to use as I make my way into the exam preparation: