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.

VCP5-DCV Delta

Casi me ha pillado el toro, casi. Tras meses de procrastinar en la preparación del VCAP5-DCA he estado a punto de dejar caducar mi VCP5 y, entre las opciones que tenía para evitarlo, opté por la solución que parecía más sencilla: el VCP5-DCV Delta.

Se trata de un examen creado por VMware, tras su cambio en la política de certificaciones, para intentar suavizar el trago que supone pasar de certificaciones de nivel profesional (VCP) sin fecha de caducidad a una validez de dos años. El examen permite renovar el VCP y se ofrece durante un período limitado (a día de hoy la promoción finaliza el 31 de diciembre), con las siguientes peculiaridades:

  • el examen es online, es decir, si el tiempo te lo permite puedes consultar toda la documentación disponible;

  • su precio es reducido (al menos comparándolo con el resto de exámenes de VMware, en torno a 100 €);

  • se trata de un delta, supuestamente comprueba tus conocimientos en cuanto a los cambios producidos entre las versiones 5.0/5.1 y 5.5 de vSphere.

El contenido detallado del examen aparece en el blueprint. Dispones de algo menos de dos horas (75 minutos + 30 minutos adicionales si el examen se realiza en un país cuyo idioma nativo no sea el inglés) para responder a 65 preguntas tipo test sobre vSphere, VSAN, VDP, etc.

Hice el examen en mi casa el pasado sábado, literalmente en zapatillas, superándolo sin demasiados problemas. La impresión que me ha dejado es que se trata de una prueba bastante asequible para cualquiera que administre a diario una infraestructura de vSphere. En mi caso tenía ciertas lagunas en herramientas y productos que no utilizo habitualmente, como vCOPs o VSAN, pero nada que no pueda superarse leyendo previamente la documentación enlazada en el blueprint.

Dos años más de VCP. Ahora a por el VCAP, antes de que VMware lo retire.

P.S.: ¿Cuándo arreglará Pearson VUE los problemas con su web en el registro de exámenes avanzados? Qué desesperación…