Tag Archives: Virtualization

Sprint to VCIX (Part 2) — Gather and Analyze Business Requirements

Originally published December 29, 2020 on LinkedIn.

The VCAP-DCV 6.5 Design exam blueprint and a great updated reference link list provided by Jeffrey Kusters (Double VCDX #252) will get us in the right direction for the content and depth VMware expects Advanced Professionals and Implementation Experts to be.

Conceptual design is the owner’s view. What does the business want to accomplish, what problems are we solving, and what value does our design bring to them?

Section 1 – Create a vSphere 6.5 Conceptual Design

Objective 1.1 for the VCAP-DCV Design exam is to gather and analyze business requirements. vBrownBag hosted a 45-minute discussion on Objective 1.1 for the Design exam:

VMware uses a design methodology when creating a conceptual design centered on business drivers and two conceptual frameworks: Design Factors – Requirements, Constraints, Assumptions, and Risks (RCARs); and Design Qualities – Availability, Manageability, Performance, Recoverability, and Security (AMPRS). Jeffrey Kusters, again, has a helpful breakdown of these frameworks. We will get more into RCARs and AMPRS later in the series but as we move through the design process and determine business requirements, we will categorize information into design factors and qualities. Design qualities should be the main considerations when identifying and categorizing requirements during stakeholder engagements.

Identify Stakeholders and Information Needed

“Gathering and analyzing business requirements starts with identifying the business justification for the project, business problems that they’re trying to solve, and the goals of the projects as it relates to those goals.”

– Jeffrey Kusters

The business leaders and the project charter should outline these goals and give you an idea of the stakeholders that need to be engaged to identify business requirements. These stakeholders will hold various roles in the organization; each will have input into the design and will have some information needed to analyze the business requirements. IT Director, Network Admins, Storage Admins, Infrastructure Admins, C-level executives, LOB directors/managers, application owners, and end-users can all have input on a vSphere design.

Engaging in workshops and interviews with stakeholders will identify business requirements, constraints, assumptions, and risks. Driving business value is closely tied to making sure you identify requirements and validate they support the business’s goals. In VMware vSphere 6.7 Design Cookbook and VMware vSphere Design, the authors have chapters dedicated to the discovery process and design factors. The primary source of information will be your stakeholder interviews, reviewing documentation, current inventory, and current state analysis that can be done with available tools. Each stakeholder has different views of the project so identifying what questions to ask and whom to ask those questions is important.

Inventory Assessments and Current State Analysis

After we engage with stakeholders we need to start assessing the current baseline state of the environment. This can be done through services and tools like Active Directory, LDAP directories, network-management tools, logging solutions, IP addressing documentation (IPAM), equipment configurations, and historical performance data. Vendor and community tools can be used such as VMware Capacity Planner, Windows Performance Monitor, vSphere Optimization Assessment (VOA) in vRealize Operations Manager, etc.

During our current state analysis, we are essentially answering: what does the customer have and how do we find it? The baseline state will help define requirements like capacity, consolidation ratios, measuring KPIs, identifying unique dependencies, and what infrastructure can be reused.

Business Objectives and Priorities

When we have our customer interview data and knowledge of the current state, we can explicitly define customer requirements, state the objectives, and determine customer priorities for our vSphere conceptual design.

Below is a sample customer objective list pulled from the vBrownBag video:

  • Virtual infrastructure capable of consolidating country-wide workloads
  • Highly available, disaster recovery solution
  • Common, standardized infrastructure
  • Simplified and improved support model
  • DR with VMware SRM and EMC RecoverPoint
  • Provide virtual infrastructure that can provide 99.9% availability or higher
  • Automatic VM failover in the event of a host failure
  • DR of critical systems with a 99.9% availability
  • DR of non-critical systems with a 99% availability
  • Management simplicity where possible
  • Resilient and provide the highest level of availability where possible while keeping costs to a minimum
  • 30% growth of VMs and storage over the next four years

These objectives should map to the design qualities mention at the beginning of this article, Availability, Manageability, Performance, Recoverability, and Security (AMPRS).

  • Virtual infrastructure capable of consolidating country-wide workloads – Availability, Manageability, Performance, Recoverability, and Security
  • Highly available, disaster recovery solution – Availability and Recoverability
  • Common, standardized infrastructure – Manageability
  • Provide virtual infrastructure that can provide 99.9% availability or higher – Availability, Performance, Recoverability
  • 30% growth of VMs and storage over the next four years – Performance

Identify & Categorize Requirements

With an approved objective list and business requirements we can refine precise requirements to prevent scope creep and define exactly what the customer requires. Requirements can be broken down into two different types, functional and non-functional requirements.

“Functional requirements specify the objectives or functions that a design must meet. Nonfunctional requirements define how the design accomplishes the functional requirements.”

VMware vSphere 6.7 Design Cookbook

Personal note: I feel like this is one of the hardest concepts in the VMware design methodology and requires a bit of a vocabulary redefinition, especially if you come from the technical/admin side of vSphere. When VMware says functional it is relating to the business’s functions, specifically. One might say storage IOPs are a function of the storage array but IOPs are not a business function in the sense of supporting a business’s needs. So in that sense, IOPs are a performance-based, non-functional requirement. A storage focused functional requirement could be the infrastructure design should simplify storage administration and increase application availability.

Put another way, a functional requirement is describing the behavior of the system as it relates to the system’s functionality. A non-functional requirement elaborates a performance characteristic or quality of the system.

Typical functional requirements include the following:

  • Business goals
  • Business rules
  • Legal, regulatory, and compliance requirements
  • Application system requirements
  • Technical requirements
  • Administrative functions

For example, “The business processes credit card data in a web application. The virtual infrastructure will be PCI DSS compliant.”

Another example, “Our systems administrators have spent a significant amount of time automating our infrastructure change management process. They need to be able to programmatically access and administer the virtual infrastructure.”

Typical nonfunctional requirements include the following:

  • Performance
  • Security
  • Capacity
  • Availability
  • Manageability
  • Recoverability

For example, a specific set of requirements might read, “Our revenue-generating web application processes 95% of our requests during business hours (9am-6pm). We must fulfill a 99.99% availability SLA for that application during business hours. Critical internal applications need to be 99.9% available and non-critical applications need to be 99% available during business hours.” These would be categorized as Performance and Availability non-functional requirements.

We will dive deeper into the details of functional and non-functional requirements in Objectives 1.3.and 2.1. They are introduced here since they are integral to the vSphere design and provide justification for each design decision. For now, having the business requirements gathered and mapped will help us later when we bring it all together into the conceptual design and in Objective 2 when we map the conceptual design to the logical design.

Detailed reading on Objective 1.1

Sprint to VCIX-DCV (Part 1)

Originally published December 26, 2020 on LinkedIn.

I am coming hot off passing the AWS-SAA certification and very excited to pivot back into VMware, this time taking it to the next level — VCIX-DCV. This series of articles is going to serve as:

  1. The mechanism I use to reinforce the material I am using to study for each VCAP. I learn new material best through my own system, which will be detailed in the series, but presenting information is a reinforcing technique I use for myself and my team.
  2. Create a forcing function and means for my peers and mentors to keep me accountable to my aggressive timeline. I am aiming for many goals inside the next 6 months and sometimes I may lose sight of where I want to be in 6-12months. This will help me keep myself on pace or adjust as needed as well as give my peers and mentors a way to track my progress. This also allows people to correct anything I have written or add to the conversation here since this is part of my learning phase.
  3. Start to give back to the community. Over the years I have taken a lot out of the community. Thousands of articles, forum posts, GitHub repos, videos, and blogs have helped me as an IT professional and I want to start to help those coming behind me.

Why Now?

I am transitioning out of the US Army and my organization has been gracious enough to allow me time to upskill before my separation and to participate in a corporate fellowship. I have been accepted into VMware’s Corporate Fellowship Program and will be starting in January 2021. I have learned a lot about myself in the last few years and with the help of mentors and peers, I have focused on virtualization, hybrid cloud deployment, and software-defined networking.

I plan to use the holiday season to prepare for the VCAP-DCV Design and take that certification the week before I start with VMware. I am already in the design mindset coming from the AWS-SAA and having spent the last couple of years working on design and architecture projects for the Federal Government. From the time I started to study, to the day of my planned VCAP Design exam will be ~30 days.

Immediately after the VCAP-DCV Design, I will start the push for VCAP-DCV Deploy using the experience and time working with my team at VMware as well as labbing at home to prepare. I am optimistic that my time with VMware will result in a successful VCAP Deploy and the VCIX-DCV designation before I start full-time employment.

The large risks with my timeline are the team and workload that I will have at VMware, military transition requirements, job hunting/interviewing within 90 days of my separation, and preparing my family for potential relocation. All of these major commitments are occurring around the same time and could potentially change my VCIX timeline. I have made some assumptions about the commitment for each and I will adjust as I start to validate. The aggressive push for the Design before I start at VMware, as well as a longer time frame (2-3 months) for Deploy, reflect the demand for my time in early 2021.

Series Outline

This is going to be a long series with each post focusing on a major exam objective from each of the exam guides (VCAP-DCV DesignVCAP-DCV Deploy). I will be studying vSphere 6.5 well as including considerations for newer versions. VMware has extended the general support for vSphere 6.5 five years from the date of release, which means the general support for vSphere 6.5 will end on November 15, 2021. The Design exam (3V0-624) is still on 6.5 while the 2018 Deploy exam (3V0-21.18t) is being expired in December 2020 for an updated 6.7 version (3V0-21.20). As I publish more sections they will be added here for quick reference:

  • Part 1 — VCAP-DCV Design Plan of Attack

Part 1 — VCAP-DCV Design Plan of Attack

I will be following the VMware VCAP exam guides for my study structure — VCAP-DCV DesignVCAP-DCV Deploy

I will be using the VCAP-DCV Design series from vBrown Bag as my starting point. I have found that my learning improves when I do a video primer followed by an in-depth study on documentation and key points.

I have picked up copies of VMware vSphere DesignFoundation In the Art of Infrastructure Design, and VMware vSphere 6.7 Data Center Design Cookbook as references to start.

I will be starting with Rene Van Den Bedem‘s VCDX Deep-Dive Series.

As I work through my studies, I will add the references/resources for specific sections/objectives in the outline below as a one-stop-shop for anyone on the same journey. Each subsequent article will be a summary of the VMware Design objective, resources used to learn, and a summary of the content.

Section 1. Create a vSphere 6.5 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 computer 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.

Please let me know if there is anything I need to add or change during the course of my series. Any advice and study recommendations are greatly appreciated.