This blog post covers objective 1.1 (Gather and analyze business requirements) of the VCAP-DCV Design 2021 exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update December 2019).

When you get the task to design something , you will instinctively start gathering information about the requirements that have to be fulfilled. Everything IT is doing should support the business in some way.

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

• Associate a stakeholder with the information that needs to be collected
• Utilize inventory and assessment data from a current environment to define a baseline state
• Analyze customer interview data to explicitly define customer objectives for a conceptual design
• Determine customer priorities for defined objectives
• Ensure that Availability, Manageability, Performance, Recoverability and Security (AMPRS) considerations are applied during the requirements gathering process
• Given results of the requirements gathering process, identify requirements for a conceptual design
• Categorize requirements by infrastructure qualities to prepare for logical design requirements

Associate a stakeholder with the information that needs to be collected

Let’s start with the stakeholders and why they are important for us. But what is a stakeholder? A stakeholder is a person with an interest or concern in something, especially a business (Oxford). Stakeholders can be internal or external parties. An internal stakeholder is someone with a direct relationship to the company. An external stakeholder has no direct connection to the company, but it is affected in some way. This can be suppliers, the government, or other groups. A stakeholder can be anyone, but in our context stakeholders are typically

• C-Level Executives (CEO, CFO, CIO etc.)
• Vice Presidents
• Managers, but also
• Engineers and end users

As always: It depends. :)

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

We also need to understand the current environment and what is currently deployed at the company. Interviews with the stakeholders are important, but in most cases they will not answer all questions. Depending on what is currently deployed, different tools can be used to gain the necessary data. Some examples:

• RVTools, PowerCLI, vSphere Web Client, vROps etc
• Custom scripts
• Windows Server Manager
• Network Monitoring Tools, like HPE Intelligent Management Center
• Asset Management

It is important to document the results of the assessment. This is the baseline state of the current environment.

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

Now we need to get back to the results of the interviews that we did with the stakeholders to define the goals and the scope of the design. We also need to understant the the

• Constraints
• Assumptions,
• Requirements, and
• Risks

When we talk about requirements, we have to differ between functional (WHAT) and non-functional (HOW) requirements.

These information will allow us to create a conceptual design, which is written down in a workbook document.

Determine customer priorities for defined objectives

The next step is to define the priorities over the defined objectives. It is important to weight e.g. requirements and risks. Milestones have to be defined. They will help us to measure the success of the project and keep it on track.

Ensure that AMPRS considerations are applied during the requirements gathering process

AMPRS stands for

• Availability
• Manageability
• Performance
• Recoverability, and
• Security

It is important to understand the meaning of each of these terms.

Availability considerations address the availability requirements of our design. These are typically expressed by percent uptime of a specific system. For example: 99,5% availability for file services.

Manageability considerations address the management and operational requirements of our design. This can be alerting, reports, access concepts etc.

Performance considerations express the required performance characteristics of the design. For example: Mails per second by a given size.

Recoverability considerations cover the ability to recover from an unexpected incident or disaster. This topic typically addresses backup and recovery of our design.

Security considerations cover the requirements around data control, access management, governance, risk management etc.

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

Now we have collected information from the relevant stakeholders, including the goals, scope, and CARR (constraints, assumptions, requirements, risks), and we have collected details about the current environment. Now it is time to put these information together and create a conceptual design.

The conceptual design must be approved by the stakeholders. This assures that everything is covered. Creating a conceptual design is an iterative process. The conceptual design is finished when the relevant stakeholders have approved it.

Categorize requirements by infrastructure qualities to prepare for logical design requirements

Sounds simple, but it can be challenging: The documented requirements have to be grouped by infrastructure categories, eg.

• Networking
• Storage
• Recovery
• Compute
• VM
• Security

Based on the CARR and the AMPRS considerations, we made design decisions. These decisions affect each of the infrastructure categories. At this point, we can review each of our decisions and mapping the requirements to the infrastructure will ease the creation of a high-level logical design.

