VCDX – Submission Breakdown

Last week I submitted my NPX document bundle to the Nutanix Platform eXpert program.  I was reflecting on how my design skills have evolved over the last three years and wondered how that translated into actual metrics.  So I went through my last four major design submissions and came up with the following figures.

Update – I have added the VCDX-CMA statistics from my joint submission with Gregg Robertson, VCDX#205, and Andrea Siviero.

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

vcdx_npx_breakdown_updated

What are the differences between my first major design and my most recent?

  • Update – Detailed Test Plan and SOPs – For my VCDX-CMA joint submission (with Gregg Robertson, VCDX#205, and Andrea Siviero), we took the time to produce a complete set of detailed tests and procedures for the vRealize Suite.
  • Brevity – My readership is comprised of experts, so there is no need to explain the technology.  Provide the justification for each decision made, the impact and any associated risks.
  • Structure and Referencing – Every Requirement, Constraint, Assumption, Design Decision, Risk, Implementation Task, Configuration Setting, Test and Procedure has a unique reference code.  This makes the design very easy to read and cross-reference (very important for Solution Metrics point below).
  • Logical DesignVendor-agnostic design decisions.  I only talk about the function of the technology and leave the vendor selection for the Physical Design.
  • Risks – Every technology decision you make has Pros and Cons, you need to fully understand the Risks that your design decisions have and then mitigate them.  There is no such thing as a risk-free design, you need to make sure that the Pros and Cons of the solution align with the Business Requirements of your Customer.
  • Page Count – Rather than include every document related to the solution, just include the URLs pertinent to the scope of the design.  You can also summarise lengthy internal documents (not available on the Internet) as an Appendix in your design submission (in your own words).
  • Scope – My designs cover all areas of the blueprint, however when it comes to the supporting documentation, I only address the actual technology area (eg. vSphere, NSX) and any touch points it has with the rest of the solution (eg. vROps, Enterprise services such as: SMTP, LDAP, NTP, Syslog).  In my Bill of Materials, I provide the list of “Enterprise Services” that I am expecting to consume and provide them in the Implementation Plan as Prerequisite Tasks that must be completed before we can begin.
  • Solution Metrics – I spend a lot of time making sure that my entire design and supporting documents are linked together and that all Customer Requirements are being met.
  • Document Structure – My document templates have matured and evolved over time, this is the current incarnation of what I submit:
    • Read Me First – Contains the list of PDFs in the document submission with a short description of each (very similar to this bullet point list).
    • Program Application – Downloaded from VMware.com/Nutanix.com and completed by me.
    • Candidate Agreement – Signed original, scanned to PDF.
    • Overview – Explains the design methodology and linkage between documents.
    • Architecture Design – Conceptual Model, Logical Design and Physical Design; broken into technology areas, including the Bill of Materials, Current State, Operational Readiness Assessment and Risk Analysis.
    • Implementation Plan – Overview of Project Plan and Gantt chart in document format with required resources and a Migration Plan.
    • Configuration Guide – Links to vendor documents and product configuration settings.
    • Test Plan – Functional, Integration, Reliability and Performance Tests with a detailed test template.
    • Standard Operating Procedures – Required procedures in table format with a detailed procedure template.
    • Blueprints – Logical and Physical design blueprints, broken into technology areas.
    • Solution Metrics – Provides an analysis of the Architecture Design and Supporting documentation, including a requirements matrix.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s