Determining the Design Factors & Design Qualities derived from them

As I am moving close to the VCDX design defense final lap, I have started working out on the documentation. During the first phase of the design, I figured out that I have not seen a standard post which can qualify the design factors and how does some one strengthen their design qualities that derives from design factors. I thought that is going to be the base or foundation for any design. In this post I am going to discuss the design factors and design qualities. So before I jump straight to it, let me make create a base here by knowing the design factorial terminology first.

  • Requirements – A mandatory condition that must be satisfied, which can be Functional or Non Functional
  • Risks – Anything that could potentially prevent the design from satisfying the requirement
  • Assumptions – Any aspect of the design that is accepted as a fact and is not backed by a requirement or a constraint
  • Constraints – Anything that restricts the vSphere architects options in satisfying the requirement
  • Design Factors – Term used to describe the four factors that influence a vSphere design
Now let us further deep dive into each area and see how they influence the design factors.

Requirement (Functional & Non Functional)

Functional Requirements are the one that define what should the design do. An example could be whether the design must be capable of supporting additional growth in the environment.

Non-Functional Requirements are the one that would state how would the design meet the functional requirements. An example could be the fact that the design must  provide sufficient capacity to handle current workloads and account for 20% growth in the number of workloads over the next year. However some times it also lead to Constraints.


Risks are broadly categorized as anything that potentially block the design from achieving it’s goal. For an example, the existing staff does not have the necessary skills or experience to manage the vSphere environment or the existing storage array does not have the sufficient capacity to meet the projected growth requirements. They are also categorized in three distinctive areas:

  • Technological
  • Operational
  • Financial


Requirements come from the client where as normally assumptions come from the architect for some unclear or undecided situations.

For an example, this design assumes that the environment would grow by approximately 20% year on year. Another example could be, It is assumed that the customer would use the existing monitoring and management solution in the new vSphere environment.


Constraints are the mirrored image of Non Functional Requirements. For example, Cisco would be the chosen vendor for all networking equipments.

Determining the Design Factors

A picture is worth 1000 words.



Design Qualities that derived from the Design factors

The architecture framework uses a common model to describe the key design qualities of a well-designed VMware infrastructure. These qualities are used to categorize requirements and design decisions and to assess infrastructure maturity.



Availability indicates the effect of a design choice on the ability of a technology and the related infrastructure to achieve highly available operation. Key metrics: % of uptime.

Availability = (Uptime / (Uptime +Downtime)) x 100


Availability = (Elapsed Time – Downtime) / Elapsed Time) x 100

Example: For example,  in the last 30 days (43, 200 minutes), a system that has been online and available for 29 days 23 hours and 34 minutes (43,174 minutes). In other words it has been offline for 26 minutes within in a 30 day (43,200 min) period due to an unscheduled outage:

Elapsed Time (Minutes in Month) =43200

Downtime Minutes = 26

Availability = (43,174/(43174 + 26)) x 100 =  99.9%


Availability = ((43,200 – 26)/43,200) x 100 = 99.9%

Manageability indicates the effect of a design choice on the flexibility of an environment and the ease of operations in its management. Sub-qualities might include scalability and flexibility. Higher ratios are considered better indicators.

Key metrics:

  • Servers per administrator
  • Clients per IT personnel
  • Time to deploy new technology

Performance indicates the effect of a design choice on the performance of the environment. This does not necessarily reflect the impact on other technologies within the infrastructure.

Key metrics:

  • Response time
  • Throughput

Response time = total time taken/total number of requests

Example: In a grocery store the cashier takes 2 minutes to checkout each customer. For 10 customers, total time taken would be 20 minutes.

Response time= 20/10  minutes/requests


Response time = 1200/10 seconds/request

Note: Doesn’t mean that throughput = 1/Response Time

Example: In the same grocery store what if 10 people used this same checkout lane, but each person arrived in line 1 minute after the last person was done checking out? The cashier is just twiddling his thumbs, waiting for a customer for 1 minute. The cashier is still capable of checking out a customer in 2 minutes, so the average response time is still 2 minutes / customer, but the throughput of people coming out of the checkout lane is not the same.

Response time = 20 minutes / 10 checkout= 2 minutes / checkout
Latency = 0 minutes / 10 checkouts = 0 minutes / checkout
Throughput = 10 checkouts / 29 minutes = .34 checkouts / minute

Recoverability indicates the effect of a design choice on the ability to recover from an unexpected incident, which affects the availability of an environment.

Key metrics:

  • RTO – Recovery Time Objective
  • RPO – Recovery Point Objective

Security indicates the ability of a design choice to have a positive or negative impact on overall infrastructure security. Can also indicate whether a quality has an impact on the ability of a business to demonstrate or achieve compliance with certain regulatory policies.

Key metrics:

  • Unauthorized access prevention
  • Data integrity and confidentiality
  • Forensic capabilities in case of a compromise


About Prasenjit Sarkar

Prasenjit Sarkar is a Product Manager at Oracle for their Public Cloud with primary focus on Cloud Strategy, Cloud Native Applications and API Platform. His primary focus is driving Oracle’s Cloud Computing business with commercial and public sector customers; helping to shape and deliver on a strategy to build broad use of Oracle’s Infrastructure as a Service (IaaS) offerings such as Compute, Storage, Network & Database as a Service. He is also responsible for developing public/private cloud integration strategies, customer’s Cloud Computing architecture vision, future state architectures, and implementable architecture roadmaps in the context of the public, private, and hybrid cloud computing solutions Oracle can offer.

One Reply to “Determining the Design Factors & Design Qualities derived from them”

  1. Good write up.

    Not sure I follow you on the functional and non-functional bits.
    In your example, functional requirement would be: support for additional growth. The non-functional requirements would be therefore how to characterise the support for additional growth using the 5 design qualities VMware loves to retain.

    Also, an assumption is something that has been decided to be true, 20% growth in your example, but you have not verified and validated. This particular example is so important IMHI that I would recommend to validate the assumption and pass it into the requirements actually.

    Regarding constraints, I’m not sure to understand the ‘…are the mirrored image of Non Functional Requirements…’!?

    Constraints are limiting your design options. i.e. you would have gone for Blade technology, but your customer has already bought pizza servers for this project. That is a constraint!
    Now if you had chosen Cisco for the design and fortunately the customer is a Cisco shop, then that is not a constraint anymore.

    Risks are something you want to identify early in the design process and mitigate them. I would not have put the ‘staff does not have the necessary skills or experience to manage the vSphere environment’ as a risk but more as an assumption. Personally dependencies to your design completion are more likely to be defined as risks in your architecture documentation.

    Good luck with your VCDX track 😉

Leave a Reply