Summary

Let me try to simplify this complex process a bit.

We were asked to solve a problem for a company. To solve this problem, we have to design a solution. To create this design, we have to identify the relevant stakeholders. These stakeholders will help us to gather information about the goals, the scope, about constraints, assumptions, requirements and risks. Especially when it comes to the requirements, we have to take availability, manageability, performance, recoverability and security considerations into account.

We can use different tools to collect information about the current environment.

At this point we know WHAT the company want, and we know WHAT they are currently running.

Now we can start with the creation of a conceptual design, which has to be approved by the relevant stakeholders.

To prepare the logical design, we need to map the documented requirements to the different categories of the infrastructure.

Links

• Functional vs. Non-Functional Requirements
• Conceptual, Logical, Physical: It is Simple
• Virtualize Business Critical Applications (blog)
• Virtualizing Business Critical Applications on vSphere

This blog post covers objective 2.3 (Build availability requirements into a vSphere 6.x logical design) of the VCAP6.5-DCV Design exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update August 2017).

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

• Evaluate which logical availability services can be used with a given vSphere solution
• Differentiate infrastructure qualities related to availability
• Describe the concept of redundancy and the risks associated with single points of failure
• Explain class of nines methodology
• Determine availability component of service level agreements (SLAs) and service level management processes
• Determine potential availability solutions for a logical design based on customer requirements
• Create an availability plan, including maintenance processes
• Balance availability requirements with other infrastructure qualities
• Analyze a vSphere design and determine possible single points of failure

Let’s start with…

Evaluate which logical availability services can be used with a given vSphere solution

VMware vSphere offers a broad band of features that allows you to create highly available solutions. When we take a look at the infrastructure, feature like VMware HA, FT, or even multiple NICs at a distributed vSwitch allow to increase availablility. When we look at the application layer, other techniques, like DRS can help us to increase availability to use DRS to place VMs on different hosts (anti-affinity rules) etc.

Differentiate infrastructure qualities related to availability

The infrastructure qualities are:

• Availability
• Manageability
• Performance
• Recoverability
• Security

Availability and Recoverability are tight together. René van den Bedem has written an very good blog post about how recoverability affectes availability.

Describe the concept of redundancy and the risks associated with single points of failure

This topic is pretty clear and should be easy to explain. You should be able to identify what a single point of failure is, and how you can avoid them. Examples for a single point of failure are:

• only a single-port HBA in a server
• only one network uplink from a Top-of-Rack switch to a Core-Switch
• using of RAID 0

Explain class of nines methodology

This is also easy:

• Two Nines- 99% – 3.65 days downtime per year
• Three Nines- 99,9% – 8.76 hours downtime per year
• Four Nines- 99,99% – 52.6 minutes downtime per year
• Five Nines – 99,999% – 5.26 minutes downtime per year
• Six Nines – 99,9999% – 31.56 seconds downtime per year

Important note: “Downtime” means “unplanned downtime”, not planned downtime, like in maintenance windows.

Determine availability component of service level agreements (SLAs) and service level management processes

An Service Level Agreement (SLA) is a contact between two parties, usually a supplier and a customer. The SLA describes targets that should be met. This can be an availability expressed using the “class of nines methodology”. If this target is missed,the supplier ofthen has to pay a penalty to the customer.

So it is pretty important to build a design that can fulfill the availability requirements. Depending on the requirements you may have to use VMware FT. If the availability requirements are lower, VMware HA may be sufficient. It is important that you can choose the best technique for the given SLA.

Determine potential availability solutions for a logical design based on customer requirements

Now it’s time to put things together. You know the different techniques that are offered by VMware vSphere, and you know the customer requirements. This allows you to determine the potential availability solutions for a logical design.

Create an availability plan, including maintenance processes

