I would say you either need to work with VCF everyday from a admin and architect level or at the very least have completed two courses such as VMware Cloud Foundation: Deploy, Configure, Manage [V5.2] – On Demand and a design course such as VMware vSphere: Design [V8] – On Demand, that go through the fundamentals .

Alot of questions are long, so you may need to read them a few times, I only had 15minutes left before the exam finished and didn’t have time to review. It covers alot of design questions in real life scenarios .

A overview would be these areas to study.

non-functional vs Functional requirements
Business vs Technical requirements
identify a constraint, risk, assumption and requirement
logical, physical designs, conceptual
VCF, Aria products, HCX, migrations and scalability

Some study notes i found online that were useful for me AND Good luck on your exam (Yes I did pass first time, go me)

VMware Conceptual Design – RCAR and AMPRS

Physical, Conceptual and Logical designs

To best explain the purpose of these three layers, I always like to introduce viewpoints or different perspectives. Let’s start with the physical design because that’s most natural to most of us techies:

Physical design – HOW – “builder’s/engineers perspective”.

This is the portion of the design that appeals most to technical engineers. It is the “builder’s/engineers perspective”. It includes detailed schematics and configuration details of HOW a system needs to be built. It includes many details that are often completely irrelevant to the owner of the system.

Conceptual design – WHY – “owner’s perspective”.

The conceptual design is completely opposite of the physical design. Technical engineers often struggle to understand this level of abstraction. Where the physical design includes detailed configuration settings, the conceptual design is all about WHY a customer is creating a new system. The conceptual design is the “owner’s perspective”. It includes business drivers, requirements, constraints, and so on. The owner basically just wants to know what business value he or she is getting out of the project and doesn’t care about all the underlying complex calculations and schematics.

Logical design – “architect’s perspective”

The logical design is the magic glue between the physical design (HOW) and the conceptual design (WHY). Its goal is to translate all the conceptual fuzziness into a fitting architectural blueprint. This is the “architect’s perspective”. The logical design includes the weighing of pros (benefits) and cons (risks) of design decisions. With just a conceptual design, several technical end solutions would be possible. With just a physical design, no justification for decisions is available and there is no traceability to business value. So, the logical design is arguably the most important portion of any design. It appeals to both the owner and the engineer/builder because both parties can understand and relate to what’s being explained in the logical design.

Elements of Conceptual Design

This breaks down the different elements of the conceptual design, following the VMware design methodology, a conceptual design typically includes business drivers and RCARs (Requirements, Constraints, Assumptions, and Risks).

Business drivers

An IT project should never be started without solid business justification. IT should always strive to add value to the business. It is therefore imperative to identify and clearly stipulate the business drivers that justify a project. These are most often a handful of statements that describe the desired outcome of the project in a language the business can relate to. It should explain what value is being delivered by the project (improved time to market, optimized operational expenditure, and so on).

Requirements

Requirements can be divided into two main categories:

  1. Functional requirements (WHAT)
  2. Non-functional requirements(HOW) (physical design – engineer’s perspective) AMPRS Framework

Functional requirements (FRs) describe WHAT functionality a system should deliver. Non-functional requirements (NFRs) describe HOW a system should behave. If you want to go all-out on requirements mapping, you can divide requirements using the MoSCoW methodology: Must-haves, Should-haves, Could-haves, and Won’t-haves. In most of my projects, I’m not adding this additional layer of complexity in all honesty. In large-scale projects, it does help you prioritize your requirements though.

A non-functional requirement often already includes part of a solution and can result in being a constraint (more on constraints later on). Within the VMware design methodology, NFRs are mapped on the AMPRS framework or Design Qualities as they are also referred to.

Availability

This includes everything related to making sure the system is up and running and doesn’t fail. For example: preventing SPOFs. Availability NFRs also typically include the number of nines’ availability.

Manageability

All requirements that are related to HOW a system must be managed. For example: providing a single pane of glass management.

Performance

Performance NFRs relate to how well a system should respond. This can include specific IOPS requirements, response times for end-users, and so on.

