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

1 thought on “Sprint to VCIX (Part 2) — Gather and Analyze Business Requirements

  1. Pingback: Sprint to VCIX (Part 3) — Gather and Analyze Application Requirements - vXeno

Leave a Reply

Your email address will not be published. Required fields are marked *