Again, I’d like to recommend the blog post of René van den Bedem. It’s all about RPO, RTO, MTD and how much does an unplanned downtime costs (result of a Business Impact Analysis).

Balance availability requirements with other infrastructure qualities

At some point of your design you need to holistically look at your design and you have to ensure that a decision, that was made, doesn not impact other requirements or other decision.

Analyze a vSphere design and determine possible single points of failure

This is pretty self-explanatory and can be done together with the preceding step.

Summary

Availability is the main theme of this objective. Do not lose sight of the customer’s requirements. Increasing availability is often associated with immense additional costs.

Read the mentioned blog post from René and I rellay recommend this vBrownBag video with Rebecca Fitzhugh.

This blog post covers objective 2.2 (Map service dependencies) of the VCAP6.5-DCV Design exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update August 2017).

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

• Evaluate dependencies for infrastructure and application services that will be included in a vSphere design
• Create Entity Relationship Diagrams that map service relationships and dependencies
• Analyze interfaces to be used with new and existing business processes
• Determine service dependencies for logical components
• Include service dependencies in a vSphere 6.x Logical Design
• Analyze services to identify upstream and downstream service dependencies
• Navigate logical components and their interdependencies and make decisions based upon all service relationships

Let’s start with the second topic of this objective.

Evaluate dependencies for infrastructure and application services that will be included in a vSphere design

This topic covers two different parts of our vSphere design:

• infrastructure, and
• application services

You should clarify what components of your design depend on each other, or if they depend on components, that are not part of your design. VMware HA needs a shared Storage, or VMware ESXi needs NTP and DNS to work properly.

The same applies to the application services (or applications) that are part of your design. What dependencies do they have. Imagine a three-tier application with database, application logic and web frontend.

You must be able to identify and describe these dependencies.

Create Entity Relationship Diagrams that map service relationships and dependencies

If you are able to identify and describe the dependencies, you also must be able to create a Entity Relationship Diagrams (ER-Diagram) to visualize these dependencies.

Do your homework and try to identify these dependencies at the beginning. Tools like the vRealize Infrastructure Navigator can help you to identify them.

Analyze interfaces to be used with new and existing business processes

It is pretty important to understand how systems interact. To gain this knowledge, you have to analyze the interfaces of business processes. This doesn’t mean that you have to click through ERP applications, but you should get familiar with how processes are tight together.

Determine service dependencies for logical components

You also have to identify the service dependencies for the logical components in your design. You can use tools like vRealize Operations Manager or the Infrastructure Navigator to get the necessary information.

Include service dependencies in a vSphere 6.x Logical Design

The identified service dependencies have to be included into the logical design. This is a pretty important step and you should pay it the necessary attention. Tables and ER diagrams will help you at this step.

Analyze services to identify upstream and downstream service dependencies

An upstream service is a service, which is mandatory for another service, because it relies on it. Downstream services need upstream services to work properly. For example: DNS is an upstream service for Active Directory.

The understanding of up- and downstream services is important for things like startup/ shutdown plans.

Navigate logical components and their interdependencies and make decisions based upon all service relationships

You should visualize the service dependencies. This will help you to evaluate the impact if a service fails or how service are interact with each other.

Summary

Most of the topics in this objective overlap. Quite basic everything is about the understanding how things are connected and interact. This will help you to get a better understanding of dependencies and what services are crucial for the business or your solution.

Think again on DNS. No one of us will ever build a solution with a single DNS server, because nearly everything will melt down if DNS is not available. DNS is a perfect example for an upstream service.

The last few weeks have been quite busy. Time to focus on exam preparation again. Let’s start with the first objective of the second section.

This blog post covers objective 2.1 (Map business requirements to a vSphere 6.x logical design) of the VCAP6.5-DCV Design exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update August 2017).

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

• Analyze requirements for functional and non-functional elements
• Build non-functional requirements into a specific logical design
• Translate stated business requirements into a logical design
• Incorporate the current state of a customer environment into a logical design