Recoverability

Whenever a system or component fails and causes an outage, recoverability requirements dictate how and in which manner a system should recover. RPO and RTO requirements are typical recoverability NFRs.

Security

Everything related to how a system is protected and secured is mapped on the security design quality. Single-sign on and RBAC are common examples of security NFRs. These describe HOW a user should logon to the system and how they can use it).

Constraints – non-negotiable NFRs

Constraints are what I like to call non-negotiable non-functional requirements. Bold statement: every constraint is a non-functional requirement (but not all non-functional requirements are constraints). When running requirements workshops, as an architect you are often negotiating about the requirements (functional and non-functional) that the customer is shouting out. You are always giving pushback, discussing, reasoning, finding justification, and so on. Constraints are a given. You can negotiate as much as you want, they are not going away. You can – figuratively speaking – throw all the money and resources at it, the constraint is there to stay. Of course in real life, most things can be negotiated away when you throw enough money at it. So, when a requirement is non-negotiable (within reason), you are dealing with a constraint.

One other way to look at constraints is that they limit you as an architect in your design possibilities and design freedom. Even when a different solution has a better fit, but you are forced to use a less attractive option, you are dealing with a constraint. The re-use of existing hardware or the use of hardware from a specific vendor due to running contracts, or limited space in the data center, are frequent examples of constraints. So, in short: constraints are non-negotiable and they limit you as an architect. If a constraint introduces a risk, you should always include it as a risk in your design!

Assumptions

Assumptions are misused a lot in my opinion. On the surface it kind of looks like a very appealing escape for every tough architectural challenge. Just assume the problem isn’t there and off you go. I’ve seen designs, for example where it is absolutely clear that there is a major cooling/power shortage in the data center that is going to prevent the customer for reaching their growth target and, the simple assumption was made that there is enough room in the data center to support the estimated growth. That’s just wrong. You KNOW the problem and risk is there. It doesn’t magically disappear because you have assumed the problem doesn’t exist.

Assumptions are also misused to place certain elements of the design out of scope. This is also heavily used in the VMware Solution Enablement Toolkits design templates: proper DNS/NTP/AD services are provided by the customer. In my opinion, that’s wrong. You are able to validate the proper working of these external services so there is no need to assume they are working. They are beyond your span of control, but up to a certain point, you can validate if they are working correctly or not.

Assumptions include everything necessary for your design (and the solution) that you have not yet been able to validate. Assumptions should be continuously validated throughout the project. Your goal is to have zero assumptions by the end of your design cycle. If that’s not possible, there is still a portion of uncertainty in your design so … you’ve guessed it … there must be an accompanying risk explaining what will go wrong if your assumption turns out to be wrong, and how you have mitigated against that scenario.

Note: also read my earlier blogpost on assumptions and how they can be actually very useful in real-life projects

Risks

Risks in design primarily originate from constraints and assumptions but can also be introduced by external factors. I always like to classify a risk by scoring it against probability vs impact. Of course, all the risks that are highly probable and have a high impact should get the bulk of your attention. A risk should always explain what will go wrong, what you have done to prevent it from happening, and how you are containing the fallout in case it does happen.

Summary

Physical – the physical design describes the engineer’s view and HOW (according to which schematics and specifications) a system is built.

Conceptual – a conceptual design describes the owner’s view and WHY the system is being built in the first place. It focuses on the outcome and envisioned the added value of the project.

Logical – the logical design describes the architect’s view and ensures alignment between the conceptual design and the physical design. It describes WHAT is being built.

The conceptual design (owner’s point of view) describes

Business drivers – aim to deliver/fulfill on the business drivers

Requirements (Functional – “what” and Non-functional “how”) – meet the requirements

Constraints (limitations and non-negotiable requirements) – adhere to constraints

Assumptions (uncertainties) – validate assumptions

Risks (what can go wrong) – minimize risks

Non-functional requirements map to the design qualities: Availability, Manageability, Performance, Recoverability, and Security

By Kader