HomeVCAP6-DCV Design – Section 1 – Objective 1.1

VCAP6-DCV Design – Section 1 – Objective 1.1

Section 1 – Create a vSphere Conceptual Design

Objective 1.1 – Gather and analyze business requirements

Definitions for this section:

  • Functional Requirements.
    • These are there to define a behavior such as Audit Tracking and Authorization (Something the system should do) Example: The system needs to be able to boot 100 VMs per minute between 8am and 10am
  • Non-Functional Requirements.
    • How the system should behave for Recoverability and Capacity requirements for example. Example: The system must balance workloads to maintain distributed performance
  • Conceptual Design
    • A very high-level design where there are no vendors or low-level connections present between components. Ideal for non-IT staff such as CEOs and CFOs to review.
  • Logical Design
    • An abstract topology of connected objects to show interoperability and how the solution will work. Each section of the conceptual design would normally have it’s own logical design.
  • Physical design
    • A very low-level view of the design to include vendors, IP addresses and connectivity of components. This is known as the “builder view” as the people implementing the solution will refer to this design. A physical design is not a single design drawing. It is generally made up of several drawings, one for each section of the design requirements. (Compute, Storage, Networking, Security etc)

Associate a stakeholder with the information that needs to be collected.

Larger companies will be able to provide this information as members will already fit into the categories below. With smaller companies, you may find that one person fits into the same stakeholder category more than once, or they may not know what category they belong to, you may need to assist with this as part of your design process. For example, there may only be 3 people in the IT department so you would expect one or more of them to be responsible for Compute, Storage, Network, and Security.

Ensure you meet with people from all stakeholder groups to fully understand the business requirements:

  • Business Executives (CEO CFO, CTO)
  • IT (Compute, storage, network, security and compliance teams)
  • Application owners
  • Users

Reading:

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

Use tools to automate the gathering of environmental data. This will save time and remove the possibility of errors in the data you might otherwise collect manually or from people.

  • VMware Capacity Planner
  • Windows Performance Monitor
  • VMware vSphere performance counters
  • 3rd 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. Try to avoid this from becoming an assumption.

Reading:

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

During stakeholder interviews collect the following information

  • Business goals and challenges
  • SLAs, RPOs and RTOs
  • Project deadlines and the reasons for those
  • Budgets
  • Decision makers

Determine customer priorities for defined objectives.

Ask for details in the interviews for project priorities and ensure you detail those in your requirements. This is also a chance 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.

For every conversation take notes on the following design considerations

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

Remember, requirements will be either functional or non-functional.

Reading:

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

Once you have categorized requirements into the above sections, go back to the stakeholders with a conceptual design for each section. Remember this is an iterative process. Only once the conceptual design is approved should you move onto the logical design.

Categorize requirements by infrastructure qualities to prepare for logical design requirements.

Using the above categories, gather all the requirements together and put into the correct category. This will make creating the logical design a simplified and easier process.