Let’s start with

Analyze requirements for functional and non-functional elements

Functional and non-functional elements sounds familiar. I wrote about functional and non-functional requirements in the previous objective 1.3 (Determine risks, requirements, constraints, and assumptions). When we talk about requirements, we have to differ between functional (WHAT) and non-functional (HOW) requirements. Some examples:

• Solution must comply with ISO standards
• The uptime must be at a minimum of 99,9%
• Users must be able deploy new virtual machine within 15 minutes after approval

This step is about analyzing the requirements and check if it is a functional or a non-functional element. Check this examples:

Remember: We have to differ between WHAT (functional) and HOW (non-functional).

Build non-functional requirements into a specific logical design

A logical design is more detailed compared to the conceptual design. A conceptual design is an abstract or high level design. The logical design contains more information, is more low-level than a conceptual design. The purpose of a logical design is refine the conceptual design and add more details and information.

With the determined and categorized requirements we can start to add more details to our design, for example we can define, that server hardware will be purchased from DELL or HPE. Or that we don’t need traditional, dedicated shared storage, because the solution must be hyper-converged.

Pretty important: A requirement is a requirement, regardless how dumb it is. This is pretty important for the exam – and your job. ;)

Translate stated business requirements into a logical design

This is pretty similar to the written above. You have to take the business requirements into account. Similar to the section above, business requirements can also be categorized into functional or non-functional elements.

Incorporate the current state of a customer environment into a logical design

If your customer is not asking for a greenfield deployment, you have to take the current environment of the customer into account. The solution must fit into the current environment. Of course, this results in further requirements that have to be fulfilled.

Summary

The main aspect of this objective is to review all requirements, determine if they are functional or non-functional, and use them to create a logical design. A logical design does not contain IP addresses or VLANs. But it contains all major components and their relationships, like data flows and connections.

Links

• Conceptual, Logical, Physical: It is Simple
• Functional vs. Non-Functional Requirements
• Conceptual Architecture Action Guide
• Systems Architecture Fundamentals – Conceptual, Logical, Physical Designs

This blog post covers objective 1.3 (Determine risks, requirements, constraints, and assumptions) of the VCAP6.5-DCV Design exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update August 2017).

The first objective of the exam prep guide has covered the business requirements. Now we have to do similar for the affected applications.

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

• Differentiate between the concepts of risks, requirements, constraints, and assumptions
• Given a statement, determine whether it is a risk, requirement, constraint, or an assumption
• Analyze impact of VMware best practices to identified risks, constraints, and assumptions

Differentiate between the concepts of risks, requirements, constraints, and assumptions

I wrote a couple of times about risks, requirements, constraints and assumptions, but I missed to explain the meaning of each of these terms. I will use the following order:

• requirements
• risks
• constraints
• assumptions

So let us start with “What is a requirement“? A requirement is something that a has to be achieved. This can be applied to business or technical things. Without defined requirements, you would have no clue what your design should cover. If you define a requirement, you should test it with the following question: Is the defined requirement

• specific
• feasable
• verifiable
• traceable
• unambiguous

When we talk about requirements, we have to differ between functional (WHAT) and non-functional (HOW) requirements. Some examples:

• Solution must comply with ISO standards
• The uptime must be at a minumum of 99,9%
• Users must be able deploy new virtual machine within 15 minutes after approval

A Risks is a potential event, that might prevent us from achieving the defined project goals, or which can cause that the project completely fails. They are often common points in every projekct. The best we can do is to identify and list every risk that might prevent us from successfully finish the project. Some examples:

• Missing the delivery date
• Vendor discontinued parts of the solution
• Hidden incompatibility with currently used frameworks

Constraints can be a limiting factor when we design our solution. They can be understood as cornerstones that set the borders of our solution. Contraints are always very specific. Examples:

