VCDX – How do I measure if my Customer Requirements are being met?

One of the biggest challenges with developing your design is checking and measuring how closely your Logical and Physical Design decisions have aligned with the Customer’s Business Requirements.  This is one of the reasons why it is worth starting your design from a blank sheet of paper and ignore any templates you may have access to; they distract you from the fundamental process.

List of articles in my VCDX Deep-Dive series (more than 70 posts)

During my first VCDX attempt I took the organic approach of just writing without any structure and in the final week before submission I had to completely rework my design to provide that needed hierarchy.  LEARN FROM MY MISTAKE: COMPLETE THE CONCEPTUAL MODEL FIRST, THEN THE LOGICAL DESIGN AND THEN FINALLY COMPLETE THE PHYSICAL DESIGN.

You will already have the Conceptual Model under control, three separate sections with Requirements, Constraints and Assumptions.  Keep these items business related, try not to specify technical criteria unless you really have to (sometimes unavoidable with Constraints).  For example:

• R01 – All Business Critical Applications will have an SLA of 99.99%
• R02 – There will be no single point of failure
• R03 – Etc.
• C01 – Two Data Centers are already owned by the Customer and must be used.  They are 300KM apart.
• C02 – Existing VENDOR-X MODEL-Y Storage Array must be used.  Customer has just finished extending and upgrading this infrastructure.
• C03 – Etc.
• A01 – Existing VENDOR-X MODEL-Y Storage Array infrastructure will provide 3 years of capacity for the Customer.

Each Logical Design Choice will have a unique alphanumeric code that will link to the Conceptual Model.  Without the hierarchical numbering to tie it all together, you will get lost in a sea of details.  For example: SLDC01

• Logical Design Choice Options: Storage Protocols can be FC, FCoE, iSCSI, NFS or DAS
• Logical Design Choice SLDC01: Storage Protocol will be Fiber Channel
• Requirements Reference: R01, R02, C02
• Requirements Conflict: None
• Justification: Customer has an existing monolithic Fiber Channel storage array that must be used.
• Impact: Two SAN fabrics will be required, each host will require two HBAs.
• Risks: Each vSphere host has a limitation of 255 LUN IDs and each vSphere Datastore has a maximum size of 64TB.
  

If you follow the blueprint, you will have Logical Design Choices for Compute – CLDCxx, Network – NLDCxx, Storage – SLDCxx, Backup/Recovery – BRLDCxx, Security – SECLDCxx, etc.

The same methodology is used for each Physical Design Choice.  Here the Requirements reference can link to the Conceptual Model and the Logical Design.  For example: SPDC01

• Physical Design Choice Options: Storage Array can be from a Vendor that supports FC, FCoE, iSCSI, NFS or DAS
• Physical Design Choice SPDC01: VENDOR-X MODEL-Y storage arrays will be used
• Requirements Reference: SLDC01 (Note: here I do not specify R01, R02 or C02, since it was already collected in SLDC01)
• Requirements Conflict: None
• Justification: Customer has existing VENDOR-X MODEL-Y storage arrays that must be used for the next 3 years.
• Impact: Enterprise-level Shared Storage, redundant Storage Processors, RAID-1/0, RAID-5 and RAID-6 available, Meta-LUNs required for large Datastores.
• Risks: VENDOR-X MODEL-Y is approaching end of life (just announced).  Customer will require a migration strategy in the next procurement cycle for storage.

Similar to the Logical Design, you will have a series of Physical Design Choices across the blueprint: Compute – CPDCxx, Network – NPDCxx, Storage – SPDCxx, etc.

Now comes the interesting part, the “Pay-Off”, to measure if your design actually meets the Customer Requirements.  You will use a spreadsheet or a document with tables to comb through your design and map the linkages/references to a matrix.  For example: Customer_Requirements_Matrix.

You will note that the first table is for the Conceptual Model, where Logical and Physical Design Choices can be mapped.  The second table is for Logical Design Choices, where only Physical Design Choices are mapped.  Any requirements conflicts that you resolved must be highlighted in RED.

Once you finish filling the matrix, the next step is to count the number of design choices per row and place that value in the “Count” cell.  Any zero values you have in your Conceptual Model and Logical Design indicate you have not met the Customer’s Requirements.  Any row that has a high count, will indicate a requirement that is more important than others, and depending on the Customer’s criteria, the requirement may be over-engineered or under-engineered.

One of the ideas I was toying with, was to numerically weight the Customer Requirements based upon importance (as defined by the Customer) and then multiply the count with the weight to provide a score and then add the scores together to provide a total design score, where some ranking provides an indicator of whether the Customer’s requirement was met (A+, A, B, C) or not met (D, E, F).

After that, I was thinking to build a software tool that contains the entire design blueprint (with a catalog of common choices) where multiple stake holders across technology silos can input their design choices and then the scoring can be executed at the push of a button with no manual sorting or counting.  Plus the tool would handle the blueprints for Data Center, Desktop, Cloud and Network Virtualisation.  The Cadillac of design methodologies.