VCDX Design Terminology

It is very important to know the terminology when you create a VCDX Design and also know what the meaning is of this.

This article is part of my VCDX blog article series that can be found here.

Some of the "key terms" used in design terminology are:

1. Requirements
2. Constraints
3. Assumptions
4. Risks
5. Design factors - (all of above) all of the above influence the design in its own way

Design factors

Requirements

A requirement is a mandatory condition or element that needs to be satisfied somewhere in the design. This can be a functional or a non-functional requirement. Functional requirements will describe what the design MUST do. Non-Functional requirements will describe how to accomplish the functional requirements. Non-Functional requirements are also called constraints (that we can specify separately) They constrain the architect with certain elements to satisfy the functional requirements.

Below you will find an example of a requirement.

Weak functional requirement: "The design must be supporting additional growth of the environment."

This requirement leaves a lot of room for interpretation. It does not define what kind of growth, how much growth and across what time period.

These are questions that impacts the design so it is important that these requirements do not leave more questions then answers.

Strong functional requirement: "The design must provide sufficient capacity to handle current workloads and account for 40% growth in the number of initial workloads in the next two years."

Weak non-functional requirement: "The design must leverage the companies existing investment in Cisco UCS Blade servers."

This non-functional requirement explains HOW the requirements need to be accomplished. This is what makes it similar to a constraint.

Requirements can come form a number of different sources and stakeholders. Application owners and other technology solutions (CIO), Business owners (CEO), Operations (COO), Security (CISO).

Constraints

A constraint is everything that restricts the architect's options that it has when trying to satisfy the functional requirement. This is the same as a non-functional requirement because it somehow restrict you or tell you HOW the requirements can be accomplished with the given constraints.

Like requirements and risks constraints can come from multiple sources like the Technology, the Operations and Financially.

Technology: Only certain vendors, technology, or hardware can be used. For VCDX the biggest constrain is that VMware technology should be used and the products are described in the VCDX technology track blueprint document.

Operational: A specific group well be responsible for managing the newly designed SDDC architecture and backups need to be done by the storage admins, etc.

Financial: Every company has a budget constraint.

Example constraint: "Arista will be the vendor that is chosen for all network related equipment."

Assumptions

An assumption is anything in the design that is accepted as a fact, but not backed by any requirement or constraint. A requirement will usually come from the customer/business and an assumption is typically made by the architect. An assumption can influence the design by including, excluding or modifying parts of the design or other design factors.

Example assumption: "This design assumes te environment will grow more then 20% during the first six months after implementation."

When the requirements are weak and leave room for questioning these requirements can be backed by an assumption. So if the initial requirement did not specify a growth number of period of time this can be assumed in the assumptions. Or course these assumptions need to be verified with the customers if this is "ok".

Another example assumption: "The customer will re-use their existing monitoring and management solutions in the new VMWare NSX environment."

In this example this assumption EXCLUDES "Monitoring and Management" from the design and with this assumption it is safe to leave these elements out of the design. We do however may need to describe what this existing monitoring and management solutions are and how these will work together with our newly proposed technical elements in the design, but no NEW monitoring and management solutions are needed.

Risks

A risk is anything that can potentially prevent the design from satisfying the functional requirements. As an architect it is important to identify and minimise or mitigate these risks in the design. Just like requirements risks can come from multiple sources like the Technology, the Operations and Financially.

Maybe a specific type of existing technology will not work together with other newly implemented technologies that are described in the new design. And maybe introducing new technology into a company will cause other operational procedures to change and people need to gain additional knowledge. All companies have budgets to work with so this may be a risk when the budget is too low or maybe exceeded.

Strong example (operational) risk: "The existing people that are working within the company do not have the skills that are needed to manage a VMware NSX environment."

As an architect you need to be able to identify and mitigate this risk. This can be mitigated with sending the staff to a VMware Install, Configure and Manage VMware NSX training.

Weak example (technology) risk: "The existing storage array does not have enough capacity to meet the projected growth requirements."

The risk does not specify what sort of capacity, it can be storage, throughput, or IOPS capacity. The projected growth requirements are not specified here as well.

In order to mitigate this we first need to have this risk written down in a stronger fashion.

Fitting together the Requirements, Constraints, Assumptions and Risks

Each of the design factors influence the design in its own specific way. As an architect who should maintain a holistic view you should be able to understand the impact of these items on the full design and where needed account for that impact.

The design must:

1) SATISFY the requirements

2) IDENTIFY / MINIMISE / MITIGATE the risks

3) IDENTIFY the assumptions (if requirements are unclear and leave room for interpretation)

4) ADHERE to the constraints

This article is part of my VCDX blog article series that can be found here.