• The costs per user must not exceed 5 €
• The project has to be finished withing 9 months
• The solution must include servers from HPE

In opposite to constraints, which are very specific, assumptions are considered to be true without proof in the planning phase. This is pretty important! We are talking about the time, when we put our design together. Examples:

• Rackspace will be available when the HW needs to be deployed
• A MS SQL database server will be available at the installation date
• A specific decision is made when needed

Summary

As I wrote at the beginning of this article: It is important to understand these terms. In simple words:

• requirements: Things that have to met to successfully finish the project
• risks: Things that might happen and that put our project at risk
• constraints: Limiting factors to our project design
• assumptions: Things that are considered to be true, but that are not proofed during the planning phase

That is a pretty simple summary, but it should be good enough to be memorized. :)

Links

• Developing Your Virtualization Strategy and Deployment Plan
• Constraints, Assumptions (Risk, Requirements) & Dependencies

This blog post covers objective 1.2 (Gather and analyze application requirements) of the VCAP6.5-DCV Design exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update August 2017).

The first objective of the exam prep guide has covered the business requirements. Now we have to do similar for the affected applications.

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

• Gather and analyze application requirements for a given scenario
• Determine the requirements for a set of applications that will be included in the design
• Collect information needed in order to identify application dependencies
• Given one or more application requirements, determine the impact of the requirements on the design

Gather and analyze application requirements for a given scenario

As a result of our already done work, we should know with what applications we have to deal in our project. Now ee have to gather the requirements of those applications. The necessary techniques are already known to us:

• interviews with the relevant stakeholders and/ or developers or engineers
• existing documentation about the deployment
• our documented baseline from objective 1.1
• vendor documentation/ support/ knowledge base articles

It is pretty important to understand what requirements these applications have. It depends on the workload and the applications itself. Tools like perfmon or capacity planning tools can help us to get a solid knowledge about the current and planned capacity/ performance requirements.

But we should not only focus on performance. There is much more to take into account, to be more specific: AMPRS

It stands for

• Availability
• Manageability
• Performance
• Recoverability, and
• Security

You can read an detailed explanation here.

Determine the requirements for a set of applications that will be included in the design

This is similar to the written above. When we talk about a set of applications, we have to take the dependencies between these applications into account.

Collect information needed in order to identify application dependencies

To gain the necessary information, we have to talk to the right people, which means that we have to talk to developers, engineers and/ or end-users. We have to deep dive into existing customer and/ or vendor documentation. And we need to use the right tools to map the found dependencies. This can be done with Microsoft Visio, OmniGraffle or similar.

Given one or more application requirements, determine the impact of the requirements on the design

With the knowledge about the applications and the dependencies between them, it is time to make some design decisions. These decisions must support the documented requirements, especially when we think about the requirements in regard of availability, manageability, performance, recoverability, and security.

The key is to understand the impact of the made decisions for the rest of the design.

Summary

I will try to summarize this objective. The last blog post has covered the business requirements and the process from gathering the required information, over the documentation, until the point at which we can start creating a design. This blog post covers the same, but not for the business requirements, but for the applications and the requirements of these applications.

We can gather the necessary information by talking to the relevant stakeholders, engineers, developers etc. Customer and/ or vendor documentation and other sources can be used to get a better understanding of the different application requirements. We also need to understand the dependencies between the different applications, especially if only a subset of applications is virtualized. Our work is supported by different tools, especially for performance analysis, capacity planning and documentation.

With the gathered information we will able to make design decisions that fulfill the requirements (Think about AMPRS).

Links

• VMware TCO Calculator
• VMware Cost-Per-Application Calculator Methodology
• Virtualizing Oracle with VMware
• Virtualizing Exchange with VMware
• Virtualize SharePoint with VMware vSphere
• Virtualizing Microsoft SQL on VMware vSphere
• SAP and VMware Virtualization
• Business and Financial Benefits of Virtualization: Customer Benchmarking Study