VCDX – Bad Design

As a VCDX mentor and customer I review a lot of infrastructure architecture designs.  Bad design can be hard to quantify, but this is the consolidated list of frequent comments I have from reading said documents:

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

• Lack of Structure – Imagine a pile of string that is all tangled and twisted.  If you want that string for something, you would have to spend hours untangling it before you could use it.  The same principle applies to architecture design; use unique reference codes to provide separate threads that reviewers can trace and understand.  You need to be able to track each customer requirement through the conceptual model, logical design, physical design, implementation plan, configuration guide, test plan and standard operating procedures.  How else can you minimise risk and maximise success?
• Logical Design contains references to vendor products and technologies – The purpose of a logical design is to provide a vendor agnostic, functional description that you can ask any vendor to create an engineering specification for.  It defeats the purpose if you name vendors.  How do you know that Vendor X is the best choice to meet your requirements?  That is the point of doing it this way.  Aside from the Physical Design section, the only valid location for naming vendor products is in the Constraints or Assumptions section of the Conceptual Model (eg. Constraint 01 – Customer has an existing EMC Symmetrix VMAX Storage Array that must be used).
• Lack of A3 Blueprints – There is great benefit in providing a series of A3 broadsheets that aggregate all of your design documentation into a single set of Blueprints for the Logical and Physical Designs.  The old adage “a picture is worth a thousand words” certainly holds true here, particularly for the spatially oriented.
• The phrase “Best Practice” – Do not ever use these words in a document.  You are the expert, list the design choices, make a design decision, reference the requirement met, justify your decision and list the impacts and risks.  “Best Practices” are for the novice.
• Weak Risk Analysis – Every design decision has pros, cons and associated risks.  Your job is to make sure each design decision aligns with the customer requirements, where all risks are identified and mitigated.  There is no such thing as a risk free design.
• Long winded explanations of technology features – Understand your target audience.  Your readers are experts in infrastructure design.  You do not need to explain the technology, just explain the reasons behind your design decisions.  Brevity is your friend.
• Lack of Solution Metrics – Once you have a structured design, you can build a spreadsheet that links your documentation together.  This will allow you to measure how well your requirements were met.
• The Juggernaut – Break your architecture design into separate documents to make it easy to review and digest.  For example:  Overview, Architecture Design, Implementation Plan, Configuration Guide, Test Plan and Standard Operating Procedure documents.
• Missing Appendices – Every architecture design should have the Bill of Materials, Abbreviations, Naming Standard and Reference appendices.
• Missing Table of Contents, Figures and Tables – Use the features of Microsoft Word to structure and organise information.  Without them, you are just floating in a sea of words, lost in the ocean with no point of reference.
• Messy Formulas – Use the Microsoft Word Equation Editor to capture any formulas you use for performance and capacity calculations.
• Prepopulated Vendor Templates – If you want to head down the wrong path, use vendor templates that you did not create.  It is much better to start with a blank spreadsheet or document and build your design from scratch.  That way you own it.
• Visio Stencil Packs – Be wary of creating diagrams with vendor stencil packs that confuse the reader.  It is worth defining your own branded Visio style that allows you to communicate your message with simple and efficient diagrams.
• Identify Reviewers & Contributors – List the names of who contributed what and who reviewed it when.  It matters.